SNAT teenoor DNAT teenoor Masquerade: wat elke VPN-NAT-reël doen

Sit ’n opname aan beide kante van ’n VPN-poort en een vloei kan vier verskillende adresse wys. Bron-NAT herskryf waarheen ’n pakkie sê dit kom; bestemmings-NAT herskryf waar dit heen gaan. Masquerade is nie ’n derde rigting nie, dit is ’n bron-NAT-reël wat sy adres by die uitgaande koppelvlak kry in plaas van ’n vaste waarde. Noem watter van die drie jy werklik nodig het, en die meeste „die VPN is stukkend”-kaartjies val terug tot ’n vraag oor die terugroete.

Wat elke reël herskryf

Bron-NAT, gewoonlik SNAT geskryf, verander die bronadres van ’n vloei wanneer dit ’n router of poort verlaat. Die ontvangende diens antwoord na die vertaalde adres, en die toestel wat vertaal keer die verandering om met die toestand wat hy vir daardie verbinding gehou het. Op Linux woon daardie toestand in conntrack, en daarom druk conntrack -L die oorspronklike en antwoord-tuples langs mekaar.

Bestemmings-NAT, DNAT, verander eerder die bestemming. ’n Pakkie wat na ’n publieke adres op UDP 51820 gerig is, kan herskryf word na ’n interne WireGuard-bediener by 10.8.0.2:51820. So publiseer ’n tuisrouter of ’n wolk-lasbalanseerder ’n VPN-luisteraar, en dit sê niks oor wat die tonnel daarna mag dra nie.

Masquerade hoort by die SNAT-familie. Die reël noem geen adres nie; dit gebruik watter adres die uitgaande koppelvlak ook al het wanneer die pakkie vertrek. Linux gee dit sy eie teiken, en dit is die gewone keuse op ’n WAN-koppelvlak wat sy adres van DHCP of PPPoE kry.

Waar die kartering woon, bepaal die fout

Teken die tuple by elke grens op: voor die tonnel, binne-in dit en op die publieke koppelvlak. ’n Opname binne die tonnel verskil wettig van een daarbuite, en enigiemand wat die twee vergelyk sonder om te weet waar die vertaling gebeur, sal die verkeerde gasheer jaag.

Terugverkeer moet deur die toestel gaan wat die kartering hou. As ’n antwoord ’n ander roete neem, ’n tweede opvoer, ’n beleidsroete, of ’n verskaffer wat nog nooit van jou private reeks gehoor het nie, gebeur die staatvolle omgekeerde vertaling nooit en die kliënt sien eenrigtingverkeer. Meer bron-NAT byvoeg maak selde ’n ontbrekende terugroete reg; dit kan die simptoom op een vloei verberg terwyl dit adresgebaseerde beleid oral anders breek.

Die ander algemene fout is om te verwag dat ’n tonnel bereikbaarheid skep. ’n Private kliënt wie se pakkies na die internet gaan, het ’n geldige uitgangsreëling nodig: ’n verstekroete, ’n deurstuurpoort en gewoonlik bronvertaling na ’n publieke adres. Versleuteling alleen maak ’n private adres nie bereikbaar nie.

Masquerade of eksplisiete SNAT

Vergelyk die twee volgens wat hulle belowe. Masquerade kies die uitgangsadres, eksplisiete SNAT pen dit vas. Op ’n poort met ’n stabiele publieke adres gee vaspenning aan logboeke en vennoot-allowlyste een voorspelbare waarde. Op ’n dinamiese WAN-skakel word ’n vasgepen SNAT-adres verkeerd sodra die huurkontrak verander, en dit is juis die geval waarvoor masquerade gebou is.

Omvang maak net soveel saak soos die keuse. ’n Masquerade-reël wat elke pakkie pas wat die poort verlaat, sonder bron- of bestemmingsbeperking, vertaal ook verkeer wat jy bedoel het om ongeskonde te hou, insluitend verkeer na ander private netwerke. Beperk die reël tot die kliëntreeks, die bedoelde bestemming en die koppelvlak.

Beleidsgebaseerde IPsec is waar dit die seerste byt. strongSwan se deurstuur-handleiding wys hoe om IP-deurstuur te aktiveer en ’n bron-NAT-reël vir kliënte by te voeg, en dieselfde dokumentasie dek die uitsluiting van verkeer wat sy oorspronklike adres moet hou. Vertaal ’n bron voordat die sekuriteitsbeleid dit pas, en die tonnel kan opkom terwyl die verkeer steeds val, want die pakkie lyk nie meer soos die keurder wat onderhandel is nie.

Bepaal ook wat die verre kant moet sien. Ná vertaling sien ’n diens die poort, nie die individuele kliënt nie. Dit vereenvoudig terugroetering en plat terselfdertyd logboeke en verydel per-kliënt-allowlyste. As dit saak maak om kliëntadresse te bewaar, beplan ’n geroteerde terugroete eerder as om hulle te versteek sodat ’n toets slaag.

Hoe om die reëls op ’n Linux-poort te lees

’n Afstandtoegang-poort met kliënte op 10.8.0.0/24 en ’n WAN-koppelvlak genaamd eth0 het deurstuur geaktiveer nodig en ’n filterbeleid wat die vloei toelaat voordat enige NAT-reël kan help. Die iptables-weergawe hou beide rigtings in die 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

Die nftables-vorm gebruik dieselfde twee hake met ’n genoemde koppelvlak en ’n eksplisiete ketting:

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 brokkies aanvaar dat die filterketting die deurgestuurde vloei reeds aanvaar. NAT is nie ’n toelaatreël nie, en ’n korrek vertaalde pakkie kan steeds een tabel later laat val word. Bevestig die lewendige kartering met conntrack -L, bevestig wat gelaai is met nft list ruleset of iptables-save -t nat, en neem dan opname op beide koppelvlakke om te sien dat die adres werklik verander.

Foutmodusse wat soos ’n slegte reël lyk

Haarspeldverkeer is die klassieke een. ’n Interne kliënt wat ’n interne bediener deur die bediener se publieke adres bereik, het die DNAT op pad in nodig en ’n bronvertaling op pad terug uit, anders antwoord die bediener reguit aan die kliënt en die antwoord word verwerp. Die regstelling is ’n tweede, nouer reël vir daardie interne-na-publieke geval, nie ’n wyer masquerade-reël vir alles nie.

Dubbele vertaling is die stil een. ’n Kliënt wat al agter diensverskaffer-grade NAT is, kom by jou poort aan met ’n adres wat jy nie kan terugroeteer nie, so jy vertaal weer. Dit werk, maar logboeke dra nou twee spronge private adressering en enige ondersoek het beide karterings nodig. Beleidsgebaseerde IPsec voeg ’n derde draai by: vertaal voor die beleidspassing en jy kry ’n SA wat op is met geen verkeer wat verbygaan nie, wat soos ’n firewall-fout lees eerder as ’n NAT een.

Dan is daar die toets wat slaag en die ontplooiing wat misluk. Om die NAT-opdrag met die hand te loop bewys die meganisme, nie die konfigurasie nie. ’n Reël wat tydens looptyd bygevoeg is, verdwyn op herbegin of op die volgende koppelvlak-gebeurtenis, en ’n masquerade-reël wat aan ’n koppelvlak gebind is wat hernommer, kan die adres wat die verre kant sien stil verander. Sit die reël in die eienaar-firewall se konfigurasie en hertoets ná ’n herverbinding.

Kontrolelys voordat jy die reël stoor

Noem eers die rigting: bron, bestemming of beide. Identifiseer dan wie die toestand moet hou, die poort, die opstroom-router of die IPsec-peer, en bevestig dat die antwoordpad daardeur terugkom. Beperk die reël tot die kliëntreeks, bestemming en koppelvlak wat jy werklik bedoel, en besluit vooraf of die verre kant die poort of die oorspronklike kliëntadres moet sien.

Toets vanaf ’n kliënt, nie vanaf die poort nie. ’n Blaaier op die poort self kan die kliëntvertaalreël heeltemal omseil, so ’n werkende bladsy daar bewys niks oor die tonnel nie. Stuur een versoek wat by die kliënt ontstaan, kyk na die tellers en die conntrack-tabel, en herhaal dit ná ’n tonnel-herverbinding en ’n WAN-adresverandering as enige van die twee moontlik is waar jy werk.