SNAT, DNAT og Masquerade: kva kvar VPN-NAT-regel gjer

Set eit avfangst på begge sider av ein VPN-gateway, og éin straum kan visa fire ulike adresser. Kjelde-NAT skriv om kvar ein pakke hevdar han kjem frå; mål-NAT skriv om kvar han skal. Masquerade er ikkje ein tredje retning, det er ein kjelde-NAT-regel som tek adressa frå det utgåande grensesnittet i staden for ein fast verdi. Namngje kva av dei tre du faktisk treng, og dei fleste «VPN er øydelagt»-sakene blir eit spørsmål om returvegen.

Kva kvar regel skriv om

Kjelde-NAT, vanlegvis skrive SNAT, endrar kjeldeadressa til ein straum når han forlèt ein ruter eller gateway. Tenesta som tek imot, svarar til den omsette adressa, og boksen som omset, gjer endringa om att med tilstanden han heldt for sambandet. På Linux bur denne tilstanden i conntrack, difor skriv conntrack -L ut dei opphavlege og svarande tupla side ved side.

Mål-NAT, DNAT, endrar målet i staden. Ein pakke adressert til ei offentleg adresse på UDP 51820 kan skrivast om til ein intern WireGuard-server på 10.8.0.2:51820. Slik publiserer ein heimeruter eller ein sky-lastbalansar ein VPN-lyttar, og det seier ingenting om kva tunnelen kan bera etterpå.

Masquerade høyrer til SNAT-familien. Regelen nemner inga adresse; han brukar den adressa det utgåande grensesnittet har når pakken forlèt. Linux gjev han sitt eige mål, og det er det vanlege valet på eit WAN-grensesnitt som får adressa frå DHCP eller PPPoE.

Kvar kartlegginga bur avgjer feilen

Noter tuplet ved kvar grense: før tunnelen, inne i han og på det offentlege grensesnittet. Eit avfangst inne i tunnelen skil seg legitimt frå eitt utanfor, og den som samanliknar dei to utan å vita kvar omsetjinga skjer, jagar feil vert.

Returtrafikk må gå gjennom eininga som held kartlegginga. Viss svaret tek ein annan veg, ein annan opplenkje, ein policy-rute eller ein leverandør som aldri har høyrt om ditt private område, skjer aldri den tilstandsfulle motsette omsetjinga, og klienten ser einvegtrafikk. Meir kjelde-NAT reparerer sjeldan ein manglande returveg; det kan skjula symptomet på éin straum og samstundes bryta adressebasert policy overalt elles.

Den andre vanlege feilen er å venta at ein tunnel skapar rutbarheit. Ein privat klient som sine pakkar går ut på internett, treng ei gyldig utgangsordning: ei standardrute, ein gateway som videresender og vanlegvis kjeldeomsetjing til ei offentleg adresse. Kryptering åleine gjer ikkje ei privat adresse nåbar.

Masquerade eller eksplisitt SNAT

Samanlikn dei to etter kva dei lovar. Masquerade vel utgangsadressa, eksplisitt SNAT festar ho. På ein gateway med ei stabil offentleg adresse gjev festing loggar og partnarar lister éin føreseieleg verdi. På ein dynamisk WAN-linje blir ei fest SNAT-adresse feil i det augeblikket leiga endrar seg, og det er nøyaktig tilfellet Masquerade vart bygd for.

Omfanget tyder like mykje som valet. Ein Masquerade-regel som treff kvar pakke som forlèt gatewayen, utan kjelde- eller målgrense, omset òg trafikk du meinte å halda intakt, inkludert trafikk til andre private nettverk. Avgrens regelen til klientområdet, det tiltenkte målet og grensesnittet.

Policybasert IPsec er der dette bit hardast. strongSwan si rettleiing for videresending går gjennom å slå på IP-videresending og leggja til ein kjelde-NAT-regel for klientar, og same dokumentasjonen dekkjer å utelata trafikk som må halda den opphavlege adressa si. Omset ei kjelde før tryggleikspolicyen treff ho, og tunnelen kan koma opp medan trafikken framleis fell, fordi pakken ikkje lenger ser ut som veljaren som vart forhandla.

Avgjer òg kva den fjerne enden skal sjå. Etter omsetjinga ser ei teneste gatewayen, ikkje den einskilde klienten. Det forenklar returruting og jamnar samstundes ut loggar og gjer tillatingslister per klient verknadslause. Viss det er viktig å varðveita klientadresser, planlegg ein ruta returveg i staden for å skjula dei for å få ein test til å gå gjennom.

Å lesa reglane på ein Linux-gateway

Ein fjernåtkomst-gateway med klientar på 10.8.0.0/24 og eit WAN-grensesnitt kalla eth0 treng påslått videresending og ein filterpolicy som tillèt straumen, før nokon NAT-regel kan hjelpa. iptables-versjonen held båe retningane 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-forma brukar dei same to krokane med eit namngjeve grensesnitt og ei 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

Båe utdraga føreset at filterkjeda alt godtek den videresende straumen. NAT er ikkje ein tillatingsregel, og ein korrekt omsett pakke kan framleis bli forkasta ein tabell seinare. Stadfest den levande kartlegginga med conntrack -L, stadfest kva som er lasta med nft list ruleset eller iptables-save -t nat, og ta så avfangst på båe grensesnitta for å sjå at adressa faktisk endrar seg.

Feilmodi som ser ut som ein dårleg regel

Hårnålstrafikk er klassikaren. Ein intern klient som når ein intern server via den offentlege adressa til serveren, treng DNAT på vegen inn og ei kjeldeomsetjing på vegen ut att, elles svarar serveren rett til klienten, og svaret blir avvist. Rettninga er ein annan, trongare regel for det interne-til-offentlege tilfellet, ikkje ein breiare Masquerade-regel for alt.

Dobbel omsetjing er den stille. Ein klient som alt er bak carrier-grade NAT, kjem til gatewayen din med ei adresse du ikkje kan ruta tilbake, så du omset på nytt. Det verkar, men loggane ber no to hopp med privat adressering, og kvar gransking treng båe kartleggingane. Policybasert IPsec legg til eit tredje vrid: omset før policytreffet, og du får ein SA som står oppe utan at trafikk passerer, noko som les som ein brannmurfeil og ikkje ein NAT-feil.

Så er det testen som går gjennom, og utrullinga som feilar. Å køyra NAT-kommandoen for hand provar mekanismen, ikkje konfigurasjonen. Ein regel som blir lagd til under køyring, forsvinn ved omstart eller ved neste grensesnittshending, og ein Masquerade-regel knytt til eit grensesnitt som endrar nummer, kan stille endra adressa den fjerne enden ser. Legg regelen i konfigurasjonen til brannmuren som eig han, og test på nytt etter ein attkopling.

Sjekkliste før du lagrar regelen

Namngje retninga først: kjelde, mål eller båe. Finn så ut kven som må halda tilstanden — gatewayen, ruteren over eller IPsec-motparten — og stadfest at svarvegen kjem tilbake gjennom han. Avgrens regelen til klientområdet, målet og grensesnittet du faktisk meiner, og avgjer på førehand om den fjerne enden skal sjå gatewayen eller den opphavlege klientadressa.

Test frå ein klient, ikkje frå gatewayen. Ein nettlesar på gatewayen sjølv kan omgå klientomsetjingsregelen heilt, så ei side som verkar der, provar ingenting om tunnelen. Send éin førespurnad som kjem frå klienten, følg med på teljarane og conntrack-tabellen, og gjer det om att etter ein attkopling av tunnelen og ei endring av WAN-adressa viss eitt av dei er mogleg der du jobbar.