SNAT, DNAT a Masquerade: co dělá každé pravidlo VPN NAT

Zachyťte provoz na obou stranách VPN brány a jeden tok může ukázat čtyři různé adresy. Zdrojový NAT přepisuje, odkud paket tvrdí, že přichází; cílový NAT přepisuje, kam jde. Masquerade není třetí směr, je to pravidlo zdrojového NAT, které bere adresu z odchozího rozhraní místo pevné hodnoty. Pojmenujte, které ze tří skutečně potřebujete, a většina tiketů „VPN je rozbitá“ se zúží na otázku o zpětné cestě.

Co každé pravidlo přepisuje

Zdrojový NAT, obvykle psaný SNAT, mění zdrojovou adresu toku, když opouští router nebo bránu. Přijímající služba odpovídá na přeloženou adresu a box, který překládá, změnu obrátí pomocí stavu, který si pro toto spojení uchoval. V Linuxu tento stav žije v conntracku, proto conntrack -L vypisuje původní a odpovědní n-tice vedle sebe.

Cílový NAT, DNAT, mění místo toho cíl. Paket adresovaný veřejné adrese na UDP 51820 lze přepsat na interní server WireGuard na 10.8.0.2:51820. Tak domácí router nebo cloudový balancer zveřejňuje VPN posluchač, a to nic neříká o tom, co tunel může přenášet potom.

Masquerade patří do rodiny SNAT. Pravidlo nepojmenovává žádnou adresu; použije tu, kterou má odchozí rozhraní, když paket vychází. Linux mu dává vlastní cíl a je to obvyklá volba na rozhraní WAN, které adresu dostává z DHCP nebo PPPoE.

Kde mapování žije, rozhoduje o selhání

Zaznamenejte n-tici na každé hranici: před tunelem, uvnitř něj a na veřejném rozhraní. Zachycení uvnitř tunelu se oprávněně liší od toho vně a každý, kdo obě porovnává, aniž ví, kde překlad probíhá, bude honit špatného hostitele.

Zpětný provoz musí projít zařízením, které drží mapování. Pokud odpověď jde jinou cestou, druhým uplinkem, cestou podle politiky nebo poskytovatelem, který o vašem privátním rozsahu nikdy neslyšel, stavový zpětný překlad nikdy nenastane a klient vidí jednosměrný provoz. Přidání dalšího zdrojového NAT zřídka opraví chybějící zpětnou cestu; může skrýt symptom na jednom toku, zatímco jinde rozbije politiku založenou na adresách.

Další častou chybou je očekávat, že tunel vytvoří směrovatelnost. Privátní klient, jehož pakety vycházejí do internetu, potřebuje platné výstupní uspořádání: výchozí trasu, předávající bránu a obvykle zdrojový překlad na veřejnou adresu. Šifrování samo o sobě privátní adresu dostupnou neudělá.

Masquerade, nebo explicitní SNAT

Porovnejte je podle toho, co slibují. Masquerade vybírá výstupní adresu, explicitní SNAT ji připíná. Na bráně se stabilní veřejnou adresou dává připnutí logům a partnerským seznamům povolených jednu předvídatelnou hodnotu. Na dynamickém WAN spoji se připnutá adresa SNAT stane nesprávnou ve chvíli, kdy se změní lease, a přesně pro tento případ byl Masquerade vytvořen.

Rozsah je stejně důležitý jako volba. Pravidlo Masquerade odpovídající každému paketu, který opustí bránu, bez omezení zdroje či cíle, překládá i provoz, který jste chtěli nechat nedotčený, včetně provozu do jiných privátních sítí. Omezte pravidlo na rozsah klientů, zamýšlený cíl a rozhraní.

Nejvíc to bolí u IPsec založeného na politikách. Příručka strongSwan k předávání prochází zapnutím IP forwardingu a přidáním pravidla zdrojového NAT pro klienty a táž dokumentace pokrývá vyloučení provozu, který si musí ponechat původní adresu. Přeložte zdroj dřív, než ho politika zabezpečení zachytí, a tunel může naběhnout, zatímco provoz stále padá, protože paket už nevypadá jako vyjednaný selektor.

Rozhodněte také, co má vidět vzdálený konec. Po překladu služba vidí bránu, ne jednotlivého klienta. To zjednodušuje zpětný routing a zároveň zplošťuje logy a ruší seznamy povolených pro jednotlivé klienty. Pokud je zachování klientských adres důležité, naplánujte routovanou zpětnou cestu, místo abyste je skrývali, aby test prošel.

Jak číst pravidla na Linux bráně

Brána vzdáleného přístupu s klienty na 10.8.0.0/24 a rozhraním WAN jménem eth0 potřebuje zapnuté předávání a filtrovací politiku, která tok povolí, než může jakékoli NAT pravidlo pomoci. Verze s iptables drží oba směry v tabulce nat:

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

Forma nftables používá stejné dva háčky s pojmenovaným rozhraním a explicitním řetězcem:

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

Oba úryvky předpokládají, že filtrovací řetězec už předávaný tok přijímá. NAT není pravidlo povolení a správně přeložený paket může být o jednu tabulku dál stejně zahozen. Ověřte živé mapování pomocí conntrack -L, ověřte, co je načteno, pomocí nft list ruleset nebo iptables-save -t nat, a pak zachyťte na obou rozhraních, abyste viděli, že se adresa skutečně mění.

Režimy selhání, které vypadají jako špatné pravidlo

Provoz typu vlásenky je klasika. Interní klient, který se k internímu serveru dostává přes veřejnou adresu serveru, potřebuje DNAT na cestě dovnitř a zdrojový překlad na cestě zpět ven, jinak server odpoví přímo klientovi a odpověď je odmítnuta. Opravou je druhé, užší pravidlo pro tento případ interní-k-veřejnému, ne širší pravidlo Masquerade pro všechno.

Dvojitý překlad je ten tichý. Klient, který už je za NAT operátorské úrovně, dorazí na vaši bránu s adresou, kterou nelze směrovat zpět, takže překládáte znovu. Funguje to, ale logy teď nesou dva skoky privátního adresování a každé vyšetřování potřebuje obě mapování. IPsec založený na politikách přidává třetí obrat: přeložte před shodou s politikou a dostanete SA, které je nahoře a přitom neprochází provoz, což vypadá jako chyba firewallu, ne NAT.

Pak je tu test, který projde, a nasazení, které selže. Ruční spuštění NAT příkazu dokazuje mechanismus, ne konfiguraci. Pravidlo přidané za běhu zmizí při restartu nebo při další události rozhraní a pravidlo Masquerade navázané na rozhraní, které mění číslo, může tiše změnit adresu, kterou vzdálený konec vidí. Dejte pravidlo do konfigurace vlastnícího firewallu a otestujte znovu po opětovném připojení.

Kontrolní seznam před uložením pravidla

Nejprve pojmenujte směr: zdroj, cíl, nebo obojí. Pak určete, kdo musí držet stav — brána, nadřazený router nebo protějšek IPsec — a ověřte, že se zpětná cesta vrací přes něj. Omezte pravidlo na rozsah klientů, cíl a rozhraní, které skutečně zamýšlíte, a předem rozhodněte, zda má vzdálený konec vidět bránu, nebo původní adresu klienta.

Testujte z klienta, ne z brány. Prohlížeč přímo na bráně může pravidlo překladu pro klienty úplně obejít, takže fungující stránka tam o tunelu nic nedokazuje. Pošlete jeden požadavek vzniklý u klienta, sledujte čítače a tabulku conntrack a zopakujte to po opětovném připojení tunelu a změně adresy WAN, pokud je některé z toho tam, kde pracujete, možné.