SNAT, DNAT a Masquerade: čo robí každé pravidlo NAT vo VPN

Umiestnite zachytávanie na obe strany VPN brány a jeden tok môže ukázať štyri rôzne adresy. Zdrojový NAT prepisuje, odkiaľ paket tvrdí, že prichádza; cieľový NAT prepisuje, kam ide. Masquerade nie je tretí smer, je to pravidlo zdrojového NAT, ktoré berie adresu z odchádzajúceho rozhrania namiesto pevnej hodnoty. Pomenujte, ktoré z troch skutočne potrebujete, a väčšina tiketov „VPN je pokazená“ sa zúži na otázku o spiatočnej ceste.

Čo prepisuje každé pravidlo

Zdrojový NAT, zvyčajne písaný SNAT, mení zdrojovú adresu toku, keď opúšťa smerovač alebo bránu. Prijímajúca služba odpovedá na preloženú adresu a box, ktorý prekladá, zmenu obráti pomocou stavu, ktorý si pre toto spojenie uchoval. V Linuxe tento stav žije v conntracku, preto conntrack -L vypisuje pôvodné a odpovedné n-tice vedľa seba.

Cieľový NAT, DNAT, mení namiesto toho cieľ. Paket adresovaný verejnej adrese na UDP 51820 možno prepísať na interný server WireGuard na 10.8.0.2:51820. Tak domáci smerovač alebo cloudový balancer zverejňuje VPN poslucháča, a to nič nehovorí o tom, čo tunel môže niesť potom.

Masquerade patrí do rodiny SNAT. Pravidlo neuvádza žiadnu adresu; použije tú, ktorú má odchádzajúce rozhranie pri odchode paketu. Linux mu dáva vlastný cieľ a je to obvyklá voľba na rozhraní WAN, ktoré adresu dostáva z DHCP alebo PPPoE.

Kde mapovanie žije, rozhoduje o zlyhaní

Zaznamenajte n-ticu na každej hranici: pred tunelom, v ňom a na verejnom rozhraní. Zachytávanie vnútri tunela sa oprávnene líši od toho vonku, a kto obe porovnáva bez toho, aby vedel, kde preklad prebieha, bude naháňať nesprávneho hostiteľa.

Spiatočná prevádzka musí prejsť zariadením, ktoré drží mapovanie. Ak odpoveď ide inou cestou, druhým uplinkom, cestou podľa politiky alebo poskytovateľom, ktorý o vašom privátnom rozsahu nikdy nepočul, stavový spätný preklad nikdy nenastane a klient vidí jednosmernú prevádzku. Pridanie ďalšieho zdrojového NAT zriedka opraví chýbajúcu spiatočnú cestu; môže skryť príznak na jednom toku a inde rozbiť politiku založenú na adresách.

Ďalšou častou chybou je očakávať, že tunel vytvorí smerovateľnosť. Privátny klient, ktorého pakety vychádzajú do internetu, potrebuje platné výstupné usporiadanie: predvolenú trasu, preposielajúcu bránu a zvyčajne zdrojový preklad na verejnú adresu. Šifrovanie samo osebe privátnu adresu dostupnou neurobí.

Masquerade alebo explicitný SNAT

Porovnajte ich podľa toho, čo sľubujú. Masquerade vyberá výstupnú adresu, explicitný SNAT ju fixuje. Na bráne so stabilnou verejnou adresou dáva fixácia logom a partnerským zoznamom povolených jednu predvídateľnú hodnotu. Na dynamickom WAN spoji sa fixnutá adresa SNAT stane nesprávnou v okamihu, keď sa zmení lease, a presne pre tento prípad bol Masquerade vytvorený.

Rozsah je rovnako dôležitý ako voľba. Pravidlo Masquerade zodpovedajúce každému paketu, ktorý opustí bránu, bez obmedzenia zdroja či cieľa, prekladá aj prevádzku, ktorú ste chceli nechať nedotknutú, vrátane prevádzky do iných privátnych sietí. Obmedzte pravidlo na rozsah klientov, zamýšľaný cieľ a rozhranie.

Pri IPsec založenom na politikách to hryzie najviac. Príručka strongSwan k preposielaniu prechádza zapnutím preposielania IP a pridaním pravidla zdrojového NAT pre klientov a tá istá dokumentácia pokrýva vylúčenie prevádzky, ktorá si musí ponechať pôvodnú adresu. Preložte zdroj skôr, než sa s ním zhoduje bezpečnostná politika, a tunel môže nabehnúť, zatiaľ čo prevádzka stále padá, pretože paket už nevyzerá ako vyjednaný selektor.

Rozhodnite aj, čo má vidieť vzdialený koniec. Po preklade služba vidí bránu, nie jednotlivého klienta. To zjednodušuje spätné smerovanie a zároveň splošťuje logy a ruší zoznamy povolených pre jednotlivých klientov. Ak je zachovanie klientskych adries dôležité, naplánujte smerovanú spiatočnú cestu namiesto toho, aby ste ich skrývali, aby test prešiel.

Ako čítať pravidlá na Linux bráne

Brána vzdialeného prístupu s klientmi v 10.8.0.0/24 a rozhraním WAN menom eth0 potrebuje zapnuté preposielanie a filtrovaciu politiku, ktorá tok povolí, až potom môže akékoľvek pravidlo NAT pomôcť. Verzia s iptables drží oba smery v tabuľke 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žíva rovnaké dva háčiky s pomenovaným rozhraním a explicitnou reťazou:

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 predpokladajú, že filtrovacia reťaz už preposielaný tok prijíma. NAT nie je pravidlo povolenia a správne preložený paket môže byť o tabuľku neskôr stále zahodený. Overte živé mapovanie pomocou conntrack -L, overte, čo je načítané, pomocou nft list ruleset alebo iptables-save -t nat, a potom zachyťte na oboch rozhraniach, aby ste videli, že sa adresa skutočne mení.

Režimy zlyhania, ktoré vyzerajú ako zlé pravidlo

Prevádzka typu vlásenky je klasika. Interný klient, ktorý sa k internému serveru dostáva cez verejnú adresu servera, potrebuje DNAT na ceste dnu a zdrojový preklad na ceste von, inak server odpovedá priamo klientovi a odpoveď je odmietnutá. Opravou je druhé, užšie pravidlo pre tento prípad interné-k-verejnému, nie širšie pravidlo Masquerade pre všetko.

Dvojitý preklad je ten tichý. Klient, ktorý je už za NAT na úrovni operátora, prichádza na vašu bránu s adresou, ktorú nedokážete smerovať späť, takže prekladáte znova. Funguje to, ale logy teraz nesú dva skoky privátneho adresovania a každé vyšetrovanie potrebuje obe mapovania. IPsec založený na politikách pridáva tretí obrat: preložte pred zhodou politiky a dostanete SA, ktoré je hore bez prevádzky, čo sa číta ako chyba firewallu, nie NAT.

Potom je tu test, ktorý prejde, a nasadenie, ktoré zlyhá. Ručné spustenie príkazu NAT dokazuje mechanizmus, nie konfiguráciu. Pravidlo pridané za behu zmizne pri reštarte alebo pri ďalšej udalosti rozhrania a pravidlo Masquerade naviazané na rozhranie, ktoré mení číslo, môže ticho zmeniť adresu, ktorú vzdialený koniec vidí. Dajte pravidlo do konfigurácie vlastniaceho firewallu a otestujte znova po opätovnom pripojení.

Kontrolný zoznam pred uložením pravidla

Najprv pomenujte smer: zdroj, cieľ alebo oboje. Potom určte, kto musí držať stav — brána, smerovač nad ňou alebo partner IPsec — a overte, že sa spiatočná cesta vracia cez neho. Obmedzte pravidlo na rozsah klientov, cieľ a rozhranie, ktoré skutočne máte na mysli, a vopred rozhodnite, či má vzdialený koniec vidieť bránu alebo pôvodnú adresu klienta.

Testujte z klienta, nie z brány. Prehliadač priamo na bráne môže úplne obísť pravidlo prekladu pre klientov, takže fungujúca stránka tam o tuneli nič nedokazuje. Pošlite jednu požiadavku vzniknutú u klienta, sledujte počítadlá a tabuľku conntrack a zopakujte to po opätovnom pripojení tunela a zmene adresy WAN, ak je niečo z toho tam, kde pracujete, možné.