SNAT, DNAT en Masquerade: wat elke VPN-NAT-regel doet

Zet een capture aan beide kanten van een VPN-gateway en één stroom kan vier verschillende adressen laten zien. Bron-NAT herschrijft waar een pakket zegt vandaan te komen; bestemmings-NAT herschrijft waar het heen gaat. Masquerade is geen derde richting, het is een bron-NAT-regel die zijn adres van de uitgaande interface haalt in plaats van een vaste waarde. Benoem welke van de drie je echt nodig hebt en de meeste „de VPN is stuk”-tickets worden een vraag over de retourweg.

Wat elke regel herschrijft

Bron-NAT, meestal SNAT genoemd, verandert het bronadres van een stroom wanneer die een router of gateway verlaat. De ontvangende dienst antwoordt op het vertaalde adres, en de doos die vertaalt draait de wijziging terug met de toestand die hij voor die verbinding bewaarde. Op Linux leeft die toestand in conntrack, daarom drukt conntrack -L de originele en antwoordtupels naast elkaar af.

Bestemmings-NAT, DNAT, verandert in plaats daarvan de bestemming. Een pakket dat naar een openbaar adres op UDP 51820 is geadresseerd, kan worden herschreven naar een interne WireGuard-server op 10.8.0.2:51820. Zo publiceert een thuisrouter of cloud-loadbalancer een VPN-listener, en dat zegt niets over wat de tunnel daarna mag dragen.

Masquerade hoort bij de SNAT-familie. De regel noemt geen adres; hij gebruikt welk adres de uitgaande interface ook heeft op het moment dat het pakket vertrekt. Linux geeft hem een eigen doel, en het is de gebruikelijke keuze op een WAN-interface die zijn adres via DHCP of PPPoE krijgt.

Waar de mapping leeft, bepaalt de fout

Noteer het tupel bij elke grens: vóór de tunnel, erin en op de openbare interface. Een capture in de tunnel verschilt legitiem van een erbuiten, en wie de twee vergelijkt zonder te weten waar de vertaling gebeurt, jaagt op de verkeerde host.

Retourverkeer moet door het apparaat dat de mapping houdt. Als het antwoord een andere route neemt, een tweede uplink, een policy-route of een provider die nog nooit van jouw privébereik heeft gehoord, gebeurt de stateful omgekeerde vertaling nooit en ziet de client eenrichtingsverkeer. Meer bron-NAT lost een ontbrekende retourroute zelden op; het kan het symptoom op één stroom verbergen terwijl het adresgebaseerd beleid overal elders breekt.

De andere veelgemaakte fout is verwachten dat een tunnel routeerbaarheid creëert. Een privéclient wiens pakketten naar het internet gaan, heeft een geldige uitgangsregeling nodig: een standaardroute, een doorsturende gateway en meestal bronvertaling naar een openbaar adres. Versleuteling alleen maakt een privéadres niet bereikbaar.

Masquerade of expliciete SNAT

Vergelijk de twee op wat ze beloven. Masquerade kiest het uitgangsadres, expliciete SNAT zet het vast. Op een gateway met een stabiel openbaar adres geeft vastzetten logs en partner-allowlists één voorspelbare waarde. Op een dynamische WAN-link wordt een vastgezet SNAT-adres onjuist op het moment dat de lease verandert, en dat is precies het geval waarvoor Masquerade is gebouwd.

Bereik is net zo belangrijk als de keuze. Een Masquerade-regel die op elk pakket past dat de gateway verlaat, zonder bron- of bestemmingsgrens, vertaalt ook verkeer dat je intact wilde laten, inclusief verkeer naar andere privénetwerken. Beperk de regel tot het clientbereik, de bedoelde bestemming en de interface.

Bij beleidsgebaseerde IPsec bijt dit het hardst. De doorstuurhandleiding van strongSwan loopt door het inschakelen van IP-forwarding en het toevoegen van een bron-NAT-regel voor clients, en dezelfde documentatie behandelt het uitsluiten van verkeer dat zijn oorspronkelijke adres moet houden. Vertaal een bron voordat het beveiligingsbeleid erop matcht en de tunnel kan omhoog komen terwijl het verkeer nog steeds valt, omdat het pakket er niet meer uitziet als de onderhandelde selector.

Bepaal ook wat de verre kant moet zien. Na vertaling ziet een dienst de gateway, niet de individuele client. Dat vereenvoudigt retourroutering en vlakt tegelijk logs af en ontkracht allowlists per client. Als het behouden van clientadressen telt, plan dan een gerouteerde retourweg in plaats van ze te verbergen om een test te laten slagen.

De regels lezen op een Linux-gateway

Een gateway voor externe toegang met clients op 10.8.0.0/24 en een WAN-interface met de naam eth0 heeft ingeschakelde forwarding nodig en een filterbeleid dat de stroom toestaat, voordat enige NAT-regel kan helpen. De iptables-versie houdt beide richtingen in de nat-tabel:

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

De nftables-vorm gebruikt dezelfde twee haken met een benoemde interface en een expliciete chain:

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

Beide fragmenten gaan ervan uit dat de filterchain de doorgestuurde stroom al accepteert. NAT is geen toestemmingsregel, en een correct vertaald pakket kan een tabel later alsnog worden weggegooid. Bevestig de live mapping met conntrack -L, bevestig wat er geladen is met nft list ruleset of iptables-save -t nat, en maak dan een capture op beide interfaces om te zien dat het adres echt verandert.

Faalmodi die op een slechte regel lijken

Haarspeldverkeer is de klassieker. Een interne client die een interne server bereikt via het openbare adres van de server heeft de DNAT nodig op de heenweg en een bronvertaling op de terugweg naar buiten, anders antwoordt de server rechtstreeks aan de client en wordt het antwoord geweigerd. De oplossing is een tweede, smallere regel voor dat geval intern-naar-openbaar, geen bredere Masquerade-regel voor alles.

Dubbele vertaling is de stille. Een client die al achter carrier-grade NAT zit, komt met een adres bij je gateway aan dat je niet terug kunt routeren, dus je vertaalt opnieuw. Het werkt, maar logs dragen nu twee sprongen privéadressering en elk onderzoek heeft beide mappings nodig. Beleidsgebaseerde IPsec voegt een derde draai toe: vertaal vóór de beleidsmatch en je krijgt een SA die omhoog staat zonder dat er verkeer doorheen gaat, wat als een firewallbug leest en niet als een NAT-bug.

Dan is er de test die slaagt en de uitrol die faalt. Het NAT-commando met de hand draaien bewijst het mechanisme, niet de configuratie. Een regel die tijdens runtime is toegevoegd verdwijnt bij een herstart of bij de volgende interfacegebeurtenis, en een Masquerade-regel die aan een interface hangt die opnieuw nummert, kan het adres dat de verre kant ziet stil veranderen. Zet de regel in de configuratie van de firewall die hem bezit en test opnieuw na een herverbinding.

Checklist voordat je de regel opslaat

Benoem eerst de richting: bron, bestemming of beide. Bepaal dan wie de toestand moet houden — de gateway, de router erboven of de IPsec-peer — en bevestig dat de antwoordweg er doorheen terugkomt. Beperk de regel tot het clientbereik, de bestemming en de interface die je echt bedoelt, en beslis vooraf of de verre kant de gateway of het oorspronkelijke clientadres moet zien.

Test vanaf een client, niet vanaf de gateway. Een browser op de gateway zelf kan de clientvertaalregel volledig omzeilen, dus een pagina die daar werkt bewijst niets over de tunnel. Stuur één verzoek dat bij de client ontstaat, kijk naar de tellers en de conntrack-tabel, en herhaal het na een herverbinding van de tunnel en een wijziging van het WAN-adres als een van beide mogelijk is waar je werkt.