SNAT, DNAT és Masquerade: mit tesz az egyes VPN-NAT-szabály

Tegyen rögzítést a VPN-átjáró mindkét oldalára, és egyetlen folyam négy különböző címet mutathat. A forrás-NAT átírja, honnan állítja a csomag, hogy jön; a cél-NAT átírja, hová megy. A Masquerade nem harmadik irány, hanem forrás-NAT szabály, amely a címet a kimenő interfészről veszi fix érték helyett. Nevezze meg, melyikre van valóban szüksége a háromból, és a legtöbb „a VPN elromlott” jegy a visszaútra vonatkozó kérdéssé szűkül.

Mit ír át az egyes szabályok

A forrás-NAT, amelyet általában SNAT-nak írnak, a folyam forráscímét változtatja meg, amikor elhagy egy routert vagy átjárót. A fogadó szolgáltatás a lefordított címre válaszol, és a fordító doboz az adott kapcsolathoz tartott állapot segítségével visszafordítja a változtatást. Linuxon ez az állapot a conntrackben él, ezért a conntrack -L egymás mellett írja ki az eredeti és a válasz tuple-t.

A cél-NAT, a DNAT, ehelyett a célt változtatja meg. Az UDP 51820-on egy nyilvános címre küldött csomag átírható egy belső WireGuard-kiszolgálóra a 10.8.0.2:51820 címen. Így tesz közzé egy otthoni router vagy egy felhő-terheléselosztó VPN-figyelőt, és ez semmit nem mond arról, mit szállíthat az alagút utána.

A Masquerade az SNAT családba tartozik. A szabály nem nevez meg címet; azt használja, amely a kimenő interfészen van, amikor a csomag elmegy. A Linux saját célpontot ad neki, és ez a szokásos választás olyan WAN-interfészen, amely DHCP-től vagy PPPoE-től kap címet.

Attól függ a hiba, hol él a leképezés

Jegyezze fel a tuple-t minden határon: az alagút előtt, benne és a nyilvános interfészen. Az alagúton belüli rögzítés jogosan különbözik a kívülitől, és aki a kettőt anélkül hasonlítja össze, hogy tudná, hol történik a fordítás, rossz gazdagép után fog menni.

A visszirányú forgalomnak át kell haladnia azon az eszközön, amely a leképezést tartja. Ha a válasz más útvonalat, második feltöltő kapcsolatot, szabályzati útvonalat vagy olyan szolgáltatót választ, amely soha nem hallott a privát tartományáról, az állapottal működő fordított fordítás soha nem történik meg, és az ügyfél egyirányú forgalmat lát. Több forrás-NAT ritkán javítja a hiányzó visszaútvonalat; elrejtheti a tünetet egy folyamon, miközben mindenhol máshol elrontja a címalapú szabályzatot.

A másik gyakori hiba azt várni, hogy az alagút útvonalképességet teremt. Az a privát ügyfél, amelynek csomagjai az internetre mennek, érvényes kimeneti elrendezést igényel: alapértelmezett útvonalat, továbbító átjárót és általában forrásfordítást egy nyilvános címre. A titkosítás önmagában nem teszi elérhetővé a privát címet.

Masquerade vagy explicit SNAT

Hasonlítsa össze őket az alapján, mit ígérnek. A Masquerade kiválasztja a kimenő címet, az explicit SNAT rögzíti. Stabil nyilvános című átjárón a rögzítés egyetlen kiszámítható értéket ad a naplóknak és a partnerek engedélylistáinak. Dinamikus WAN-kapcsolaton a rögzített SNAT-cím abban a pillanatban válik hibássá, amikor a bérlet megváltozik, és a Masquerade éppen erre az esetre készült.

A hatókör ugyanolyan fontos, mint a választás. Az a Masquerade-szabály, amely az átjárót elhagyó minden csomagra illeszkedik, forrás- vagy célkorlát nélkül, átfordítja az érintetlenül hagyni kívánt forgalmat is, beleértve a más privát hálózatok felé menő forgalmat. Korlátozza a szabályt az ügyfélkörre, a szándékolt célra és az interfészre.

A szabályzatalapú IPsec az, ahol ez a legjobban harap. A strongSwan továbbítási útmutatója végigveszi az IP-továbbítás bekapcsolását és a forrás-NAT-szabály hozzáadását az ügyfelekhez, és ugyanez a dokumentáció kiterjed az eredeti címét megtartani köteles forgalom kizárására. Fordítsa le a forrást, mielőtt a biztonsági szabályzat illeszkedne rá, és az alagút felállhat, miközben a forgalom továbbra is elesik, mert a csomag már nem hasonlít a tárgyalt szelektorra.

Azt is döntse el, mit lásson a távoli vég. A fordítás után a szolgáltatás az átjárót látja, nem az egyes ügyfelet. Ez egyszerűsíti a visszaútvonal-kezelést, és ugyanakkor ellapítja a naplókat és hatástalanítja az ügyfelenkénti engedélylistákat. Ha az ügyfélcímek megőrzése számít, tervezzen irányított visszaútvonalat ahelyett, hogy elrejtené őket egy teszt átmenete érdekében.

A szabályok olvasása Linux-átjárón

A távoli hozzáférésű átjárónak, amelynek ügyfelei a 10.8.0.0/24-en vannak és WAN-interfésze eth0 néven fut, bekapcsolt továbbításra és a folyamot engedélyező szűrőszabályzatra van szüksége, mielőtt bármely NAT-szabály segíthet. Az iptables változat mindkét irányt a nat táblában tartja:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

Az nftables forma ugyanazt a két horgot használja elnevezett interfésszel és explicit lánccal:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Mindkét részlet feltételezi, hogy a szűrőlánc már elfogadja a továbbított folyamot. A NAT nem engedélyező szabály, és egy helyesen lefordított csomag egy táblával később még eldobható. Erősítse meg az élő leképezést a conntrack -L paranccsal, ellenőrizze, mi van betöltve a nft list ruleset vagy iptables-save -t nat paranccsal, majd rögzítsen mindkét interfészen, hogy lássa, a cím valóban változik.

Hibamódok, amelyek rossz szabálynak látszanak

A hajtűforgalom a klasszikus. Az a belső ügyfél, amely a kiszolgáló nyilvános címén keresztül ér el egy belső kiszolgálót, befelé a DNAT-ra és kifelé a forrásfordításra szorul, különben a kiszolgáló egyenesen az ügyfélnek válaszol, és a válasz elutasításra kerül. A javítás egy második, szűkebb szabály erre a belsőből nyilvánosba esetre, nem egy szélesebb Masquerade-szabály mindenre.

A kettős fordítás a csendes. Az az ügyfél, amely már szolgáltatói szintű NAT mögött van, olyan címmel érkezik az átjárójához, amelyet nem tud visszairányítani, ezért újra fordít. Működik, de a naplók most két ugrást hordoznak privát címzésből, és minden vizsgálathoz mindkét leképezés kell. A szabályzatalapú IPsec harmadik csavart ad hozzá: fordítson a szabályzati egyezés előtt, és olyan SA-t kap, amely fel van állva, miközben nem megy át forgalom, ami tűzfalhibának látszik, nem NAT-hibának.

Aztán ott van a teszt, amely átmegy, és a telepítés, amely elbukik. A NAT-parancs kézi futtatása a mechanizmust bizonyítja, nem a konfigurációt. A futásidőben hozzáadott szabály eltűnik újraindításkor vagy a következő interfészeseménynél, és az újraszámozódó interfészhez kötött Masquerade-szabály csendben megváltoztathatja a címet, amelyet a távoli vég lát. Tegye a szabályt a tulajdonos tűzfal konfigurációjába, és tesztelje újra újracsatlakozás után.

Ellenőrzőlista a szabály mentése előtt

Először nevezze meg az irányt: forrás, cél vagy mindkettő. Aztán határozza meg, kinek kell tartania az állapotot — az átjárónak, a felette lévő routernek vagy az IPsec-társnak —, és erősítse meg, hogy a válaszút rajta keresztül tér vissza. Korlátozza a szabályt arra az ügyfélkörre, célra és interfészre, amelyet valóban szeretne, és döntse el előre, hogy a távoli végnek az átjárót vagy az eredeti ügyfélcímet kell-e látnia.

Ügyfélről teszteljen, ne az átjáróról. Az átjárón futó böngésző teljesen megkerülheti az ügyfélfordítási szabályt, ezért az ott működő oldal semmit nem bizonyít az alagútról. Küldjön egy ügyfélről induló kérést, figyelje a számlálókat és a conntrack táblát, és ismételje meg az alagút újracsatlakozása és a WAN-cím változása után, ha valamelyik lehetséges a munkahelyén.