Hogyan költöztessünk Raspberry Pi VPN-szervert Ethernetre

A Pi átállítása Wi-Fi-ről kábelre ötperces munkának tűnik, és csak akkor is marad az, ha a költözést négy külön beállításként kezeli egy helyett. A végpont neve, amelyet az ügyfelei hívnak, pontosan ugyanaz maradhat, miközben a mögötte lévő cím változik. Valójában a régi címhez rögzített listener törik el, a porttovábbítás, amely még mindig a vezeték nélküli lease-re mutat, vagy egy visszatérő útvonal, amely azon a felületen hagyja el a gépet, amelyet már kivontnak hitt. Ez az útmutató minden lépésnél nyitva tart egy helyreállítási útvonalat, így egy sikertelen átállás csak egy újraindításba kerül.

Jegyezze fel a négy felelőst, mielőtt bármit kihúzna

Négy beállítás dönti el, hogy a váltás túléli-e: a Pi címe, a kötési cím OpenVPN, a router átirányítási célja és az útvonal, amelyen a válaszok haladnak. Jegyezze fel mind a négyet, mielőtt hozzáér a kábelhez, mert amint eltűnik a vezeték nélküli lease, a régi értékeket már nem tudja kiolvasni a gépről. A kábeles interfész nem örökli a vezeték nélküli profilt, és Bookworm alatt a cím a NetworkManagerben él, míg a Bullseye a dhcpcd.conf-ban tartja. Egy rezerváció, amely a vezeték nélküli MAC-címet rögzítette, semmit sem mond eth0-ról. Kezelje az új címet új hozzárendelésként, amelynek saját bizonyítékra van szüksége.

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

A listener a második felelős. Ha a szolgáltatás konkrét kötési címmel indult, a socket meghal a régi interfésszel; ha minden címet köt, a socket túléli, és a router szabálya lesz az egyetlen, amit még ki kell javítani.

Az átirányítási cél és a visszatérő útvonal azok a felelősök, amelyeket az emberek kihagynak. A továbbítás, amely még mindig 10.42.7.24-re mutat, a beérkező kézfogásokat arra a címre küldi, amellyel a Pi már nem rendelkezik, ezért az ügyfelek időtúllépéssel zárnak, anélkül hogy a szerveroldalon egyetlen naplósor is megjelenne. A visszatérő útvonal akkor számít, amikor mindkét kapcsolat rövid ideig aktív, mert a Pi azon a felületen válaszol, amelyet az útvonaltábla előnyben részesít, és ez nem mindig az, amelyen a csomag érkezett. Az alábbi útvonalkeresés megmutatja, melyik forrást választja a kernel.

Olvassa el a tényleges socketet, mielőtt megbízik az új címben

A konfigurációs fájlok a szándékot írják le, a socket pedig a valóságot. Kérdezze meg a futó szolgáltatást, mihez van kötve, ahelyett hogy megbízna az emlékezett konfigurációban. Az OpenVPN 2.6 kézikönyv --local-t egy címhez kötésként definiálja, és megjegyzi, hogy elhagyása minden felületet hozzáköt.

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

Az állapotoszlop helyett a helyi cím oszlopát olvassa. Egy sor, amely 10.42.7.24:1194 mutat, azt jelenti, hogy a socket ahhoz a címhez van rögzítve, amelyet mindjárt eltávolít, míg a 0.0.0.0:1194 vagy *:1194 azt jelenti, hogy a démon maga követi az interfész változását. Ha a cím rögzítve van, szerkessze a profilt és indítsa újra az egységet, ahelyett hogy kézzel átírná az élő socketet, majd ellenőrizze, hogy a szolgáltatás továbbra is eléri-e a tanúsítvány- és kulcsfájljait.

Olyan sorrendben haladjon végig a költözéssel, amely biztosítja, hogy elérhető maradjon

A sorrend itt fontosabb a sebességnél. Hozza fel a kábeles kapcsolatot, amíg a vezeték nélküli még működik, erősítse meg az új címet és a visszatérő útvonalat, és csak ezután vonja ki a vezeték nélküli profilt. Ez a sorrend nyitva tart egy működő munkamenetet, amíg a csere bizonyítást nem nyer.

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

Az első parancs megválaszolja, hogy eth0 megkapta-e a szándékolt címet, a második pedig kiírja azt a forráscímet, amelyet a kernel egy külső célhoz használna, ezért futtassa a változás előtt és után. Ha ez a forrás még mindig a vezeték nélküli cím, a kábeles kapcsolat még nem az előnyben részesített útvonal, és a kinti teszt olyan okból fog meghiúsulni, amelynek semmi köze az OpenVPN-hez. Javítsa ki az útválasztási preferenciát, mielőtt hozzáér a továbbításhoz.

Ha mindkét kapcsolat aktív, a Pi előnyben részesítheti a vezeték nélküli alapértelmezett útvonalat, mert azt telepítették előbb, vagy mert a kábeles kapcsolat magasabb metrikát hordoz. Bookworm alatt a támogatott beállítás a ipv4.route-metric a kapcsolaton, Bullseye alatt pedig az egyenértékű egy interfész-specifikus metric sor a dhcpcd.conf fájlban. Csökkentse a vezeték nélküli kapcsolat besorolását ahelyett hogy kikapcsolná, hogy a visszaállítási útvonal egy parancsnyira maradjon.

A tunelt kívülről bizonyítsa, ne a LAN-ból

Egy VPN-kapcsolat, amely a kanapéról működik, kevesebbet bizonyít, mint amennyit látszik. A LAN belsejéből a nyilvános cím felé menő forgalom hairpin- vagy tükrözési szabályokon halad át, amelyeket a routerek következetlenül valósítanak meg, ezért egy sikeres LAN-teszt létezhet egy törött külső útvonal mellett. Az átvételi teszthez használjon mobil adatforgalmú telefont vagy bármely hálózaton kívüli hostot. A LAN-próbálkozást tartsa külön, opcionális diagnosztikaként.

Ezután olvassa a naplót abban a sorrendben, ahogy a csomagok érkeznek. Semmi sem azt jelenti, hogy a kézfogás soha nem érte el a Pi-t, tehát az átirányítási cél vagy a host tűzfala rossz. Az a kézfogás, amely elkezdődik és elakad, kulcsokra, tanúsítványokra vagy MTU-ra utal. Az a munkamenet, amely befejeződik és leesik, általában a visszatérő útvonalat vagy egy második alapértelmezett útvonalat jelent, és az ügyfél naplósora Initialization Sequence Completed megmondja, hogy maga a tunel felállt.

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

Ha semmi sem jelenik meg a szervernaplóban, miközben az ügyfél újra próbálkozik, hagyja abba az OpenVPN-konfiguráció olvasását, és térjen vissza az átirányítási célhoz. A rögzítés másodpercek alatt megválaszolja az érkezés kérdését, a válasz nélküli bejövő csomagok pedig az útvonalra szűkítik a problémát.

Tartson meg egy egy lépéses visszaállítást, és vonja ki a vezeték nélküli profilt

Hagyja a vezeték nélküli profilt telepítve, amíg a kábeles elrendezés túl nem él egy újraindítást. nmcli con show felsorolja a szükséges profilneveket, és egy törölt profilt a legrosszabb pillanatban kell újraépíteni emlékezetből. Jegyezze fel az interfész nevét, a címzési módot és a metrikát a másik négy érték mellé. Egy jegyzetből beírható visszaállítás többet ér, mint amit újra kell építeni.

A vezeték nélküli függőség kivonása tulajdonságváltozás, nem törlés. Ha beállítja a connection.autoconnect no értéket, a hitelesítő adatok és a címelőzmények érintetlenek maradnak, miközben a Pi nem tud újra csatlakozni ahhoz a hálózathoz, amelyről elköltözött.

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

Mielőtt befejezettnek nyilvánítja a munkát, erősítsen meg négy dolgot: az átirányítási cél megfelel a kábeles címnek, a listener túlélte az újraindítást, egy külső ügyfél befejezi a kézfogást, és a Pi újraindítás után is válaszol a kábeles címen. Az újraindítás a legolcsóbb módja annak, hogy elkapjon egy olyan hozzárendelést, amely csak a futó kernelben létezett. Ha a négy közül bármelyik meghiúsul, hozza vissza a vezeték nélküli profilt ezzel: sudo nmcli con up és hasonlítsa össze a feljegyzett értékeket az aktívakkal.