Tegyen közzé egy VPN-kliensportot CGNAT mögül: ellenőrzőlista

Tegyen egy szolgáltatást egy szolgáltatói szintű NAT mögötti laptopra, irányítsa azt a laptopot VPN-en keresztül egy VPS-re, és kívülről senki nem érheti el. Hozzáad egy cél-NAT-szabályt a VPS-en, és valami rosszabbat kap a csendnél: a kapcsolatok megnyílnak, majd elakadnak. A válasz nem hiányzik, a kliens saját alapértelmezett útvonalán távozik, ami azt jelenti, hogy a szerver soha nem látja. Járja végig ezt az öt ellenőrzést sorrendben, és álljon meg az elsőnél, amelyik nem állja meg a helyét.

Erősítse meg, hogy a szerver egyáltalán továbbít

Jelölje be ezt a négyzetet, mielőtt akár egyetlen fordítást írna. Egy olyan csomag DNAT-szabályát, amelyet a kernel nem hajlandó továbbítani, a szabályértelmező elfogadja, majd a továbbítási útvonal eldobja, ami olyan időtúllépést okoz, amely tűzfalproblémának tűnik.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

Futó kernelben beállítani nem ugyanaz, mint újraindításon át beállítani. Írja a net.ipv4.ip_forward=1 sort egy fájlba a /etc/sysctl.d/ alatt, futtassa a sysctl --system parancsot, majd olvassa vissza az értéket ahelyett, hogy megbízna abban, hogy a fájlt átvették. Egy konténernek, amely a saját hálózati névterét kezeli, ugyanarra az értékre van szüksége azon a névtéren belül, nem csak a gazdagépen.

Ha a visszaolvasás még mindig nulla, álljon meg itt. Lent semmi sem fog működni.

Rögzítse az alagút címét, mielőtt bármely szabály hivatkozna rá

A készlet csatlakozási sorrendben osztja ki a címeket, így egy mai bérletre írt szabály jövő héten csendben egy másik kliensre mutathat. A címet a tanúsítvány identitásához kösse, ne az érkezés sorrendjéhez.

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

Ez a pár a pont-pont alagút kliens vége és partnervége, a szerver pedig a tanúsítvány köznapi nevéhez van kötve. Alhálózati topológiában a második értéket helyette hálózati maszkként olvassák, ezért a használt topológiának megfelelő alakot írja. Ezután csatlakoztassa újra a klienst, és olvassa le a címet magán a kliensen, mert a szerver készletről alkotott képe nem bizonyítja, mit állított be a kliens.

Ha a cím újracsatlakozás után megváltozik, álljon meg. A mozgó célpontot követő NAT-szabály időnként meghibásodik, és semmire sem tanítja meg.

Fordítson mindkét irányban

A célfordítás a bejövő csomagot a klienshez küldi. A forrásfordítás az, ami ráveszi a klienst, hogy a szervernek válaszoljon, ne az eredeti küldőnek, és ez az a szabály, amelyet az emberek kihagynak.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

A második szabály nélkül a kliens az ISP feltmeneti kapcsolatán keresztül válaszol, így a távoli partner olyan forráscímet lát, amellyel soha nem beszélt, miközben a szervernek nincs nyomkövetési bejegyzése a válaszhoz. A külső megfigyelő félúton befejeződő kézfogást lát, és pontosan ez a tünet küldi az embereket olyan tűzfalhiba keresésére, amely nem létezik.

Olvassa vissza mindkét szabályt a iptables -t nat -S paranccsal, és erősítse meg, hogy az interfész neve az, amely a nyilvános címet viseli. Olyan gazdagépen, amely már nftables-szel szűr, a fordítást a megfelelő címcsalád nftables NAT-láncában írja meg, ahelyett hogy eszközöket keverne.

Engedje át a szűrőtáblát

A NAT-táblák átírják a fejléceket; nem adnak engedélyt. Alapértelmezett DROP-szabályzattal a továbbított folyamnak saját engedélyre van szüksége, plusz a visszirányra, amelyet a legtöbb szabályzat már lefed egy established,related szabállyal.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Ellenőrizze a FORWARD lánc szabályzatát, mielőtt bármit hozzáadna, mert egy korai DROP sorrendje dönti el, hogy egyáltalán megkérdezik-e a szabályát. Olyan gazdagépen, amelynek szűrése nftables-ben él, adja hozzá az egyenértékű szabályt az inet tábla forward hookjához, és erősítse meg, hogy az alaplánc valóban látja a továbbított forgalmat, nem csak a helyi bemenetet. Ha az új szabály csomagszámlálója nullán marad, miközben a NAT-számlálók nőnek, a csomagot a szabálya előtt dobják el. Ez annak a jele, hogy olvassa el a láncok sorrendjét, nem hogy hozzáadja ugyanazon szabály második példányát.

Bizonyítsa külső hálózatból

Teszteljen egy nem kapcsolódó hálózatból. Egy másik gép próbája ugyanazon a LAN-on áthaladhat a hairpin NAT támogatáson, és soha nem gyakorolja azt az útvonalat, amelyet egy távoli kliens használ, így az ottani zöld eredmény a rossz dolgot bizonyítja.

tcpdump -ni any port 29443
conntrack -L | grep 29443

Futtassa a rögzítést a szerveren és a kliensen egyszerre. A szerver rögzítése megmutatja, hogy a lefordított csomag elhagyja-e az alagút felé; a kliens rögzítése megmutatja, hogy a kérés megérkezik-e, és hova van címezve a válasz. A conntrack -L bejegyzésében lévő fordítási bejegyzés bizonyítja, hogy a szabály illeszkedett, hiánya pedig bizonyítja, hogy a csomag soha nem érte el a NAT-láncot.

A portszkennerek gyenge bizonyítékok. Zártnak jelentik a portot, amíg az alkalmazás nincs hozzákötve és nem figyel, ezért valódi kapcsolatot használjon a valódi szolgáltatáshoz. Amikor végre működik, tartsa a kitettséget ezen az egy porton: az SSH vagy egy adminpanel továbbítása, mert az első szabály kínosnak tűnt, sokkal nagyobb döntés, mint egy szolgáltatás közzététele.