Az OpenVPN-kliens eléri a szervert, de a LAN-gazdákat nem: ellenőrzőlista

A kliens azt mondja, kapcsolódva, az alagút címe válaszol egy pingre, és semmi nem reagál az irodai LAN-on. Ezt szinte minden kliensfrissítés után látom, és az első ösztön a tűzfal megnyitása, ami általában rossz lépés: az alagút rendben van, és a szakadás a három ugrás egyikén van, amelyen a csomagnak át kell haladnia. Járja végig az útvonalat abban a sorrendben, ahogy a csomag halad, először a kliens útvonala, aztán a szerver továbbítása, aztán a visszaút, és néhány perc alatt megtalálja a hiba gazdáját.

Első lépés: figyelje a kliens útválasztási döntését

Mielőtt hozzányúlna a szerverhez, bizonyítsa, hogy a kliens a csomagot az alagútba küldi. Kérdezze meg a kernelt, melyik interfészt használná egy adott LAN-gazdához, ahelyett hogy a teljes táblát olvasná:

ip route get 192.168.50.10

Ha a válasz a fizikai adapterét és az iroda átjáróját nevezi meg, semmilyen szerveroldali változtatás nem segít. A OpenVPN csak akkor oszt útvonalakat, amikor a szerver tolja őket, ezért keresse a push "route 192.168.50.0 255.255.255.0" bejegyzést a szerver konfigurációjában, majd csatlakoztassa újra a klienst. A legtöbb kliens a betolt útvonalakat kapcsolódáskor alkalmazza, nem a profil újratöltésekor.

Windows alatt ugyanennek a kérdésnek más a parancsa. A Find-NetRoute -RemoteIPAddress 192.168.50.10 kiírja az interfészt és a következő ugrást, amelyet a verem választana, a route print -4 pedig megmutatja, létezik-e egyáltalán a betolt előtag.

Második lépés: erősítse meg, hogy a szerver továbbítja a csomagot

Ha a kliens útvonala helyes, a csomag eléri a szervert, és a szervernek el kell fogadnia a továbbítást. A kernelkapcsoló az első kapu, és a sysctl net.ipv4.ip_forward értékének 1-et kell visszaadnia. A echo 1 > /proc/sys/net/ipv4/ip_forward segítségével beállítva a következő újraindításig működik, és pontosan ezért tér vissza ugyanaz a panasz hetekkel később.

Írja le valahová, ami túlél egy újraindítást:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

A második kapu a szűrőtábla. A Dockerrel telepített gazdán gyakran DROP a FORWARD irányelv, és az alagút ezt a döntést örökli. A iptables -L FORWARD -v -n megmutatja az irányelvet és a csomagszámlálókat is; ha az irányelv DROP, a továbbításhoz kifejezett engedély kell az alagútból a LAN felé irányra, és egy másik a válaszra.

Harmadik lépés: kövesse a csomagot a LAN-ra, és keresse a választ

Figyelje a szerver két oldalát egyszerre. Rögzítsen az alagúton és a LAN-interfészen, egy kliensre és egy gazdára szűrve, hogy a kimenet olvasható maradjon:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

A tun0 felületen, majd újra a eth0 felületen 10.8.0.x forrással megjelenő kérések, amelyeket csend követ, azt jelentik, hogy a csomag megérkezett, a válasz pedig máshová ment. A LAN-gazda a saját alapértelmezett átjárójának válaszol, annak az átjárónak nincs útvonala a VPN-poolhoz, és a válasz meghal a LAN-routeren. A LAN-gazda pingelése a szerverről semmit nem bizonyít erről az útvonalról, mert az a forgalom soha nem halad át az alagúton.

Negyedik lépés: válasszon a címfordítás és a visszaútvonal között

Két javítás zárja be a rést, és a választásnak a ping működésén túl is vannak következményei. A forrás-címfordítás a szervert teszi látszólagos küldővé:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Szűkítse a szabályt a poolra és a LAN-interfészre, majd tegye állandóvá, különben a következő tűzfal-újratöltés csendben eltávolítja a javítását. Az ár az azonosság: minden kliens úgy néz ki, mint a VPN-szerver a LAN-naplókban és a hozzáférési szabályokban, és per-client policy becomes guesswork.

A LAN-routeren a VPN-szerverre mutató statikus útvonal a 10.8.0.0/24-hez láthatóvá teszi a kliensek címeit, és ez a jobb hosszú távú válasz, amikor az a router az öné. Sok helyen egy ideig mindkettő fut, NAT az azonnali javításhoz és az útvonal, amint a tűzfalszabály megíródott. Ha a szerver site-to-site partner és nem pool, a szerveroldalnak is kell egy iroute a távoli alhálózathoz, különben a partner útvonala létezik, de a kliensforgalom soha nem kapcsolódik hozzá.

Ötödik lépés: ellenőrizze a kliensről, és jegyezze fel, mi változott

A klienstől zárja a hurkot, nem a szervertől. Csatlakozzon egy valódi szolgáltatáshoz a LAN-gazdán, majd erősítse meg, hogy a címfordítási számlálók elmozdultak a iptables -t nat -L POSTROUTING -v -n segítségével, mert a nulla csomagos szabály olyan szabály, amely soha nem illeszkedett. A conntrack -L -s 10.8.0.5 megmutatja a folyamot és annak állapotát, amikor bizonyíték kell arra, hogy a visszirány követve van.

Hagyjon megjegyzést a szerver konfigurációjában: melyik alhálózat, melyik interfész, melyik szabály, és hogy a LAN-router hordoz-e visszaútvonalat. Amikor legközelebb egy kliensfrissítés töröl egy betolt útvonalat, az a megjegyzés egy tűzoltó munkamenetet egysoros javítássá alakít.