SNAT, DNAT in Masquerade: kaj počne vsako pravilo NAT v VPN

Nastavite zajem na obeh straneh prehoda VPN in en tok lahko pokaže štiri različne naslove. Izvorni NAT prepiše, od kod paket trdi, da prihaja; ciljni NAT prepiše, kam gre. Masquerade ni tretja smer, je pravilo izvornega NAT, ki vzame naslov z izhodnega vmesnika namesto fiksne vrednosti. Poimenujte, katero od treh res potrebujete, in večina zahtevkov „VPN je pokvarjen“ se skrči na vprašanje o povratni poti.

Kaj prepiše vsako pravilo

Izvorni NAT, običajno zapisan SNAT, spremeni izvorni naslov toka, ko ta zapusti usmerjevalnik ali prehod. Storitev, ki prejme, odgovori na prevedeni naslov, in polje, ki prevaja, spremembo obrne s stanjem, ki ga je hranilo za to povezavo. V Linuxu to stanje živi v conntracku, zato conntrack -L izpiše izvirne in odgovorne n-terice drugo ob drugi.

Ciljni NAT, DNAT, namesto tega spremeni cilj. Paket, naslovljen na javni naslov na UDP 51820, je mogoče prepisati na notranji strežnik WireGuard na 10.8.0.2:51820. Tako domači usmerjevalnik ali oblačni razbremenilnik objavi poslušalca VPN, in to ne pove ničesar o tem, kaj lahko tunel nosi pozneje.

Masquerade spada v družino SNAT. Pravilo ne navaja naslova; uporabi tistega, ki ga ima izhodni vmesnik ob odhodu paketa. Linux mu da svoj cilj, in to je običajna izbira na vmesniku WAN, ki naslov dobi iz DHCP ali PPPoE.

Kje živi preslikava, odloča o napaki

Zapišite n-terico na vsaki meji: pred tunelom, v njem in na javnem vmesniku. Zajem znotraj tunela se zakonito razlikuje od tistega zunaj, in kdor primerja oba, ne da bi vedel, kje poteka prevod, bo lovil napačnega gostitelja.

Povratni promet mora iti skozi napravo, ki drži preslikavo. Če odgovor izbere drugo pot, drugi zgornji kanal, pot politike ali ponudnika, ki še ni slišal za vaš zasebni razpon, se stanjski obratni prevod nikoli ne zgodi in odjemalec vidi enosmerni promet. Dodajanje še enega izvornega NAT redko popravi manjkajočo povratno pot; lahko skrije simptom na enem toku in drugje zlomi politiko, ki temelji na naslovih.

Druga pogosta napaka je pričakovanje, da bo tunel ustvaril usmerljivost. Zasebni odjemalec, katerega paketi gredo v internet, potrebuje veljavno izhodno ureditev: privzeto pot, posredovalni prehod in običajno izvorni prevod na javni naslov. Samo šifriranje zasebnega naslova ne naredi dosegljivega.

Masquerade ali eksplicitni SNAT

Primerjajte ju po tem, kar obljubljata. Masquerade izbere izhodni naslov, eksplicitni SNAT ga pritrdi. Na prehodu s stabilnim javnim naslovom pritrditev daje dnevnikom in partnerskim seznamom dovoljenih eno predvidljivo vrednost. Na dinamični povezavi WAN pritrjeni naslov SNAT postane napačen v trenutku, ko se zakup spremeni, in prav za ta primer je bil Masquerade zgrajen.

Obseg je enako pomemben kot izbira. Pravilo Masquerade, ki se ujema z vsakim paketom, ki zapusti prehod, brez omejitve izvora ali cilja, prevede tudi promet, ki ste ga hoteli pustiti nedotaknjenega, vključno s prometom v druga zasebna omrežja. Omejite pravilo na razpon odjemalcev, predvideni cilj in vmesnik.

Pri IPsec, ki temelji na politikah, to najbolj ugrizne. Vodnik strongSwan za posredovanje pelje skozi vklop posredovanja IP in dodajanje pravila izvornega NAT za odjemalce, in ista dokumentacija pokriva izključitev prometa, ki mora obdržati prvotni naslov. Prevedite izvor, preden se z njim ujame varnostna politika, in tunel se lahko dvigne, medtem ko promet še vedno pada, ker paket ni več videti kot dogovorjeni selektor.

Odločite tudi, kaj naj vidi oddaljeni konec. Po prevodu storitev vidi prehod, ne posameznega odjemalca. To poenostavi povratno usmerjanje in hkrati zravna dnevnike ter izniči sezname dovoljenih za posameznega odjemalca. Če je ohranjanje naslovov odjemalcev pomembno, načrtujte usmerjeno povratno pot, namesto da bi jih skrivali, da bi test uspel.

Branje pravil na prehodu Linux

Prehod za oddaljeni dostop z odjemalci v 10.8.0.0/24 in vmesnikom WAN z imenom eth0 potrebuje vklopljeno posredovanje in filtrirno politiko, ki dovoli tok, preden lahko katero koli pravilo NAT pomaga. Različica iptables drži obe smeri v tabeli nat:

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

Oblika nftables uporablja ista dva kavlja z imenovanim vmesnikom in izrecno verigo:

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

Oba odlomka predpostavljata, da filtrirna veriga že sprejema posredovani tok. NAT ni pravilo dovoljenja, in pravilno preveden paket je lahko eno tabelo pozneje še vedno zavržen. Potrdite živo preslikavo z conntrack -L, potrdite, kaj je naloženo, z nft list ruleset ali iptables-save -t nat, nato zajemite na obeh vmesnikih, da vidite, da se naslov res spremeni.

Načini odpovedi, ki so videti kot slabo pravilo

Promet v obliki lasnice je klasika. Notranji odjemalec, ki doseže notranji strežnik prek javnega naslova strežnika, potrebuje DNAT na poti noter in izvorni prevod na poti nazaj ven, sicer strežnik odgovori neposredno odjemalcu in odgovor je zavrnjen. Popravek je drugo, ožje pravilo za ta primer notranje-proti-javnemu, ne širše pravilo Masquerade za vse.

Dvojni prevod je tihi. Odjemalec, ki je že za NAT na ravni operaterja, pride na vaš prehod z naslovom, ki ga ne morete usmeriti nazaj, zato prevajate znova. Deluje, vendar dnevniki zdaj nosijo dva skoka zasebnega naslavljanja in vsaka preiskava potrebuje obe preslikavi. IPsec, ki temelji na politikah, doda tretji zasuk: prevedite pred ujemanjem politike in dobite SA, ki stoji brez prometa, kar se bere kot napaka požarnega zidu, ne NAT.

Nato je tu test, ki uspe, in uvedba, ki ne uspe. Ročno izvajanje ukaza NAT dokaže mehanizem, ne konfiguracije. Pravilo, dodano med delovanjem, izgine ob ponovnem zagonu ali ob naslednjem dogodku vmesnika, in pravilo Masquerade, vezano na vmesnik, ki spremeni številko, lahko tiho spremeni naslov, ki ga vidi oddaljeni konec. Vstavite pravilo v konfiguracijo požarnega zidu, ki ga ima v lasti, in znova preizkusite po ponovni povezavi.

Kontrolni seznam pred shranjevanjem pravila

Najprej poimenujte smer: izvor, cilj ali oboje. Nato ugotovite, kdo mora držati stanje — prehod, usmerjevalnik zgoraj ali partner IPsec — in potrdite, da se povratna pot vrača skozi njega. Omejite pravilo na razpon odjemalcev, cilj in vmesnik, ki jih res mislite, in vnaprej odločite, ali naj oddaljeni konec vidi prehod ali prvotni naslov odjemalca.

Preizkušajte z odjemalca, ne s prehoda. Brskalnik na samem prehodu lahko popolnoma obide pravilo prevoda za odjemalce, zato stran, ki tam deluje, o tunelu ne dokaže ničesar. Pošljite eno zahtevo, ki izvira pri odjemalcu, opazujte števce in tabelo conntrack, in to ponovite po ponovni povezavi tunela in spremembi naslova WAN, če je kaj od tega tam, kjer delate, mogoče.