Porttovábbítás NAT mögötti WireGuard-peerhez: DNAT plusz SNAT

Egy böngésző a https://203.0.113.10:8443 címet kéri, a proxy elfogadja a kapcsolatot, és a WireGuard-peer szolgáltatása soha nem válaszol. A DNAT-szabály végzi a dolgát; a válasz az a rész, amely meghiúsul. Kövesse végig a csomagot mindkét fordításban, és a hiányzó szabály nyilvánvalóvá válik. A javítás egy további NAT-utasítás a megfelelő hookban, nem új alagút.

Kövessen végig egy kérést elejétől a végéig

A kérés a proxy nyilvános interfészére érkezik, forrásként az ügyfél nyilvános címével, célként a proxy címével. A nat PREROUTING szakaszban a DNAT-szabály átírja a célt a peer alagútcímére, 10.90.0.2-re. Ezután az útválasztási döntés kiküldi a csomagot a wg0 interfészen, és a továbbítási útvonal elkészül.

A peeren a csomag most az eredeti nyilvános forráscímet hordozza, mert semmi nem írta át. A szolgáltatás elfogadja a kapcsolatot, és a válaszát a saját alapértelmezett átjárójára küldi, amely a peer előtti otthoni router. Annak a routernek nincs állapota egy olyan folyamhoz, amelyet soha nem látott, ezért vagy eldobja a csomagot, vagy lefordítja a saját nyilvános címére, amit az ügyfél nem fog elfogadni.

Az aszimmetria a teljes probléma: a kérés a proxyn keresztül megy, a válasz pedig közvetlenül próbál menni. A proxy kapcsolatkövetése csak akkor segít, ha a válasz a proxyn keresztül tér vissza, és addig nem tud oda visszatérni, amíg a forráscím még az eredeti ügyfélre mutat.

Adja hozzá a visszafordítást

Írja át a továbbított folyam forrását a proxy alagútcímére, mielőtt a peer felé elindul. Ezután a szolgáltatás a 10.90.0.1 címre válaszol, a proxy fogadja, és a kapcsolatkövetés visszafordítja mindkét fordítást, mielőtt a csomag visszatér az ügyfélhez.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

A POSTROUTING szabály szándékosan szűk: a lefordított célra és az alagút interfészére illeszkedik, így nem írja át a véletlenül a wg0-n kilépő, nem kapcsolódó forgalmat. Egy széles masquerade-szabály szintén elrejtené az ügyfél címét, de ezt minden folyamra megtenné, és nehezebbé tenné a NAT-tábla auditálását.

Helyezze a szabályokat oda, ahol az alagút létezik

Az alagút címére vagy interfészére hivatkozó szabályoknak azután kell futniuk, hogy a wg-quick beállította. Az interfész a PreUp előtt jön létre, de a címek, az MTU, a DNS és az útvonalak utána kerülnek alkalmazásra, a PostUp pedig akkor fut, amikor mindez a helyén van. A hozzáadásokat a PostUp alá, a törléseket a PreDown alá tegye.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

A törléseknek tokenről tokenre meg kell egyezniük a hozzáadásokkal, beleértve a multiport- és interfész-egyezéseket. Egy egyezésben eltérő törlés semmit nem távolít el, és a következő újracsatlakozás hozzáadja a szabály második példányát. Néhány újracsatlakozás után a tábla olyan duplikátumokat tartalmaz, amelyeket nehéz egy konfigurációs sorhoz rendelni.

Ellenőrizze az eredményt a iptables -t nat -S segítségével egy újracsatlakozás után. Ha ugyanaz a szabály kétszer jelenik meg, a PreDown sor nem illeszkedik, és a tisztítás csendben meghiúsul.

Továbbítás, szűrés és a másik NAT

Kapcsolja be tartósan az IPv4-továbbítást, majd engedélyezze a továbbított folyamot a szűrőtáblában. A DNAT a FORWARD lánc előtt történik, ezért a szűrőszabály a lefordított célra illeszkedik, nem a nyilvános címre. Ha az UFW kezeli a tűzfalat, fejezze ki az engedélyt útvonal-szabályként; egy egyszerű host-szabály nem fedi le a továbbított forgalmat.

Két másik NAT-réteg továbbra is eltörheti az utat, még ha a proxy szabályai helyesek is. Otthoni kapcsolatnál a nyilvános cím a routeré, és a port megnyitása a tűzfalában nem ugyanaz, mint egy porttovábbítási bejegyzés létrehozása, amely azt a portot a proxyhoz küldi. Egy kívülről nyitottnak látszó port, amelyre semmi nem válaszol, gyakran éppen ezt a leképezést nélkülözi.

NAT VPS-en a szolgáltató egy nyilvános portot magáncímre képez le. A leképezésnek meg kell egyeznie a hirdetett porttal, és az eltérés pontosan úgy néz ki, mint egy törött alagút. A WireGuard-konfiguráció módosítása előtt erősítse meg a szolgáltató leképezését.

Ellenőrizze a visszautat, és fogadja el az árat

Csatlakozzon olyan hálózatról, amely nem a proxy LAN-ja, majd vizsgálja meg a fordítási párt, amíg a kapcsolat nyitva van:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

A conntrack bejegyzésnek az eredeti tuple-t, a lefordított tuple-t és a válasz irányát kell mutatnia. Ha a válasz hiányzik, a peer nem küld az alagúton keresztül, ami általában azt jelenti, hogy az SNAT-szabály nem érvényesült, vagy a peer saját tűzfala eldobta a folyamot.

Indítsa újra egyszer, hogy bizonyítsa, a PostUp újra alkalmazza a szabályokat, majd állítsa le az alagutat, és erősítse meg, hogy a PreDown eltávolította őket. A kapcsolatbontást túlélő halott szabályok az oka annak, hogy egy későbbi változtatás kiszámíthatatlanul viselkedik.

Végül fogadja el, mibe kerül a SNAT. A szolgáltatás minden kérést a proxytól érkezőnek lát, ezért a hozzáférési naplók, az ügyfelenkénti sebességkorlátok és az engedélyezett címek listái már nem különböztetik meg a felhasználókat. A hairpin eset saját forrásfordítást igényel a proxy LAN-ján lévő ügyfelek számára. Ha a peernek valódi ügyfélcímekre van szüksége, az alternatíva egy visszaútvonal az ügyfél hálózatához, ami több munka, de megőrzi az információt.