SNAT, DNAT og Masquerade: hva hver VPN-NAT-regel gjør

Sett en fangst på begge sider av en VPN-gateway, og én strøm kan vise fire forskjellige adresser. Kilde-NAT skriver om hvor en pakke hevder den kommer fra; mål-NAT skriver om hvor den skal hen. Masquerade er ikke en tredje retning, det er en kilde-NAT-regel som tar adressen fra det utgående grensesnittet i stedet for en fast verdi. Navngi hvilken av de tre du faktisk trenger, og de fleste «VPN er ødelagt»-sakene blir et spørsmål om returveien.

Hva hver regel skriver om

Kilde-NAT, vanligvis skrevet SNAT, endrer kildeadressen til en strøm når den forlater en ruter eller gateway. Tjenesten som mottar, svarer til den oversatte adressen, og boksen som oversetter, gjør endringen om igjen med tilstanden den holdt for forbindelsen. På Linux bor denne tilstanden i conntrack, derfor skriver conntrack -L ut de opprinnelige og svarende tuplene side ved side.

Mål-NAT, DNAT, endrer målet i stedet. En pakke adressert til en offentlig adresse på UDP 51820 kan skrives om til en intern WireGuard-server på 10.8.0.2:51820. Slik publiserer en hjemmeruter eller en sky-lastbalanserer en VPN-lytter, og det sier ingenting om hva tunnelen kan bære etterpå.

Masquerade hører til SNAT-familien. Regelen nevner ingen adresse; den bruker den adressen det utgående grensesnittet har når pakken forlater. Linux gir den sitt eget mål, og det er det vanlige valget på et WAN-grensesnitt som får adressen fra DHCP eller PPPoE.

Hvor kartleggingen bor avgjør feilen

Noter tuplen ved hver grense: før tunnelen, inne i den og på det offentlige grensesnittet. En fangst inne i tunnelen avviker legitimt fra en utenfor, og den som sammenligner de to uten å vite hvor oversettelsen skjer, jager feil vert.

Returtrafikk må gå gjennom enheten som holder kartleggingen. Hvis svaret tar en annen rute, en annen opplink, en policy-rute eller en leverandør som aldri har hørt om ditt private område, skjer aldri den tilstandsfulle motsatte oversettelsen, og klienten ser enveistrafikk. Mer kilde-NAT reparerer sjelden en manglende returrute; det kan skjule symptomet på én strøm og samtidig bryte adressebasert policy overalt ellers.

Den andre vanlige feilen er å forvente at en tunnel skaper rutbarhet. En privat klient hvis pakker går ut på internett, trenger en gyldig utgangsordning: en standardrute, en gateway som videresender og vanligvis kildeoversettelse til en offentlig adresse. Kryptering alene gjør ikke en privat adresse nåbar.

Masquerade eller eksplisitt SNAT

Sammenlign de to etter hva de lover. Masquerade velger utgangsadressen, eksplisitt SNAT fester den. På en gateway med en stabil offentlig adresse gir festing logger og partnerlister ett forutsigbart svar. På en dynamisk WAN-linje blir en festet SNAT-adresse feil i det øyeblikket lease-tiden endres, og det er nøyaktig tilfellet Masquerade ble laget for.

Omfanget betyr like mye som valget. En Masquerade-regel som treffer hver pakke som forlater gatewayen, uten kilde- eller målbegrensning, oversetter også trafikk du mente å holde intakt, inkludert trafikk til andre private nettverk. Begrens regelen til klientområdet, det tiltenkte målet og grensesnittet.

Policybasert IPsec er der dette biter hardest. strongSwans veiledning for videresending går gjennom å aktivere IP-videresending og legge til en kilde-NAT-regel for klienter, og samme dokumentasjon dekker å utelate trafikk som må beholde sin opprinnelige adresse. Oversett en kilde før sikkerhetspolicyen treffer den, og tunnelen kan komme opp mens trafikken fortsatt faller, fordi pakken ikke lenger ser ut som velgeren som ble forhandlet.

Bestem også hva den fjerne enden skal se. Etter oversettelsen ser en tjeneste gatewayen, ikke den enkelte klienten. Det forenkler returruting og jevner samtidig ut logger og gjør tillatelseslister per klient virkningsløse. Hvis det er viktig å bevare klientadresser, planlegg en rutet returvei i stedet for å skjule dem for å få en test til å bestå.

Å lese reglene på en Linux-gateway

En fjernadgangs-gateway med klienter på 10.8.0.0/24 og et WAN-grensesnitt kalt eth0 trenger aktivert videresending og en filterpolicy som tillater strømmen, før noen NAT-regel kan hjelpe. iptables-versjonen 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 bruker de samme to krokene med et navngitt grensesnitt og en eksplisitt kjede:

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 utdragene forutsetter at filterkjeden allerede godtar den videresendte strømmen. NAT er ikke en tillatelsesregel, og en korrekt oversatt pakke kan fortsatt bli forkastet en tabell senere. Bekreft den levende kartleggingen med conntrack -L, bekreft hva som er lastet med nft list ruleset eller iptables-save -t nat, og ta så fangst på begge grensesnittene for å se at adressen faktisk endres.

Feilmoduser som ser ut som en dårlig regel

Hårnålstrafikk er klassikeren. En intern klient som når en intern server via serverens offentlige adresse, trenger DNAT på vei inn og en kildeoversettelse på vei ut igjen, ellers svarer serveren rett til klienten, og svaret blir avvist. Rettelsen er en annen, snevrere regel for det interne-til-offentlige tilfellet, ikke en bredere Masquerade-regel for alt.

Dobbel oversettelse er den stille. En klient som allerede er bak carrier-grade NAT, kommer til gatewayen din med en adresse du ikke kan rute tilbake, så du oversetter igjen. Det virker, men loggene bærer nå to hopp med privat adressering, og enhver undersøkelse trenger begge kartleggingene. Policybasert IPsec legger til en tredje vri: oversett før policytreffet, og du får en SA som står oppe uten at trafikk passerer, noe som leses som en brannmurfeil og ikke en NAT-feil.

Så er det testen som består, og utrullingen som feiler. Å kjøre NAT-kommandoen for hånd beviser mekanismen, ikke konfigurasjonen. En regel som legges til under kjøring, forsvinner ved omstart eller ved neste grensesnittshendelse, og en Masquerade-regel knyttet til et grensesnitt som endrer nummer, kan stille endre adressen den fjerne enden ser. Legg regelen i konfigurasjonen til brannmuren som eier den, og test på nytt etter en gjentilkobling.

Sjekkliste før du lagrer regelen

Navngi retningen først: kilde, mål eller begge. Finn så ut hvem som må holde tilstanden — gatewayen, ruteren over eller IPsec-motparten — og bekreft at svarveien kommer tilbake gjennom den. Begrens regelen til klientområdet, målet og grensesnittet du faktisk mener, og bestem på forhånd om den fjerne enden skal se gatewayen eller klientens opprinnelige adresse.

Test fra en klient, ikke fra gatewayen. En nettleser på gatewayen selv kan omgå klientoversettelsesregelen helt, så en side som virker der, beviser ingenting om tunnelen. Send én forespørsel som kommer fra klienten, følg med på tellerne og conntrack-tabellen, og gjenta etter en gjentilkobling av tunnelen og en endring av WAN-adressen hvis ett av dem er mulig der du jobber.