VPN a routeren vagy porttovábbítás: melyik nyer?

A router maga fejezi be a VPN-t, és egy régi továbbítási szabály még mindig ugyanazt az UDP-portot küldi el egy LAN-gépre. Csak az egyikük lehet az igazi végpont, és a kernel nem dönt közöttük. A célfordítás átírja a csomagot, mielőtt a helyi szolgáltatást megkérdeznék, így a VPN-folyamat olyan forgalomra vár, amelyet már máshova küldtek. A feladat, hogy eldöntsük, kié a port, majd összehangoljuk a szabályokat.

Egy port, két igényelt tulajdonos

A routeren belül futó VPN-kiszolgálónak bejövő engedélyre van szüksége, amely a saját socketjéhez vezet. Ugyanannak a portnak a cél-NAT-bejegyzése egészen máshová vezet: egy LAN-címre és egy továbbítási döntésre. Ezek különböző végpontok, különböző naplókkal és különböző meghibásodási módokkal. A szokásos nyom, hogy az egyik címcsalád működik, a másik nem, mert a megmaradt bejegyzést egyetlen családhoz írták, és soha nem vizsgálták felül.

Írja fel az igényt szerkesztés előtt: család, külső cím, átvitel, port és a lefordított cél.

A fordítás a helyi ellenőrzés előtt fut

A cél-NAT a prerouting szakaszban változtatja meg a csomag célját, mielőtt a kernel a helyi kézbesítés és a továbbítás között választana. Amint a cél LAN-gazdagép lesz, a csomag a továbbítási útra tér. A router saját socketjának bemeneti szabályait soha nem vizsgálják, ezért a VPN-napló üresen marad, miközben az ügyfél időtúllépést szenved.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Ez a sorrend az egész mechanizmus, és az eszközök felületei jelölőnégyzetek mögé rejtik anélkül, hogy megváltoztatnák. A csomag útjáról továbbra is a cél tulajdonosa dönt.

Ha a LAN-gazdagép a kívánt végpont, a továbbítás helyes, és a routernek nem szabad ugyanazon a porton is figyelnie.

Tartsa meg az egyik leképezést, és távolítsa el a másikat

Listázza az adott port és család NAT-bejegyzéseit, és válassza ki a túlélőt:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Az azonos számú TCP-bejegyzés irreleváns egy UDP-hiba szempontjából, és ha egyetlen objektumnak tekintjük őket, rossz szabályt törlünk. Amikor a helyi socketnek kell nyernie, az ütköző leképezés tulajdonosa eltávolítja vagy átírja ezt az egy bejegyzést, és a router saját portjának bejövő engedélye a helyén marad. A független továbbításoknak, a kezelési útvonalnak és a szabálykészlet egy példányának egyaránt túl kell élnie a változtatást.

Ha a VPN külön gazdagépen él, a továbbítás a helyes objektum. Egy konténerben vagy virtuális gépen futó szolgáltatásnak is szüksége lehet közzétett portra, még akkor is, ha a dobozt routernek hívják, ezért a socketet és annak névterét kövesse, ne a házon lévő címkét.

Erősítse meg a tulajdonost kívülről

Minden családot külön teszteljen, mert a routeren végződő IPv6-kapcsolat semmit sem mond arról az IPv4-kapcsolatról, amelyet egy elavult szabály átirányít. Olvassa el a fogadó szolgáltatás naplóját, hogy lássa, melyik végpont válaszolt, és a kliens sikerüzenetét gyenge bizonyítéknak tekintse. Érdemi teszthez új folyamra van szükség. Küldjön próbát külső gazdagépről a nc -zvu 203.0.113.7 1194 használatával, és olvassa el a nyertes naplóját a journalctl -u openvpn@server -n 20 használatával. A router figyelője maga naplózza a kapcsolatot, míg egy LAN-gazdagép a saját szolgáltatásában naplózza.

A kapcsolatkövetés a meglévő folyamokat az eredeti leképezésükön tartja, így egy létrejött munkamenet túlélheti az imént javított szabályt.

Miután a kívánt végpont a szokásos identitás-ellenőrzéseivel válaszol, teszteljen egy privát erőforrást az alagút mögött. A külső figyelő elérése csak az első ugrás; a belső útválasztás és az alkalmazásengedélyezés külön eredmények.