SNAT, DNAT ja Masquerade: mida iga VPN-i NAT-reegel teeb

Pange jälgimine VPN-lüüsi mõlemale poole ja üks voog võib näidata nelja erinevat aadressi. Lähte-NAT kirjutab ümber, kust pakett väidab tulevat; siht-NAT kirjutab ümber, kuhu see läheb. Masquerade ei ole kolmas suund, vaid lähte-NAT-i reegel, mis võtab aadressi väljuvalt liideselt, mitte fikseeritud väärtusest. Nimetage, millist kolmest te tegelikult vajate, ja enamik piletitest „VPN on katki“ taandub küsimuseks tagasitee kohta.

Mida iga reegel ümber kirjutab

Lähte-NAT, tavaliselt kirjutatud SNAT, muudab voo lähteaadressi, kui see lahkub ruuterist või lüüsist. Vastuvõttev teenus vastab tõlgitud aadressile ja tõlkiv seade pöörab muudatuse tagasi olekuga, mille ta selle ühenduse jaoks hoidis. Linuxis elab see olek conntrackis, seepärast trükib conntrack -L algse ja vastuse korteeži kõrvuti.

Siht-NAT, DNAT, muudab selle asemel sihti. UDP 51820 avalikule aadressile adresseeritud paketi saab ümber kirjutada sisemisele WireGuard-serverile aadressil 10.8.0.2:51820. Nii avaldab koduruuter või pilvekoormusjaotur VPN-kuulaja, ja see ei ütle midagi selle kohta, mida tunnel hiljem kanda tohib.

Masquerade kuulub SNAT-i perekonda. Reegel ei nimeta ühtegi aadressi; see kasutab seda, mis väljuval liidesel paketi lahkumise hetkel on. Linux annab sellele oma sihtmärgi ja see on tavaline valik WAN-liidesel, mis saab aadressi DHCP või PPPoE kaudu.

Kus vastendus elab, see määrab rikke

Märkige korteež igal piiril: enne tunnelit, selle sees ja avalikul liidesel. Tunnelis tehtud jälgimine erineb õiguspäraselt väljaspool tehtust ja igaüks, kes neid võrdleb ilma teadmata, kus tõlge toimub, ajab taga valet hosti.

Tagasiliiklus peab läbima seadet, mis vastendust hoiab. Kui vastus valib teise marsruudi, teise üleslingi, poliitikamarsruudi või teenusepakkuja, kes pole teie privaatsest vahemikust kunagi kuulnud, ei toimu olekuga pöördtõlge kunagi ja klient näeb ühesuunalist liiklust. Rohkem lähte-NAT-i parandab harva puuduvat tagasiteed; see võib varjata sümptomit ühel voolul, samal ajal rikkudes aadressipõhist poliitikat kõikjal mujal.

Teine levinud viga on oodata, et tunnel loob marsruuditavuse. Privaatne klient, kelle paketid lähevad internetti, vajab kehtivat väljundikorraldust: vaikemarsruuti, edastavat lüüsi ja tavaliselt lähte-NAT-i avalikule aadressile. Krüpteerimine üksi ei tee privaatset aadressi kättesaadavaks.

Masquerade või selgesõnaline SNAT

Võrrelge neid selle järgi, mida nad lubavad. Masquerade valib väljundaadressi, selgesõnaline SNAT kinnitab selle. Stabiilse avaliku aadressiga lüüsil annab kinnitamine logidele ja partnerite lubatud nimekirjadele ühe ettearvatava väärtuse. Dünaamilisel WAN-lingil muutub kinnitatud SNAT-i aadress valeks hetkel, kui liising muutub, ja just selleks juhuks Masquerade loodigi.

Ulatus loeb sama palju kui valik. Masquerade-reegel, mis sobib iga lüüsist lahkuva paketiga, ilma lähte- või sihipiiranguta, tõlgib ka liiklust, mille kavatsesite puutumatuks jätta, sealhulgas liiklust teistesse privaatvõrkudesse. Piirake reegel kliendivahemiku, kavatsetud sihi ja liidesega.

Poliitikapõhine IPsec on koht, kus see kõige valusamalt hammustab. strongSwan-i edastusjuhend käib läbi IP-edastuse lubamise ja klientidele lähte-NAT-i reegli lisamise, ja sama dokumentatsioon katab ka liikluse välistamise, mis peab säilitama oma algse aadressi. Tõlkige lähtekoht enne, kui turbepoliitika sellega sobib, ja tunnel võib tulla üles, samal ajal kui liiklus ikka langeb, sest pakett ei näe enam välja nagu läbiräägitud selektor.

Otsustage ka, mida peaks nägema kaugem ots. Pärast tõlget näeb teenus lüüsi, mitte üksikut klienti. See lihtsustab tagasimarsruutimist ja samal ajal lamedab logisid ning muudab kliendipõhised lubatud nimekirjad mõttetuks. Kui kliendi aadresside säilitamine loeb, planeerige marsruuditud tagasitee, selle asemel et neid testi läbimise nimel peita.

Reeglite lugemine Linuxi lüüsil

Kaugjuurdepääsu lüüs, mille kliendid on 10.8.0.0/24 ja WAN-liides kannab nime eth0, vajab lubatud edastust ja filtreerimispoliitikat, mis voo lubab, enne kui ükski NAT-reegel saab aidata. iptables-i versioon hoiab mõlemat suunda nat-tabelis:

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-i vorm kasutab samu kahte konksu nimetatud liidese ja selgesõnalise ahelaga:

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

Mõlemad katked eeldavad, et filtreerimisahel juba aktsepteerib edastatud voogu. NAT ei ole lubamisreegel, ja korrektselt tõlgitud pakett võib ikkagi ühe tabeli hiljem kõrvale jääda. Kinnitage elav vastendus käsuga conntrack -L, kinnitage, mis on laaditud, käsuga nft list ruleset või iptables-save -t nat, ja seejärel jälgige mõlemal liidesel, et näha aadressi tõesti muutumas.

Rikkerežiimid, mis näevad välja nagu halb reegel

Juuksepoldiliiklus on klassika. Sisemine klient, kes jõuab sisemise serverini serveri avaliku aadressi kaudu, vajab DNAT-i sissetuleval ja lähte-NAT-i tagasiväljuval teel, muidu vastab server otse kliendile ja vastus lükatakse tagasi. Parandus on teine, kitsam reegel selle sisemisest avalikku juhtumi jaoks, mitte laiem Masquerade-reegel kõige jaoks.

Topelttõlge on vaikne. Klient, kes on juba operaatoritasandi NAT-i taga, saabub teie lüüsile aadressiga, mida te ei saa tagasi marsruutida, seega tõlgite uuesti. See töötab, aga logid kannavad nüüd kahte hüpet privaatset adresseerimist ja iga uurimine vajab mõlemat vastendust. Poliitikapõhine IPsec lisab kolmanda keerdkäigu: tõlkige enne poliitika sobimist ja saate SA, mis on üleval ilma liikluseta, mis loeb firewalli veana, mitte NAT-i veana.

Siis on test, mis läbib, ja juurutus, mis ebaõnnestub. NAT-käsu käsitsi jooksutamine tõestab mehhanismi, mitte konfiguratsiooni. Tööajal lisatud reegel kaob taaskäivitamisel või järgmisel liidesesündmusel, ja liidesega seotud Masquerade-reegel, mille number muutub, võib vaikselt muuta aadressi, mida kaugem ots näeb. Pange reegel seda omava tulemüüri konfiguratsiooni ja testige uuesti pärast taasühendamist.

Kontrollnimekiri enne reegli salvestamist

Nimetage esmalt suund: lähe, siht või mõlemad. Seejärel tehke kindlaks, kes peab olekut hoidma — lüüs, ülemine ruuter või IPsec-i partner —, ja kinnitage, et vastusete tee tuleb sealt tagasi. Piirake reegel kliendivahemiku, sihi ja liidesega, mida te tõesti mõtlete, ja otsustage ette, kas kaugem ots peaks nägema lüüsi või kliendi algset aadressi.

Testige kliendist, mitte lüüsist. Lüüsi enda brauser võib kliendi tõlkereegli täielikult mööda minna, seega seal töötav leht ei tõesta tunnelist midagi. Saatke üks kliendilt algatatud päring, jälgige loendureid ja conntracki tabelit ning korrake seda pärast tunneli taasühendamist ja WAN-aadressi muutust, kui kumbki neist on teie töökohas võimalik.