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

Postavite snimanje sa 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 interfejsa umjesto fiksne vrijednosti. Imenujte koje od tri vam zaista treba i većina tiketa „VPN je pokvaren“ svodi se na pitanje o povratnom putu.

Šta svako pravilo prepisuje

Izvorni NAT, obično napisan SNAT, mijenja izvornu adresu toka dok napušta ruter 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 conntrack-u, zato conntrack -L ispisuje originalne i povratne torke jedne pored 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 server na 10.8.0.2:51820. Tako kućni ruter ili oblak balanser objavljuje VPN slušaoca, i to ne govori ništa o tome šta tunel smije nositi poslije.

Masquerade pripada porodici SNAT. Pravilo ne imenuje adresu; koristi onu koju izlazni interfejs ima kad paket izađe. Linux mu daje vlastitu metu, i to je uobičajen izbor na WAN interfejsu koji adresu dobija od DHCP ili PPPoE.

Gdje mapa živi, određuje kvar

Zapišite torku na svakoj granici: prije tunela, unutar njega i na javnom interfejsu. Snimanje unutar tunela legitimno se razlikuje od onog izvan njega, i svako ko poredi ta dva a ne zna gdje se prevod događa tražiće pogrešnog domaćina.

Povratni saobraćaj mora proći kroz uređaj koji drži mapu. Ako odgovor krene drugim putem, drugim uzlaznim linkom, rutom po politici ili provajderom koji nikad nije čuo za vaš privatni opseg, prevod sa stanjem se nikad ne dogodi i klijent vidi jednosmjerni saobraćaj. 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 greš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 prevod na javnu adresu. Šifrovanje samo po sebi ne čini privatnu adresu dostupnom.

Masquerade ili eksplicitni SNAT

Uporedite ih po tome šta obećavaju. Masquerade bira izlaznu adresu, eksplicitni SNAT je fiksira. Na prolazu sa stabilnom javnom adresom fiksiranje daje logovima i partnerskim listama dozvola 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.

Obim 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 saobraćaj koji ste namjeravali ostaviti netaknutim, uključujući saobraćaj ka drugim privatnim mrežama. Ograničite pravilo na opseg klijenata, željeno odredište i interfejs.

IPsec zasnovan na politici tu najviše boli. strongSwan-ov 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 saobraćaja koji mora zadržati originalnu adresu. Prevedite izvor prije nego ga sigurnosna politika pogodi, i tunel može stati dok saobraćaj i dalje pada, jer paket više ne izgleda kao pregovoreni selektor.

Odlučite i šta daleki kraj treba da vidi. Poslije prevoda usluga vidi prolaz, a ne pojedinačnog klijenta. To pojednostavljuje povratno rutiranje i istovremeno izravnava logove i obesmišljava liste dozvola 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 sa klijentima na 10.8.0.0/24 i WAN interfejsom po imenu eth0 treba uključeno prosljeđivanje i filtarsku politiku koja dopušta tok prije nego ijedno NAT pravilo pomogne. Verzija sa iptables drži oba smjera u nat tabeli:

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 sa imenovanim interfejsom 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ć prihvata proslijeđeni tok. NAT nije pravilo dozvole, i ispravno preveden paket može i dalje biti odbačen jednu tabelu kasnije. Potvrdite živu mapu sa conntrack -L, potvrdite šta je učitano sa nft list ruleset ili iptables-save -t nat, pa snimite na oba interfejsa da vidite da se adresa zaista mijenja.

Načini kvara koji izgledaju kao loše pravilo

Saobraćaj tipa ukosnice je klasika. Interni klijent koji do internog servera dolazi preko javne adrese servera treba DNAT na ulazu i izvorni prevod na povratnom izlazu, inače server odgovara pravo klijentu i odgovor biva odbijen. Ispravka je drugo, uže pravilo za taj slučaj interno-prema-javnom, a ne šire Masquerade pravilo za sve.

Dvostruki prevod je tihi. Klijent koji je već iza NAT-a na razini operatora dolazi na vaš prolaz sa adresom koju ne možete rutirati nazad, pa prevodite ponovo. Radi, ali logovi sada nose dva skoka privatnog adresiranja i svaka istraga treba obje mape. IPsec zasnovan na politici dodaje treći obrt: prevedite prije poklapanja politike i dobijate SA koji je podignut bez saobraćaja koji prolazi, što se čita kao greška u firewallu, ne u NAT-u.

Zatim tu je test koji prolazi i implementacija koja pada. Ručno pokretanje NAT komande dokazuje mehanizam, ne konfiguraciju. Pravilo dodano u toku rada nestaje pri restartu ili na sljedećem događaju interfejsa, a Masquerade pravilo vezano za interfejs koji mijenja broj može tiho promijeniti adresu koju daleki kraj vidi. Stavite pravilo u konfiguraciju firewalla koji ga posjeduje i ponovo testirajte poslije ponovnog spajanja.

Kontrolna lista prije nego sačuvate pravilo

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

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