[Megoldva] VPN beállítás

Hálózatok általános

Sziasztok!

VPN-nel összekapcsolt hálózatok beállításában szeretnék segítséget kérni. Barátom a Gugli sok olvasnivalót adott, de hiába: nem vagyok otthon ebben a témában. Ezért megkérek mindenkit, hogy a válaszát - ha olyan jellegű, akkor - egy-két mondattal magyarázza is el.

Minden gépen Debian vagy Raspberry Pi OS van telepítve és OpenVPN-t használok.

VPN-nel összekötött hálózatok

A képen látható VPN kapcsolat működik, a szerver és a kliens látja egymást szolgáltatásait.

Célok:

  • a LAN1 PC-jéről el tudjam érni LAN2 RPi szolgáltatásait és ha ez már működik, akkor
  • a LAN1 PC-jéről el tudjam érni LAN2 PC szolgáltatásait.

A válaszokat előre is köszönöm.

  • 475 megtekintés

( andrej_ v | 2023. 04. 07., p – 15:23 )

Egymásnak lesznek a gateway-ei. A 192.168.0.0/24-es hálózat a 10.203.29.1 -en lesz elérhető, ha openvpn akkor push route kell. Fordítva pedig a 192.168.1.0/24-es hálózatnak a 10.203.29.3 lesz a gateway-e, openvpnnél talán iroute, a szerver oldalon meg statikusan. Linuxon ehhez az ip_forward legyen engedélyezve.

Ezzel elérem a LAN1 RPi-ről (de csak arról) a LAN2 eszközeit:

LAN1 RPi /etc/openvpn/ccd/profil:

(...)
iroute 192.168.1.0 255.255.255.0

LAN1 RPi /etc/openvpn/server.conf:

(...)
route 192.168.1.0 255.255.255.0

Már csak másik mumussal, a LAN1 route-olásával kell megküzdeni.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

( pozsarzs | 2023. 04. 07., p – 21:22 )

Szerkesztve: 2023. 04. 08., szo – 07:16

Azt már elértem, hogy a LAN2 RPi-ről látom az egész LAN1-et, még ha ez nem is volt cél:

LAN1 RPi /etc/openvpn/server.conf:

(...)
push "route 192.168.0.0 255.255.255.0"
sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
service networking restart

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

( sibike | 2023. 04. 07., p – 21:52 )

Biztos nem kell NAT (MASQUERADE), mert nincsenek egymást fedő tartományok....

Ez a 10.66.0.0 honnan jött? Szerintem felejtsd el a push route-okat...

Az alábbi static route-okat kellene felvenni az eszközökön:

LAN1 RPi

192.168.1.0/24 via 10.203.29.3

LAN1 PC

192.168.1.0/24 via 192.168.0.50

LAN2 RPi

192.168.0.0/24 via 10.203.29.1

LAN2 PC

192.168.0.0/24 via 192.168.1.9

Feltételeztem, hogy az RPI LAN és VPN címek fixek. Utóbbi ellenőrzéséhez kellene a szerver oldali config.

> Szerintem felejtsd el a push route-okat...

hat nem feltetlen, mert ha nem fix a tun-ok ip-je akkor nem nagyon van mas ut (esetleg valami ip-up scriptet raaggatni), illetve amig nem epul fel a vpn addig nem is tud route-t konfolni a tun-ra. erre valo a push route, bar inkabb iroute lesz az...

> Ez a 10.66.0.0 honnan jött?

Köszi az észrevételt, ahol példában ez szerepelt, javítottam.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

Minden cím állandó. A static route-ok felvételét nehezíti, hogy a LAN2-n kamerák és mikrovezérlők is vannak.

Találtam egy megoldást, hamarosan kifejtem.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

Kép

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

szvsz, ha a 4 gépből az egyik szerver (amelyik fixen be van kapcsolva), akkor egyszerű a probléma.

- Ha nincs publikus IP-je egyik gépnek sem, akkor már nehezebb. Ekkor szerintem opció lehet az is, hogy bérelsz egy VPS-t amire felrakod az OpenVPN szervert.
- Ha az otthoni gép routerén van VPN szerver lehetőség és kívülről is látszik, akkor szintén egyszerű a dolog, mert oda kell csatlakoznia, a két mobilnet mögötti eszköznek.

Készítettem egy blogbejegyzést a témában: https://hup.hu/node/181388

 

ps.: Lan1 10-es IP-jű gép eth0-ra tennék még egy IP-t (igen 2 ip-je lenne) amire raknék egy vpn client-et, és máris minden gép egy hálóban van.

Köszönöm, elolvasom.

A LAN2 szolgáltatói NAT mögött van, a LAN1 elérhető, ezért tettem a klienset a LAN2-be. A routereken sajnos nincs VPN lehetőség.

Jelenlegi állapot:

  • a LAN2 szerveréről látom a teljes LAN1 hálózatot, ez biztonsági okból elég is.
  • a LAN1 szerveréről látom a teljes LAN2 hálózatot, de ez kevés: A teljes LAN2-őt a teljes LAN1-ből szeretném elérni.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

Szerintem 1 szerver kellene, amin keresztül látják egymást. Ennek oka, ha mindkét oldalon a route-táblával vacakolsz, akkor "lényegében" ugyanott vagy. Csak lényegében mert, ha a kliensoldalon egymásnak akartok bármit küldeni ezen a hálón keresztül, akkor az elmegy a másik oldali a szerverig. Erre ne használd ezt a hálót, mert lokálisan amúgy is látják egymást a gépek. 

> Csak lényegében mert, ha a kliensoldalon egymásnak akartok bármit küldeni ezen a hálón keresztül, akkor az elmegy a másik oldali a szerverig.

A LAN2 RPi az OpenVPN kliens, de ennek más feladata is van: mikrovezérlőkkel tart kapcsolatot.

Amíg a route-olás nincs állítgatva és csak az RPi-ken látom a másik oldal teljes hálóját, a mikrovezérlők lekérdezése ekkor is megjárja az VPN kapcsolatot?

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

( pozsarzs | 2023. 04. 08., szo – 14:18 )

Csak egy kliens van. A VPN-en keresztül csak a távoli ellenőrzése történne. A lekérdezések a LAN2-n belül mennek.

Szerver oldal:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway.lan     0.0.0.0         UG    202    0        0 eth0
10.203.29.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.1.0     10.203.29.2     255.255.255.0   UG    0      0        0 tun0

A gateway.lan az átjáró az internet felé.

Kliens oldal:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.203.29.1     128.0.0.0       UG    0      0        0 tun0
default         router.lan      0.0.0.0         UG    202    0        0 eth0
10.203.29.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.203.29.1     128.0.0.0       UG    0      0        0 tun0
95C8175F.dsl.po router.lan      255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

A router.lan az átjáró az internet felé.

Jól gondolom? A kliens oldal táblájában megjelenik a szerver 10.203.29.1 IP címe, mint gateway, ez nem jelent jót. Tehát most, hogy az RPi-k látják a másik teljes hálózatát, az oda-vissza adatforgalom történik a helyi adatforgalom esetén is?

Ha visszaállítom arra az állapotra, amikor az RPi-k csak egymást látták, akkor már nem történhet ilyen felesleges adatforgalom?

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

( pozsarzs | 2023. 04. 08., szo – 15:16 )

Megnéztem a válaszidőket:

  • A LAN2 hálón egy másik helyi eszköz pingelésekor a válaszidő 2-3 ms, ha ugyanezt a LAN1-ről pingelem akkor 50-60 ms.
  • A LAN1 hálón egy másik helyi eszköz pingelésekor a válaszidő 0,4-0,6 ms, ha ugyanezt a LAN2-ről pingelem akkor 50-60 ms.

Ebből arra következtetek, hogy a LAN2-es helyi forgalma most nem megy át a LAN1-en lévő szerverre. Hurrá!

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

Ezt nem ismertem, de nagyon jó, köszönöm.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

( pozsarzs | 2023. 04. 09., v – 12:31 )

A végső állapot az lett, hogy nem route-oltam tovább sehova, hanem:

  • a LAN1-en csak az RPi (VPN szerver) látja a teljes LAN2-t,
  • a LAN2-n csak az RPi (VPN első kliens) látja a teljes LAN1-t,
  • mobilról vagy laptopról második VPN kliensként bejelentkezve látom mindkét hálózatot.

Így elérem mindkét oldal kameráit, mikorvezérlőit és a RPi-k webes felületeit, tehát mindent amire rendszeresen kíváncsi vagyok, és be is tudok SSH-val jelentkezni mindenhová.

Köszönöm mindenkinek a rám fordított időt.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

( Zs | 2023. 04. 10., h – 12:00 )

A feladat tisztán OpenVPN segítségével a következő módon oldható meg:

  • a konfigban lesz egy push route, amely egyfelől beállítja a kliensen, hogy a szerver mögötti subnet a VPN kapcsolaton elérhető, másfelől  az OpenVPN-nek is infó, hogy az ebbe a subnet-be érkező forgalmat a fogadó oldalon kell kiengedni,
  • a kliens oldal kicsit összetettebb, mert ott egy kliens mögötti subnetet kell láttatni, de ez is megoldható - csak kicsit több beállítást igényel
    • ehhez is kell egy push route, amely most a kliens mögötti subnetet is felveszi, mint a VPN-en keresztül elérhető subnet,
    • definiálni kell a ccd-t, azaz egy önálló mappába bele kell tenni az kliensekhez tartozó egyedi konfigot,
    • létre kell hozni a klienshez tartozó egyedi konfigot és ebben egy iroute sort elhelyezni - ez fogja informálni az OpenVPN-t, hogy a korábbiakban megadott kliens mögötti subnet ezen kliens mögött érhető el, tehát a VPN-be bekerülő, ezenl tartomány-beli cél IP-vel rendelkező csomagot ehhez a klienshez kell küldeni, hogy célba érjen.