SNAT, DNAT och Masquerade: vad varje VPN-NAT-regel gör

Sätt en fångst på båda sidor av en VPN-gateway och ett enda flöde kan visa fyra olika adresser. Käll-NAT skriver om varifrån ett paket påstår sig komma; mål-NAT skriver om vart det ska. Masquerade är inte en tredje riktning, det är en käll-NAT-regel som tar adressen från det utgående gränssnittet i stället för ett fast värde. Namnge vilken av de tre du faktiskt behöver och de flesta „VPN:et är trasigt“-ärenden krymper till en fråga om returvägen.

Vad varje regel skriver om

Käll-NAT, oftast skrivet SNAT, ändrar källadressen för ett flöde när det lämnar en router eller gateway. Tjänsten som tar emot svarar på den översatta adressen, och boxen som översätter vänder tillbaka ändringen med det tillstånd den höll för anslutningen. På Linux bor det tillståndet i conntrack, därför skriver conntrack -L ut de ursprungliga och svarande tuplarna sida vid sida.

Mål-NAT, DNAT, ändrar i stället målet. Ett paket adresserat till en offentlig adress på UDP 51820 kan skrivas om till en intern WireGuard-server på 10.8.0.2:51820. Så publicerar en hemrouter eller en molnlastbalanserare en VPN-lyssnare, och det säger ingenting om vad tunneln får bära efteråt.

Masquerade tillhör SNAT-familjen. Regeln namnger ingen adress; den använder den adress som det utgående gränssnittet har när paketet lämnar. Linux ger den ett eget mål, och det är det vanliga valet på ett WAN-gränssnitt som får sin adress via DHCP eller PPPoE.

Var kartläggningen bor avgör felet

Anteckna tuplen vid varje gräns: före tunneln, inuti den och på det offentliga gränssnittet. En fångst inuti tunneln skiljer sig legitimt från en utanför, och den som jämför de två utan att veta var översättningen sker jagar fel värd.

Returtrafik måste passera genom den enhet som håller kartläggningen. Om svaret tar en annan väg, en andra upplänk, en policyrutt eller en leverantör som aldrig har hört talas om ditt privata intervall, sker aldrig den tillståndsbaserade omvända översättningen och klienten ser enkelriktad trafik. Mer käll-NAT lagar sällan en saknad returväg; det kan dölja symptomet på ett flöde och samtidigt bryta adressbaserad policy överallt annars.

Det andra vanliga misstaget är att förvänta sig att en tunnel skapar routbarhet. En privat klient vars paket går ut på internet behöver en giltig utgående ordning: en standardrutt, en gateway som vidarebefordrar och vanligtvis källöversättning till en offentlig adress. Kryptering i sig gör inte en privat adress nåbar.

Masquerade eller explicit SNAT

Jämför de två efter vad de lovar. Masquerade väljer utgångsadressen, explicit SNAT fäster den. På en gateway med en stabil offentlig adress ger fästet loggar och partnerlistor ett förutsägbart värde. På en dynamisk WAN-länk blir en fäst SNAT-adress fel i samma stund som lånet ändras, och det är precis det fallet Masquerade byggdes för.

Omfånget spelar lika stor roll som valet. En Masquerade-regel som matchar varje paket som lämnar gatewayen, utan käll- eller målgräns, översätter också trafik du menade att lämna orörd, inklusive trafik till andra privata nät. Begränsa regeln till klientintervallet, det avsedda målet och gränssnittet.

Med policybaserad IPsec biter det hårdast. strongSwans guide för vidarebefordran går igenom att aktivera IP-vidarebefordran och lägga till en käll-NAT-regel för klienter, och samma dokumentation täcker att undanta trafik som måste behålla sin ursprungliga adress. Översätt en källa innan säkerhetspolicyn matchar den, och tunneln kan komma upp medan trafiken fortfarande faller, eftersom paketet inte längre ser ut som den förhandlade väljaren.

Bestäm också vad den bortre änden ska se. Efter översättningen ser en tjänst gatewayen, inte den enskilda klienten. Det förenklar returroutning och jämnar samtidigt ut loggar och gör tillåtelselistor per klient verkningslösa. Om det är viktigt att bevara klientadresser, planera en routad returväg i stället för att gömma dem för att få ett test att gå igenom.

Att läsa reglerna på en Linux-gateway

En fjärråtkomstgateway med klienter på 10.8.0.0/24 och ett WAN-gränssnitt som heter eth0 behöver aktiverad vidarebefordran och en filterpolicy som tillåter flödet, innan någon NAT-regel kan hjälpa. iptables-versionen håller båda riktningarna 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 använder samma två krokar med ett namngivet gränssnitt och en explicit kedja:

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

Båda utdragen förutsätter att filterkedjan redan accepterar det vidarebefordrade flödet. NAT är ingen tillåtelseregel, och ett korrekt översatt paket kan fortfarande slängas en tabell senare. Bekräfta den levande kartläggningen med conntrack -L, bekräfta vad som är laddat med nft list ruleset eller iptables-save -t nat, och fånga sedan på båda gränssnitten för att se att adressen verkligen ändras.

Fellägen som ser ut som en dålig regel

Hårnålstrafik är klassikern. En intern klient som når en intern server via serverns offentliga adress behöver DNAT på väg in och en källöversättning på väg ut igen, annars svarar servern rakt till klienten och svaret avvisas. Rättelsen är en andra, snävare regel för det fallet internt-till-offentligt, inte en bredare Masquerade-regel för allt.

Dubbel översättning är den tysta. En klient som redan ligger bakom operatörsnivå-NAT kommer till din gateway med en adress du inte kan routa tillbaka, så du översätter igen. Det fungerar, men loggarna bär nu två hopp av privat adressering och varje utredning behöver båda kartläggningarna. Policybaserad IPsec lägger till en tredje vridning: översätt före policymatchningen och du får en SA som står uppe utan att trafik passerar, vilket läses som en brandväggsbugg och inte en NAT-bugg.

Sedan finns testet som går igenom och driftsättningen som misslyckas. Att köra NAT-kommandot för hand bevisar mekanismen, inte konfigurationen. En regel som läggs till under drift försvinner vid omstart eller vid nästa gränssnittshändelse, och en Masquerade-regel knuten till ett gränssnitt som numreras om kan tyst ändra adressen som den bortre änden ser. Lägg regeln i konfigurationen för brandväggen som äger den och testa igen efter en återanslutning.

Checklista innan du sparar regeln

Namnge riktningen först: källa, mål eller båda. Bestäm sedan vem som måste hålla tillståndet — gatewayen, routern ovanför eller IPsec-motparten — och bekräfta att svarsvägen kommer tillbaka genom den. Begränsa regeln till klientintervallet, målet och gränssnittet som du faktiskt menar, och bestäm i förväg om den bortre änden ska se gatewayen eller klientens ursprungliga adress.

Testa från en klient, inte från gatewayen. En webbläsare på gatewayen själv kan kringgå klientöversättningsregeln helt, så en sida som fungerar där bevisar ingenting om tunneln. Skicka en förfrågan som kommer från klienten, följ räknarna och conntrack-tabellen, och upprepa efter en återanslutning av tunneln och en ändring av WAN-adressen om något av det är möjligt där du arbetar.