SNAT, DNAT ja Masquerade: mitä kukin VPN-NAT-sääntö tekee

Aseta kaappaus VPN-yhdyskäytävän molemmille puolille ja yksi virtaus voi näyttää neljä eri osoitetta. Lähde-NAT kirjoittaa uudelleen, mistä paketti väittää tulevansa; kohde-NAT kirjoittaa uudelleen, mihin se on menossa. Masquerade ei ole kolmas suunta, vaan lähde-NAT-sääntö, joka ottaa osoitteensa lähtevältä liitännältä kiinteän arvon sijaan. Nimeä, minkä kolmesta todella tarvitset, ja useimmat ”VPN on rikki” -tiketit kutistuvat kysymykseksi paluureitistä.

Mitä kukin sääntö kirjoittaa uudelleen

Lähde-NAT, yleensä SNAT, muuttaa virtauksen lähdeosoitetta, kun se lähtee reitittimestä tai yhdyskäytävästä. Vastaanottava palvelu vastaa käännettyyn osoitteeseen, ja kääntävä laite peruuttaa muutoksen sillä tilalla, jonka se piti yhteyttä varten. Linuxissa tila asuu conntrackissa, siksi conntrack -L tulostaa alkuperäiset ja vastauksen tuplet vierekkäin.

Kohde-NAT, DNAT, muuttaa sen sijaan kohdetta. UDP 51820:n julkiseen osoitteeseen osoitettu paketti voidaan kirjoittaa uudelleen sisäiselle WireGuard-palvelimelle osoitteessa 10.8.0.2:51820. Näin kotireititin tai pilven kuormantasaaja julkaisee VPN-kuuntelijan, eikä se kerro mitään siitä, mitä tunneli saa sen jälkeen kuljettaa.

Masquerade kuuluu SNAT-perheeseen. Sääntö ei nimeä osoitetta; se käyttää sitä, mikä lähtevällä liitännällä on paketin lähtiessä. Linux antaa sille oman kohteensa, ja se on tavallinen valinta WAN-liitännällä, joka saa osoitteensa DHCP:ltä tai PPPoE:lta.

Missä kartoitus asuu, se ratkaisee vian

Kirjaa tuple joka rajalla: ennen tunnelia, sen sisällä ja julkisella liitännällä. Tunnelissa tehty kaappaus eroaa oikeutetusti sen ulkopuolella tehdystä, ja kuka tahansa, joka vertaa niitä tietämättä, missä käännös tapahtuu, ajaa takaa väärää isäntää.

Paluuliikenteen on kuljettava laitteen kautta, joka pitää kartoitusta. Jos vastaus valitsee toisen reitin, toisen ylälinkin, käytäntöreitin tai palveluntarjoajan, joka ei ole koskaan kuullut yksityisestä alueestasi, tilallinen käänteiskäännös ei koskaan tapahdu ja asiakas näkee yksisuuntaista liikennettä. Lisää lähde-NAT:ia harvoin korjaa puuttuvan paluureitin; se voi piilottaa oireen yhdeltä virtaukselta ja rikkoa osoiteperusteisen käytännön kaikkialla muualla.

Toinen yleinen virhe on odottaa, että tunneli luo reititettävyyttä. Yksityinen asiakas, jonka paketit lähtevät internetiin, tarvitsee kelvollisen lähtöjärjestelyn: oletusreitin, edelleen välittävän yhdyskäytävän ja yleensä lähdekäännöksen julkiseen osoitteeseen. Salaus yksin ei tee yksityisestä osoitteesta saavutettavaa.

Masquerade vai eksplisiittinen SNAT

Vertaile niitä sen mukaan, mitä ne lupaavat. Masquerade valitsee lähtöosoitteen, eksplisiittinen SNAT kiinnittää sen. Yhdyskäytävässä, jolla on vakaa julkinen osoite, kiinnitys antaa lokeille ja kumppanien sallittujen luetteloille yhden ennustettavan arvon. Dynaamisella WAN-linkillä kiinnitetty SNAT-osoite muuttuu vääräksi heti, kun vuokra vaihtuu, ja juuri sitä tapausta varten Masquerade rakennettiin.

Laajuus on yhtä tärkeä kuin valinta. Masquerade-sääntö, joka osuu jokaiseen yhdyskäytävältä lähtevään pakettiin ilman lähde- tai kohderajoitusta, kääntää myös liikennettä, jonka tarkoitit pitää koskemattomana, mukaan lukien liikenne muihin yksityisiin verkkoihin. Rajaa sääntö asiakasalueeseen, aiottuun kohteeseen ja liitäntään.

Käytäntöperusteinen IPsec on paikka, jossa tämä puree kovimmin. strongSwanin edelleen välityksen opas käy läpi IP-edelleenvälityksen käyttöönoton ja lähde-NAT-säännön lisäämisen asiakkaille, ja sama dokumentaatio kattaa sellaisen liikenteen pois jättämisen, jonka on säilytettävä alkuperäinen osoitteensa. Käännä lähde ennen kuin tietoturvakäytäntö osuu siihen, ja tunneli voi nousta pystyyn liikenteen yhä pudotessa, koska paketti ei enää näytä neuvotellulta valitsimelta.

Päätä myös, mitä kauko-osan pitäisi nähdä. Käännöksen jälkeen palvelu näkee yhdyskäytävän, ei yksittäistä asiakasta. Se yksinkertaistaa paluureititystä ja samalla tasoittaa lokit ja tekee asiakaskohtaiset sallitut luettelot tyhjiksi. Jos asiakkaiden osoitteiden säilyttäminen on tärkeää, suunnittele reititetty paluureitti sen sijaan, että piilottaisit ne testin läpäisemiseksi.

Sääntöjen lukeminen Linux-yhdyskäytävältä

Etäkäyttöyhdyskäytävä, jonka asiakkaat ovat 10.8.0.0/24:ssä ja WAN-liitäntä nimeltä eth0, tarvitsee käytössä olevan edelleenvälityksen ja suodatuskäytännön, joka sallii virtauksen, ennen kuin mikään NAT-sääntö voi auttaa. iptables-versio pitää molemmat suunnat nat-taulussa:

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-muoto käyttää samoja kahta koukkua nimetyllä liitännällä ja eksplisiittisellä ketjulla:

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

Molemmat pätkät olettavat, että suodatinketju jo hyväksyy edelleen välitetyn virtauksen. NAT ei ole sallimissääntö, ja oikein käännetty paketti voidaan silti pudottaa yhden taulun myöhemmin. Vahvista elävä kartoitus komennolla conntrack -L, vahvista ladattu sisältö komennolla nft list ruleset tai iptables-save -t nat ja kaappaa sitten molemmilta liitännöiltä nähdäksesi osoitteen todella muuttuvan.

Vikatilat, jotka näyttävät huonolta säännöltä

Hiusneulaliikenne on klassikko. Sisäinen asiakas, joka saavuttaa sisäisen palvelimen palvelimen julkisen osoitteen kautta, tarvitsee DNAT:n sisäänmenossa ja lähdekäännöksen ulospaluussa, muuten palvelin vastaa suoraan asiakkaalle ja vastaus hylätään. Korjaus on toinen, kapeampi sääntö tuolle sisäisestä julkiseen -tapaukselle, ei laajempi Masquerade-sääntö kaikelle.

Kaksoiskäännös on hiljainen. Asiakas, joka on jo operaattoritason NAT:n takana, saapuu yhdyskäytävällesi osoitteella, jota et voi reitittää takaisin, joten käännät uudelleen. Se toimii, mutta lokit kantavat nyt kaksi hyppyä yksityistä osoitteistusta ja mikä tahansa tutkinta tarvitsee molemmat kartoitukset. Käytäntöperusteinen IPsec lisää kolmannen käänteen: käännä ennen käytännön osumista ja saat SA:n, joka on ylhäällä ilman liikennettä, mikä luetaan palomuurin viaksi eikä NAT:n viaksi.

Sitten on testi, joka menee läpi, ja käyttöönotto, joka epäonnistuu. NAT-komennon ajaminen käsin todistaa mekanismin, ei kokoonpanoa. Ajonaikana lisätty sääntö katoaa uudelleenkäynnistyksessä tai seuraavassa liitäntätapahtumassa, ja liitäntään sidottu Masquerade-sääntö, jonka numero vaihtuu, voi hiljaa muuttaa osoitetta, jonka kauko-osa näkee. Laita sääntö sen omistavan palomuurin kokoonpanoon ja testaa uudelleen yhteyden palauttamisen jälkeen.

Tarkistuslista ennen säännön tallentamista

Nimeä ensin suunta: lähde, kohde vai molemmat. Selvitä sitten, kenen on pidettävä tila — yhdyskäytävän, ylemmän reitittimen vai IPsec-vastapuolen — ja vahvista, että vastausreitti palaa sen kautta. Rajaa sääntö asiakasalueeseen, kohteeseen ja liitäntään, joita todella tarkoitat, ja päätä etukäteen, pitäisikö kauko-osan nähdä yhdyskäytävä vai asiakkaan alkuperäinen osoite.

Testaa asiakkaasta, älä yhdyskäytävästä. Yhdyskäytävän omalla selaimella voi ohittaa asiakaskäännössäännön kokonaan, joten siellä toimiva sivu ei todista tunnelista mitään. Lähetä yksi asiakkaasta lähtevä pyyntö, seuraa laskureita ja conntrack-taulua ja toista se tunnelin uudelleenyhdistämisen ja WAN-osoitteen muutoksen jälkeen, jos jompikumpi on mahdollinen työpaikallasi.