Jeden pomysł to OpenVPN w trybie tap. Wtedy jesteś w stanie udawać w pewnym stopniu jakbyś był wpięty fizycznie. Na kliencie robisz bridge któryś porów na switchu i powino działać. Masz zewnętrzny, publiczny adres od netii?

Na tym jednym "porcie telewizyjnym" jest oddzielny vlan, dhcp? Tutaj jest opis jak przepchnąć vlany przez tunel openvpn na określone fizyczne porty:
https://forum.openwrt.org/viewtopic.php?id=33678

ethernet bridging:
https://openvpn.net/index.php/open-sour … dging.html

Poczytałem i wydaje mi się, że tak będzie OK:

DOM (Netia):

{Internet}---[Technicolor(modem/router od Netii)]---[NUC(Linux)]

NUC ma:
-serwer OpenVPN w trybie TAP i bridge (eth0+tap0)
-serwer DHCP dla całej sieci, żeby można było "przepołowić" adresy (Technicolor nie zapamiętuje konfiguracji DHCP...)

Technicolor ma:
-wyłączone DHCP (to zapamiętuje)
-przekierowanie UDP na NUCa, żeby OpenVPN działał
-WiFi

Oczywiście poza VPNem, będzie więcej podłączonych urządzeń (np. kamera)

ZDALNY:

{Internet}---[1043ND]---[NP]

1043ND ma:
-serwer DHCP skonfigurowany "komplementarnie" (druga połowa zakresu) do tego z domu
-klienta OpenVPN łączącego się do domu - również TAP w bridge (eth0+tap0)
-WiFi

Oczywiście i tutaj będzie więcej klientów

I teraz widzę dwa wyjścia i nie wiem które lepsze:
1. Zostawić dwie "całe" połączone sieci (efektywnie mam jeden duży LAN, wszystkie urządzenia widzą się nawzajem, a tylko dla NP wymusić "wyjście" przez VPN tzn. ustawić mu gateway na Technicolor)
2. Sprawić, żeby tylko NP gadał przez VPN, a reszta nie (efektywnie są dwa LANy, a tylko jedno urządzenie w tym zdalnym "wygląda" jakby było podłączone do tego domowego)

Dużo osób mówi, że TAP jest wolniejszy i więcej wymaga zarówno od łącza (więcej danych+większe nagłówki) jak i sprzętu (więcej ramkowania+szyfrowanie). Więc może opcja "2" jest lepsza, bo pewnie jakoś można cały ten ruch przyciąć tylko do tego jednego, zainteresowanego urządzenia (NP). Przy okazji warto zauważyć, że to praktycznie tylko ściąga (upload to chyba tylko przy logowaniu i zmianie kanałów).
Z kolei opcja "1" jest de facto fajniejsza, bo mam wszystko dostępne tak jakbym był w domu. Nie muszę się bawić w przekierowywanie np. kamerki itp. Ale za to bridge ma dużo więcej roboty.

1043ND da radę, gdyby zrobić #2? Dziś wieczorem sprawdzę, ile faktycznie NP wymaga łącza (ale na pewno najmarniej kilka Mbps)

No właśnie się z tym męczę...

Netia jest 100/10, a więc 10Mbps. Od dłuższego czasu próbuje zmierzyć ile pojedynczy NP zużywa i...nie wiem jak. Myślałem, że te wykresy są popsute, ale teraz poszedłem prostszą drogą:

root@OpenWrt:~# ifconfig | grep bytes
          RX bytes:116926072 (111.5 MiB)  TX bytes:50841088 (48.4 MiB)
          RX bytes:98128037 (93.5 MiB)  TX bytes:772119081 (736.3 MiB)
          RX bytes:4152768927 (3.8 GiB)  TX bytes:55796844 (53.2 MiB)
          RX bytes:0 (0.0 B)  TX bytes:705939366 (673.2 MiB)
          RX bytes:41009 (40.0 KiB)  TX bytes:41009 (40.0 KiB)
root@OpenWrt:~# ifconfig | grep bytes
          RX bytes:117060952 (111.6 MiB)  TX bytes:51243240 (48.8 MiB)
          RX bytes:98592818 (94.0 MiB)  TX bytes:772572181 (736.7 MiB)
          RX bytes:4153194342 (3.8 GiB)  TX bytes:56200200 (53.5 MiB)
          RX bytes:0 (0.0 B)  TX bytes:705984510 (673.2 MiB)
          RX bytes:41009 (40.0 KiB)  TX bytes:41009 (40.0 KiB)

I nadal nie rozumiem. Między tymi "pomiarami" było ponad 10 minut, NP wpięty bezpośrednio w port #4 w 1043ND, cały czas leci kanał w HD. Gdzie te dane? Coś powinno się solidnie zmienić przecież...

Informacyjnie: NP działa też zza NATu tzn. nie musi być wpięte bezpośrednio w Technicolor (router Netii). Chciałem to sprawdzić nim zacznę się bawić w OpenVPN.

OK, działa, i to w trybie TUN!
(czy to znaczy, że NP nie robi nic specjalnego, żadnych vlanów itp? Bo tak to rozumiem.)

Tablica routingu jednak była OK, tylko nie wiedziałem o co chodzi z tymi dziwnymi trasami do bramki. Okazuje się, że to trick stosowany przez OpenVPN, żeby wymusić użycie ich interfejsu bez zmieniania istniejących wpisów. Tzn. nie ruszają tego co jest tylko dodają swoje wpisy, które są ważniejsze, bo są bardziej szczegółowe niż domyślny. Do poczytania TUTAJ. [TLDR]Ogólnie oba te wpisy "w sumie" przekierowują CAŁY ruch (każdy 'po połowie' zakresu), a że oba kierują do tego samego adresu to efektywnie to jakby jeden wpis. Fakt że jest 'po pół' powoduje, że są ważniejsze od tego domyślnego i w ten sposób nie trzeba go modyfikować, a priorytet i tak mają dwa 'po pół'.[/TLDR] To ten tajemniczy def1, który widać często w pytaniach "Jak przekierować cały ruch przez VPN?"

Co było źle? Niestety nie wiem. Podejrzewam, że albo firewall blokował ruch LAN <-> VPN albo w ogóle go nie było.

Ustawione tak jak TUTAJ opisane. Jakby się adres zmienił albo coś to wrzucam treść poniżej:

# ("streisand" to nazwa własna jego serwera, do zmiany wedle uznania)

# a new OpenVPN instance:
uci set openvpn.streisand=openvpn
uci set openvpn.streisand.enabled='1'
uci set openvpn.streisand.config='/etc/openvpn/streisand.conf'

# a new network interface for tun:
uci set network.streisandvpn=interface
uci set network.streisandvpn.proto='none' #dhcp #none
uci set network.streisandvpn.ifname='tun0'

# a new firewall zone (for VPN):
uci add firewall zone
uci set firewall.@zone[-1].name='vpn'
uci set firewall.@zone[-1].input='REJECT'
uci set firewall.@zone[-1].output='ACCEPT'
uci set firewall.@zone[-1].forward='REJECT'
uci set firewall.@zone[-1].masq='1'
uci set firewall.@zone[-1].mtu_fix='1'
uci add_list firewall.@zone[-1].network='streisandvpn'

# enable forwarding from LAN to VPN:
uci add firewall forwarding
uci set firewall.@forwarding[-1].src='lan'
uci set firewall.@forwarding[-1].dest='vpn'

# Finally, you should commit UCI changes:
uci commit

Tylko nie wiem czemu autor dał REJECT w input/forward - a tym bardziej, czemu mimo tego działa. Może ktoś mądrzejszy się wypowie?