SNAT, DNAT i Masquerade: što radi svako VPN NAT pravilo

Postavite snimanje s obje strane VPN prolaza i jedan tok može pokazati četiri različite adrese. Izvorni NAT prepisuje mjesto odakle paket tvrdi da dolazi; odredišni NAT prepisuje mjesto kuda ide. Masquerade nije treći smjer, to je pravilo izvornog NAT-a koje uzima adresu od izlaznog sučelja umjesto fiksne vrijednosti. Imenujte koje od tri stvarno trebate i većina tiketa „VPN je pokvaren“ svodi se na pitanje o povratnom putu.

Što svako pravilo prepisuje

Izvorni NAT, obično napisan SNAT, mijenja izvornu adresu toka dok napušta usmjerivač ili prolaz. Usluga koja prima odgovara na prevedenu adresu, a kutija koja prevodi poništava promjenu koristeći stanje koje je čuvala za tu vezu. Na Linuxu to stanje živi u conntracku, zato conntrack -L ispisuje originalne i povratne torke jedne pokraj drugih.

Odredišni NAT, DNAT, mijenja odredište umjesto toga. Paket upućen na javnu adresu na UDP 51820 može se prepisati na interni WireGuard poslužitelj na 10.8.0.2:51820. Tako kućni usmjerivač ili oblak balanser objavljuje VPN slušatelja, i to ne govori ništa o tome što tunel smije nositi poslije.

Masquerade pripada obitelji SNAT. Pravilo ne imenuje adresu; koristi onu koju izlazno sučelje ima kad paket izađe. Linux mu daje vlastitu metu, i to je uobičajen izbor na WAN sučelju koje adresu dobiva od DHCP ili PPPoE.

Gdje mapa živi, određuje kvar

Zapišite torku na svakoj granici: prije tunela, unutar njega i na javnom sučelju. Snimanje unutar tunela legitimno se razlikuje od onog izvan njega, i svatko ko uspoređuje ta dva a ne zna gdje se prijevod događa tražit će pogrešnog domaćina.

Povratni promet mora proći kroz uređaj koji drži mapu. Ako odgovor krene drugim putem, drugim uzlaznim linkom, rutom po politici ili pružateljem koji nikad nije čuo za vaš privatni raspon, prijevod sa stanjem se nikad ne dogodi i klijent vidi jednosmjerni promet. Dodavanje još izvornog NAT-a rijetko popravlja povratni put koji nedostaje; može sakriti simptom na jednom toku dok kvari politiku zasnovanu na adresama svuda drugdje.

Druga česta pogreška je očekivati da tunel stvara rutabilnost. Privatnom klijentu čiji paketi izlaze na internet treba valjan izlazni aranžman: podrazumijevana ruta, prolaz koji prosljeđuje i obično izvorni prijevod na javnu adresu. Šifriranje samo po sebi ne čini privatnu adresu dostupnom.

Masquerade ili eksplicitni SNAT

Usporedite ih po tome što obećavaju. Masquerade bira izlaznu adresu, eksplicitni SNAT je fiksira. Na prolazu sa stabilnom javnom adresom fiksiranje daje logovima i partnerskim listama dopuštenja jednu predvidivu vrijednost. Na dinamičnom WAN linku fiksirana SNAT adresa postaje pogrešna u trenutku kad se zakup promijeni, a upravo je za taj slučaj Masquerade napravljen.

Opseg je važan koliko i izbor. Masquerade pravilo koje pogađa svaki paket koji napusti prolaz, bez ograničenja izvora ili odredišta, prevodi i promet koji ste namjeravali ostaviti netaknutim, uključujući promet prema drugim privatnim mrežama. Ograničite pravilo na raspon klijenata, željeno odredište i sučelje.

IPsec zasnovan na politici tu najviše boli. strongSwanov vodič za prosljeđivanje prolazi kroz uključivanje IP prosljeđivanja i dodavanje pravila izvornog NAT-a za klijente, a ista dokumentacija pokriva i izuzimanje prometa koji mora zadržati originalnu adresu. Prevedite izvor prije nego ga sigurnosna politika pogodi, i tunel može stati dok promet i dalje pada, jer paket više ne izgleda kao pregovarani selektor.

Odlučite i što daleki kraj treba vidjeti. Poslije prijevoda usluga vidi prolaz, a ne pojedinačnog klijenta. To pojednostavljuje povratno rutiranje i istovremeno izravnava logove i obesmišljava liste dopuštenja po klijentu. Ako je očuvanje adresa klijenata važno, planirajte rutirani povratni put umjesto da ih skrivate da bi test prošao.

Čitanje pravila na Linux prolazu

Prolaz za daljinski pristup s klijentima na 10.8.0.0/24 i WAN sučeljem imena eth0 treba uključeno prosljeđivanje i filtarsku politiku koja dopušta tok prije nego ijedno NAT pravilo pomogne. Inačica s iptablesom drži oba smjera u tablici 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

nftables oblik koristi ista dva kuka s imenovanim sučeljem i eksplicitnim lancem:

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 isječka pretpostavljaju da filtarski lanac već prihvaća proslijeđeni tok. NAT nije pravilo dopuštenja, i ispravno preveden paket može i dalje biti odbačen jednu tablicu kasnije. Potvrdite živu mapu s conntrack -L, potvrdite što je učitano s nft list ruleset ili iptables-save -t nat, pa snimite na oba sučelja da vidite da se adresa zaista mijenja.

Načini kvara koji izgledaju kao loše pravilo

Promet tipa ukosnice je klasika. Interni klijent koji do internog poslužitelja dolazi preko javne adrese poslužitelja treba DNAT na ulazu i izvorni prijevod na povratnom izlazu, inače poslužitelj odgovara ravno klijentu i odgovor biva odbijen. Ispravak je drugo, uže pravilo za taj slučaj interno-prema-javnom, a ne šire Masquerade pravilo za sve.

Dvostruki prijevod je tihi. Klijent koji je već iza NAT-a na razini operatora dolazi na vaš prolaz s adresom koju ne možete rutirati natrag, pa prevodite ponovno. Radi, ali logovi sada nose dva skoka privatnog adresiranja i svaka istraga treba obje mape. IPsec zasnovan na politici dodaje treći obrat: prevedite prije poklapanja politike i dobivate SA koji je podignut bez prometa koji prolazi, što se čita kao greška u vatrozidu, ne u NAT-u.

Zatim tu je test koji prolazi i implementacija koja pada. Ručno pokretanje NAT naredbe dokazuje mehanizam, ne konfiguraciju. Pravilo dodano u toku rada nestaje pri ponovnom pokretanju ili na sljedećem događaju sučelja, a Masquerade pravilo vezano za sučelje kojemu se mijenja broj može tiho promijeniti adresu koju daleki kraj vidi. Stavite pravilo u konfiguraciju vatrozida koji ga posjeduje i ponovno testirajte nakon ponovnog spajanja.

Kontrolni popis prije nego spremite pravilo

Prvo imenujte smjer: izvor, odredište ili oboje. Zatim odredite ko mora držati stanje — prolaz, usmjerivač uzvodno ili IPsec peer — i potvrdite da se povratni put vraća kroz njega. Ograničite pravilo na raspon klijenata, odredište i sučelje koje zaista imate na umu, i unaprijed odlučite treba li daleki kraj vidjeti prolaz ili originalnu adresu klijenta.

Testirajte s klijenta, ne s prolaza. Preglednik na samom prolazu može posve zaobići pravilo prijevoda za klijente, pa stranica koja tamo radi ne dokazuje ništa o tunelu. Pošaljite jedan zahtjev koji potječe od klijenta, gledajte brojače i conntrack tablicu, i ponovite nakon ponovnog spajanja tunela i promjene WAN adrese ako je bilo što od toga moguće tamo gdje radite.