OpenVPN a síť za klientem

[RadegastX]

Zdravím,

zprovoznil jsem si OpenVPN server na VPS a klienta na Raspberry v domácí síti a na mobilu. V rámci VPN (10.8.0.0/24) vše funguje, z mobilu si prohlédnu dashboard v Grafaně na Raspi, v tcpdump na Raspi vidím komunikaci atd.
V domácí síti mám i nějaké IoT (192.168.100.0/24), ke kterým bych měl rád taky přístup z mobilu, ale do VPN je přidat nemůžu.

Fórum jsem prostudoval, ale řešení jsem nenašel, proto se ptám tady.

Předpokládám, že musím zajistit aby:
1) pakety z mobilu (10.8.0.3) s dotazem na 192.168.100.x, které přijdou na VPN server (10.8.0.1),  odešly na Raspberry (10.8.0.2)
2) následně na Raspberry došlo k překladu z tun0 (10.8.0.x) na eth0 (192.168.100.x) a odpovědi zpět

Na VPS jsem zjistil, že všemu, co přijde z VPN a nemá cíl ve VPN, se změní source IP

Kód: [Vybrat]

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      400 38664 SNAT       all  --  *      *       10.8.0.0/24         !10.8.0.0/24          to:89.185.xxx.yyy

Předpokládám, že bych to mohl vyřešit takto:

Kód: [Vybrat]

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      143  8700 RETURN     all  --  *      *       10.8.0.0/24          192.168.100.0/24
2      400 38664 SNAT       all  --  *      *       10.8.0.0/24         !10.8.0.0/24          to:89.185.xxx.yyy

Dál jsem se díval do routovací tabulky na VPS:

Kód: [Vybrat]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         89.185.xxx.1    0.0.0.0         UG    0      0        0 ens192
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
89.185.xxx.0    0.0.0.0         255.255.255.0   U     0      0        0 ens192

Chyběla mi tam cesta k 192.168.100.0/24 přes tun0 na Raspi

Kód: [Vybrat]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         89.185.xxx.1    0.0.0.0         UG    0      0        0 ens192
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
89.185.xxx.0    0.0.0.0         255.255.255.0   U     0      0        0 ens192
192.168.100.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0

V tento okamžik jsem si myslel, že na Raspi uvidím v tcpdump na tun0 ping request s odesílatelem 10.8.0.3 a cílem 192.168.100.200 ale bohužel ...

Je moje uvažování zcela zcestné? Nebo není a mám tam chybu?
Díky za odpovědi.

[Reklama]

[František Ryšánek]

Máte tcpdump taky v té VPSce? Hodilo by se mrknout právě tam: zjistit, kde je provoz vidět, a kde už ne.

Nemáte v iptables v té VPSce pravidlo, které by zakazovalo, příchozí paket forwardnout ven tímtéž rozhraním? Protože z hlediska kernelu netdevice tun0 má namapovaný jediný subnet, ve kterém se zjevují přihlásivší se klienti.

Podle mého není třeba se obávat, že Vám do toho hází vidle sama OpenVPN. Pokud máte cílovou adresu mimo subnet, kterému bačuje OpenVPN, tak to každopárně na VPSce bude muset proběhnout kernelovým forwardovacím procesem (vybalené) aby se to odroutovalo zase zpátky do tunelu (byť tentýž subnet).

Koukám nejspíš používáte režim server + dev tun + topology subnet... IPčka tunýlkům přidělujete staticky podle loginu?

Na VPS jsem zjistil, že všemu, co přijde z VPN a nemá cíl ve VPN, se změní source IP

s/zjistil/zajistil ? :-)

Proč vlastně tam máte ten překlad? Vy z té VPSky taky chodíte z tunelových klientů do divokého internetu?

[RadegastX]

Máte tcpdump taky v té VPSce? Hodilo by se mrknout právě tam: zjistit, kde je provoz vidět, a kde už ne.

Ano, mám .. je tam vidět vše, co přijde na tun0 z VPN, mezi klienty vše OK, ping request z klienta na 192.168.100.x je vidět taky.

Nemáte v iptables v té VPSce pravidlo, které by zakazovalo, příchozí paket forwardnout ven tímtéž rozhraním? Protože z hlediska kernelu netdevice tun0 má namapovaný jediný subnet, ve kterém se zjevují přihlásivší se klienti.

Ne, nemám

Koukám nejspíš používáte režim server + dev tun + topology subnet... IPčka tunýlkům přidělujete staticky podle loginu?

Ano

Na VPS jsem zjistil, že všemu, co přijde z VPN a nemá cíl ve VPN, se změní source IP

s/zjistil/zajistil ? :-)

Proč vlastně tam máte ten překlad? Vy z té VPSky taky chodíte z tunelových klientů do divokého internetu?

zjistil

Ten překlad tam přidala instalace OpenVPN.

[František Ryšánek]

Ještě jak jste navrhoval insertnout do chainu POSTROUTING to specifické pravidlo pro 192.168.100.0/24, nestálo by za pokus, namísto RETURN použít  ACCEPT...?
Pardon, asi blbost, pokud v tcpdumpu vidíte pakety odcházet do tun0.

Ale vrtá mi hlavou jiná věc... jestli není problém v "dev tun" v režimu "subnet". Jako že když má OpenVPN IPv4 destination mimo subnet, tak neví, kam s ní. Protože na rozdíl od dev tap, dev tun nemá adresu na druhé vrstvě, podle které by rozlišila jednotlivé klienty... možná je to pitomost, nemám to prozkoumané, jenom mě to teď napadlo. Přemejšlím, jak poznat na OpenVPN paketu zvenčí, že je uvnitř zabalený kýžený paket.

[RadegastX]

Ještě jak jste navrhoval insertnout do chainu POSTROUTING to specifické pravidlo pro 192.168.100.0/24, nestálo by za pokus, namísto RETURN použít  ACCEPT...?
Pardon, asi blbost, pokud v tcpdumpu vidíte pakety odcházet do tun0.

Zkusil jsem, chová se to stejně.
Mám na VPS dva terminály, jeden s příchozí komunikací přes tun0 a druhý s odchozí přes tun0. V obou terminálech ten paket je vidět, ale na raspberry už vidět není ... kontroloval jsem na raspberry iptables a není tam nic, co by mělo vadit.

[Reklama]

[František Ryšánek]

Ale vrtá mi hlavou jiná věc... jestli není problém v "dev tun" v režimu "subnet". Jako že když má OpenVPN IPv4 destination mimo subnet, tak neví, kam s ní. Protože na rozdíl od dev tap, dev tun nemá adresu na druhé vrstvě, podle které by rozlišila jednotlivé klienty... možná je to pitomost, nemám to prozkoumané, jenom mě to teď napadlo. Přemejšlím, jak poznat na OpenVPN paketu zvenčí, že je uvnitř zabalený kýžený paket.

Domnívám se, že dumám správným směrem. Jde to zařídit i v rámci "dev tun" (= nemusíte se uchylovat k "dev tap"). V konfiguráku OpenVPN klienta na RPi byste měl uvést "iroute" záznam. To měkké "i" na začátku není překlep. Je to způsob jak říct OpenVPN, který klient bere konkrétní destinations mimo vlastní OpenVPN subnet. A nejsem si jistý, jestli v tom případě OpenVPN pošle provoz do kernelového routovacího procesu, nebo si to vyřídí v rámci OpenVPN instance (= ten provoz vůbec neopustí "dev tun").

Ten překlad v IPtables... pokud není potřeba, pokusil bych se ho zbavit. Podle mého to není věc, kterou by dělala vanilková OpenVPN - spíš bych řekl, že je to distro-specific.
Ještě mě napadá, pokud je žádoucí tu VPNku úplně opouzdřit, že by se možná dalo rozhraní tun0 zavřít do virtuálního "network namespace".

[RadegastX]

Taky jsem ještě hledal a asi jsem dospěl ke stejnému závěru https://www.pr-software.net/openvpn-routing/

[RadegastX]

Tak abych to shrnul, kombinací různých návodů jsem dospěl k cíli. Není třeba nastavovat žádná pravidla v iptables ani na VPS, ani na klientovi, který je "bránou" do LAN.

1) Na VPS jsem vytvořil adresář /etc/openvpn/ccd
2) V tomto adresáři jsem vytvořil soubory, které musí mít stejná jména, jako jsou pojmenováni klienti při jejich vytváření

V mém případě:

Kód: [Vybrat]

root@darked:/etc/openvpn/ccd# ls -la
drwxr-xr-x 2 root root 4096 Jun 23 10:49 .
drwxr-xr-x 5 root root 4096 Jun 23 10:12 ..
-rw-r--r-- 1 root root   79 Jun 23 10:45 mobil
-rw-r--r-- 1 root root   73 Jun 23 10:45 raspberry

3) Soubor raspberry, který přísluší klientovi, který je "bránou" do 192.168.100.0/24 má obsah:

Kód: [Vybrat]

ifconfig-push 10.8.0.60 255.255.255.0
iroute 192.168.100.0 255.255.255.0

4) Soubor mobil má obsah:

Kód: [Vybrat]

ifconfig-push 10.8.0.50 255.255.255.0
push "route 192.168.100.0 255.255.255.0"

Ostatní potenciální klienti analogicky s jinou přiřazenou statickou adresou

5) Do konfigurace OpenVPN serveru na VPS jsem přidal řádky:

Kód: [Vybrat]

client-config-dir /etc/openvpn/ccd
client-to-client
Teď si už i moje žena umí otevřít garáž pomocí mobilu, když si zabouchne klíče od domu

Pane Ryšánku, díky za konzultaci a nasměrování.

[František Ryšánek]

Není zač, díky za podrobnosti, gratuluji :-)