SNAT, DNAT og Masquerade: hvad hver VPN-NAT-regel gør

Sæt en optagelse på begge sider af en VPN-gateway, og én strøm kan vise fire forskellige adresser. Kilde-NAT omskriver, hvor et pakke påstår, den kommer fra; destinations-NAT omskriver, hvor den skal hen. Masquerade er ikke en tredje retning, det er en kilde-NAT-regel, der tager sin adresse fra det udgående interface i stedet for en fast værdi. Navngiv, hvilken af de tre du faktisk har brug for, og de fleste «VPN virker ikke»-sager bliver til et spørgsmål om returvejen.

Hvad hver regel omskriver

Kilde-NAT, normalt skrevet SNAT, ændrer kilde-adressen på en strøm, når den forlader en router eller gateway. Tjenesten, der modtager, svarer til den oversatte adresse, og boksen, der oversætter, vender ændringen tilbage ved hjælp af den tilstand, den holdt for forbindelsen. På Linux bor den tilstand i conntrack, og derfor udskriver conntrack -L de oprindelige og svarende tupler side om side.

Destinations-NAT, DNAT, ændrer i stedet destinationen. En pakke adresseret til en offentlig adresse på UDP 51820 kan omskrives til en intern WireGuard-server på 10.8.0.2:51820. Sådan offentliggør en hjemmerouter eller en cloud-loadbalancer en VPN-lytter, og det siger intet om, hvad tunnelen må bære bagefter.

Masquerade hører til SNAT-familien. Reglen nævner ingen adresse; den bruger den, som det udgående interface har, når pakken forlader. Linux giver den sit eget mål, og det er det sædvanlige valg på et WAN-interface, der får sin adresse fra DHCP eller PPPoE.

Hvor kortlægningen bor, afgør fejlen

Noter tuplen ved hver grænse: før tunnelen, inde i den og på det offentlige interface. En optagelse inde i tunnelen adskiller sig legitimt fra en udenfor, og enhver, der sammenligner de to uden at vide, hvor oversættelsen sker, jager den forkerte vært.

Returtrafik skal passere gennem den enhed, der holder kortlægningen. Hvis svaret tager en anden rute, et andet uplink, en policy-rute eller en udbyder, der aldrig har hørt om dit private område, sker den tilstandsfulde omvendte oversættelse aldrig, og klienten ser ensrettet trafik. Mere kilde-NAT reparerer sjældent en manglende returrute; det kan skjule symptomet på én strøm og samtidig bryde adressebaseret politik alle andre steder.

Den anden hyppige fejl er at forvente, at en tunnel skaber routingmulighed. En privat klient, hvis pakker går ud på internettet, har brug for en gyldig udgangsordning: en standardrute, en videresendende gateway og normalt kildeoversættelse til en offentlig adresse. Kryptering alene gør ikke en privat adresse tilgængelig.

Masquerade eller eksplicit SNAT

Sammenlign de to på, hvad de lover. Masquerade vælger udgangsadressen, eksplicit SNAT fastlåser den. På en gateway med en stabil offentlig adresse giver fastlåsning logs og partner-allowlister én forudsigelig værdi. På et dynamisk WAN-link bliver en fastlåst SNAT-adresse forkert i det øjeblik, leasen skifter, og det er præcis det tilfælde, Masquerade blev bygget til.

Omfang betyder lige så meget som valget. En Masquerade-regel, der matcher hver pakke, der forlader gatewayen, uden kilde- eller destinationsgrænse, oversætter også trafik, du ville holde intakt, inklusive trafik til andre private netværk. Begræns reglen til klientområdet, den tilsigtede destination og interfacet.

Politikbaseret IPsec er der, hvor det bider hårdest. strongSwans vejledning i videresendelse går gennem aktivering af IP-videresendelse og tilføjelse af en kilde-NAT-regel til klienter, og samme dokumentation dækker udelukkelse af trafik, der skal beholde sin oprindelige adresse. Oversæt en kilde, før sikkerhedspolitikken matcher den, og tunnelen kan komme op, mens trafikken stadig droppes, fordi pakken ikke længere ligner den forhandlede selector.

Beslut også, hvad den fjerne ende skal se. Efter oversættelsen ser en tjeneste gatewayen, ikke den enkelte klient. Det forenkler retur-routing og udjævner samtidig logs og gør allowlister pr. klient virkningsløse. Hvis bevarelse af klientadresser betyder noget, planlæg en routet returvej i stedet for at skjule dem for at få en test til at bestå.

At læse reglerne på en Linux-gateway

En fjernadgangs-gateway med klienter på 10.8.0.0/24 og et WAN-interface ved navn eth0 har brug for aktiveret videresendelse og en filterpolitik, der tillader strømmen, før nogen NAT-regel kan hjælpe. iptables-versionen holder begge retninger i nat-tabellen:

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

nftables-formen bruger de samme to hooks med et navngivet interface og en eksplicit kæde:

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

Begge uddrag forudsætter, at filterkæden allerede accepterer den videresendte strøm. NAT er ikke en tilladelsesregel, og en korrekt oversat pakke kan stadig droppes en tabel senere. Bekræft den levende kortlægning med conntrack -L, bekræft hvad der er indlæst med nft list ruleset eller iptables-save -t nat, og optag derefter på begge interfaces for at se adressen faktisk ændre sig.

Fejltilstande, der ligner en dårlig regel

Hårnålstrafik er klassikeren. En intern klient, der når en intern server via serverens offentlige adresse, har brug for DNAT på vej ind og en kildeoversættelse på vej ud igen, ellers svarer serveren direkte til klienten, og svaret afvises. Rettelsen er en anden, snævrere regel for det interne-til-offentlige tilfælde, ikke en bredere Masquerade-regel for alt.

Dobbeltoversættelse er den stille. En klient, der allerede er bag carrier-grade NAT, ankommer til din gateway med en adresse, du ikke kan route tilbage, så du oversætter igen. Det virker, men logs bærer nu to hop af privat adressering, og enhver undersøgelse har brug for begge kortlægninger. Politikbaseret IPsec tilføjer et tredje twist: oversæt før politikkens match, og du får en SA, der er oppe uden trafik, hvilket læses som en firewall-fejl snarere end en NAT-fejl.

Så er der testen, der består, og udrulningen, der fejler. At køre NAT-kommandoen i hånden beviser mekanismen, ikke konfigurationen. En regel tilføjet under kørsel forsvinder ved genstart eller ved næste interface-hændelse, og en Masquerade-regel bundet til et interface, der omnummereres, kan lydløst ændre den adresse, den fjerne ende ser. Læg reglen i den ejende firewalls konfiguration, og test igen efter en genopkobling.

Tjekliste, før du gemmer reglen

Navngiv først retningen: kilde, destination eller begge. Identificér derefter, hvem der skal holde tilstanden — gatewayen, routeren ovenover eller IPsec-peeren — og bekræft, at returvejen kommer tilbage gennem den. Begræns reglen til det klientområde, den destination og det interface, du faktisk mener, og beslut på forhånd, om den fjerne ende skal se gatewayen eller klientens oprindelige adresse.

Test fra en klient, ikke fra gatewayen. En browser på gatewayen selv kan helt omgå klientoversættelsesreglen, så en side, der virker der, beviser intet om tunnelen. Send én anmodning, der stammer fra klienten, kig på tællerne og conntrack-tabellen, og gentag det efter en tunnel-genopkobling og en WAN-adresseændring, hvis en af delene er mulig der, hvor du arbejder.