SNAT, DNAT un Masquerade: ko dara katrs VPN NAT noteikums

Ievietojiet uztveršanu abās VPN vārtejas pusēs, un viena plūsma var parādīt četras dažādas adreses. Avota NAT pārraksta, no kurienes pakete apgalvo, ka nāk; galamērķa NAT pārraksta, kurp tā iet. Masquerade nav trešais virziens, tā ir avota NAT noteikums, kas adresi ņem no izejošās saskarnes, nevis no fiksētas vērtības. Nosauciet, kura no trim jums patiešām vajadzīga, un lielākā daļa „VPN ir salūzis“ biļešu sašaurinās līdz jautājumam par atgriešanās ceļu.

Ko pārraksta katrs noteikums

Avota NAT, parasti rakstīts SNAT, maina plūsmas avota adresi, kad tā pamet maršrutētāju vai vārteju. Saņemošais pakalpojums atbild uz pārtulkoto adresi, un tulkojošā kaste atceļ izmaiņu ar stāvokli, ko tā turēja šim savienojumam. Linux šis stāvoklis dzīvo conntrack, tāpēc conntrack -L izdrukā sākotnējos un atbildes pārus blakus.

Galamērķa NAT, DNAT, tā vietā maina galamērķi. Paketi, kas adresēta publiskai adresei uz UDP 51820, var pārrakstīt uz iekšēju WireGuard serveri 10.8.0.2:51820. Tā mājas maršrutētājs vai mākoņa slodzes balansētājs publicē VPN klausītāju, un tas neko nesaka par to, ko tunelis drīkst pārvadāt pēc tam.

Masquerade pieder SNAT saimei. Noteikums nenosauc nevienu adresi; tas izmanto to, kas izejošajai saskarnei ir paketei aizejot. Linux tam dod savu mērķi, un tas ir ierastā izvēle WAN saskarnē, kas adresi iegūst no DHCP vai PPPoE.

Kur dzīvo kartējums, tur nosaka kļūmi

Pierakstiet pāri katrā robežā: pirms tuneļa, tā iekšienē un publiskajā saskarnē. Uztveršana tuneļa iekšienē likumīgi atšķiras no tās ārpusē, un ikviens, kas salīdzina abas, nezinot, kur notiek tulkošana, vajās nepareizo resursdatoru.

Atgaitas plūsmai jāiet caur ierīci, kas tur kartējumu. Ja atbilde izvēlas citu maršrutu, otru augšupējo savienojumu, politikas maršrutu vai pakalpojumu sniedzēju, kas nekad nav dzirdējis par jūsu privāto diapazonu, stāvokļa apgrieztā tulkošana nekad nenotiek, un klients redz vienvirziena plūsmu. Vairāk avota NAT reti salabo trūkstošu atgaitas maršrutu; tas var paslēpt simptomu vienā plūsmā un salauzt uz adresēm balstītu politiku visur citur.

Cita izplatīta kļūda ir gaidīt, ka tunelis radīs maršrutējamību. Privātam klientam, kura paketes iet uz internetu, vajag derīgu izejas kārtību: noklusējuma maršrutu, pārsūtošu vārteju un parasti avota tulkojumu uz publisku adresi. Šifrēšana vien privātu adresi nepadara sasniedzamu.

Masquerade vai skaidrs SNAT

Salīdziniet tos pēc tā, ko tie sola. Masquerade izvēlas izejas adresi, skaidrs SNAT to nofiksē. Vārtejā ar stabilu publisku adresi fiksēšana dod žurnāliem un partneru atļauju sarakstiem vienu paredzamu vērtību. Dinamiskā WAN saitē nofiksēta SNAT adrese kļūst nepareiza tajā brīdī, kad mainās noma, un tieši šim gadījumam Masquerade tika būvēts.

Apjoms ir tikpat svarīgs kā izvēle. Masquerade noteikums, kas atbilst katrai paketei, kas pamet vārteju, bez avota vai galamērķa ierobežojuma, pārtulko arī plūsmu, ko gribējāt atstāt neskartu, tostarp plūsmu uz citiem privātiem tīkliem. Ierobežojiet noteikumu ar klientu diapazonu, paredzēto galamērķi un saskarni.

Uz politiku balstīts IPsec ir vieta, kur tas kodīgāk. strongSwan pārsūtīšanas rokasgrāmata izstaigā IP pārsūtīšanas ieslēgšanu un avota NAT noteikuma pievienošanu klientiem, un tā pati dokumentācija aptver tās plūsmas izslēgšanu, kurai jāsaglabā sākotnējā adrese. Pārtulkojiet avotu, pirms tam pieskaņojas drošības politika, un tunelis var pacelties, kamēr plūsma joprojām krīt, jo pakete vairs neizskatās pēc sarunātā selektora.

Izlemiet arī, ko drīkst redzēt tālais gals. Pēc tulkošanas pakalpojums redz vārteju, nevis atsevišķu klientu. Tas vienkāršo atgaitas maršrutēšanu un vienlaikus izlīdzina žurnālus un padara atļauju sarakstus uz klientu bezjēdzīgus. Ja klientu adrešu saglabāšana ir svarīga, plānojiet maršrutētu atgaitas ceļu, tā vietā lai tās slēptu, lai tests izietu.

Noteikumu lasīšana Linux vārtejā

Attālās piekļuves vārtejai ar klientiem 10.8.0.0/24 tīklā un WAN saskarni ar nosaukumu eth0 vajag ieslēgtu pārsūtīšanu un filtra politiku, kas atļauj plūsmu, pirms jebkurš NAT noteikums var palīdzēt. iptables versija tur abus virzienus nat tabulā:

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 forma izmanto tos pašus divus āķus ar nosauktu saskarni un skaidru ķēdi:

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

Abi fragmenti pieņem, ka filtra ķēde jau pieņem pārsūtīto plūsmu. NAT nav atļaujas noteikums, un pareizi pārtulkota pakete joprojām var tikt nomesta vienu tabulu vēlāk. Apstipriniet dzīvo kartējumu ar conntrack -L, apstipriniet, kas ielādēts, ar nft list ruleset vai iptables-save -t nat, pēc tam veiciet uztveršanu abās saskarnēs, lai redzētu, ka adrese tiešām mainās.

Kļūmes režīmi, kas izskatās kā slikts noteikums

Matadatas plūsma ir klasika. Iekšējam klientam, kas sasniedz iekšējo serveri caur servera publisko adresi, vajag DNAT ceļā iekšā un avota tulkojumu ceļā atpakaļ ārā, citādi serveris atbild tieši klientam un atbilde tiek noraidīta. Labojums ir otrs, šaurāks noteikums šim iekšējā-uz-publisko gadījumam, nevis plašāks Masquerade noteikums visam.

Dubultā tulkošana ir klusā. Klients, kas jau ir aiz operatora līmeņa NAT, ierodas jūsu vārtejā ar adresi, kuru nevarat maršrutēt atpakaļ, tāpēc tulkojat vēlreiz. Tas strādā, bet žurnālos tagad ir divi privātas adresācijas lēcieni, un jebkuram izmeklēšanai vajag abus kartējumus. Uz politiku balstīts IPsec pievieno trešo pagriezienu: pārtulkojiet pirms politikas atbilstības, un jūs iegūstat SA, kas ir uzcelts bez plūsmas, kas iet cauri, kas lasās kā ugunsmūra, nevis NAT kļūda.

Tad ir tests, kas iziet, un izvietošana, kas cieš neveiksmi. NAT komandas palaišana ar roku pierāda mehānismu, nevis konfigurāciju. Izpildlaikā pievienots noteikums pazūd pārstartējot vai nākamajā saskarnes notikumā, un Masquerade noteikums, kas piesaistīts saskarnei, kura maina numuru, var klusi mainīt adresi, ko redz tālais gals. Ielieciet noteikumu īpašnieka ugunsmūra konfigurācijā un pārbaudiet vēlreiz pēc atkārtotas savienošanas.

Kontrolsaraksts pirms noteikuma saglabāšanas

Vispirms nosauciet virzienu: avots, galamērķis vai abi. Tad nosakiet, kam jātur stāvoklis – vārtejai, augstākajam maršrutētājam vai IPsec partnerim –, un apstipriniet, ka atbildes ceļš atgriežas caur to. Ierobežojiet noteikumu ar klientu diapazonu, galamērķi un saskarni, ko tiešām domājat, un iepriekš izlemiet, vai tālajam galam jāredz vārteja vai sākotnējā klienta adrese.

Pārbaudiet no klienta, nevis no vārtejas. Pārlūks pašā vārtejā var pilnībā apiet klienta tulkošanas noteikumu, tāpēc lapa, kas tur strādā, neko nepierāda par tuneli. Nosūtiet vienu pieprasījumu, kas nāk no klienta, vērojiet skaitītājus un conntrack tabulu, un atkārtojiet pēc tuneļa atkārtotas savienošanas un WAN adreses maiņas, ja vismaz viens no tiem ir iespējams jūsu darbavietā.