SNAT, DNAT kaj Masquerade: kion faras ĉiu VPN-NAT-regulo

Metu kapton ambaŭflanke de VPN-pordego kaj unu fluo povas montri kvar malsamajn adresojn. Fonta NAT reskribas, de kie la paketo asertas veni; cella NAT reskribas, kien ĝi iras. Masquerade ne estas tria direkto, ĝi estas fonta-NAT-regulo, kiu prenas sian adreson de la elira interfaco anstataŭ fiksa valoro. Nomu, kiun el la tri vi vere bezonas, kaj la plej multaj biletoj «la VPN estas rompita» kolapsas al demando pri la revena vojo.

Kion ĉiu regulo reskribas

Fonta NAT, kutime skribata SNAT, ŝanĝas la fontan adreson de fluo dum ĝi forlasas enkursigilon aŭ pordegon. La ricevanta servo respondas al la tradukita adreso, kaj la skatolo, kiu tradukas, malfaras la ŝanĝon per la stato, kiun ĝi konservis por tiu konekto. En Linux tiu stato loĝas en conntrack, tial conntrack -L presas la originalajn kaj respondajn opojn unu apud la alia.

Cela NAT, DNAT, ŝanĝas la celon anstataŭe. Paketo adresita al publika adreso sur UDP 51820 povas esti reskribita al interna WireGuard-servilo ĉe 10.8.0.2:51820. Tiel hejma enkursigilo aŭ nuba ŝarĝbalancilo publikigas VPN-aŭskultanton, kaj tio diras nenion pri tio, kion la tunelo povas porti poste.

Masquerade apartenas al la familio SNAT. La regulo nomas neniun adreson; ĝi uzas tiun, kiun la elira interfaco havas kiam la paketo foriras. Linux donas al ĝi propran celon, kaj ĝi estas la kutima elekto sur WAN-interfaco, kiu ricevas sian adreson de DHCP aŭ PPPoE.

Kie loĝas la mapado decidas la fiaskon

Notu la opon ĉe ĉiu limo: antaŭ la tunelo, ene de ĝi kaj sur la publika interfaco. Kapto ene de la tunelo laŭleĝe diferencas de unu ekstere, kaj iu ajn, kiu komparas la du sen scii, kie okazas la traduko, ĉasos la malĝustan gastiganton.

Revena trafiko devas pasi tra la aparato, kiu tenas la mapadon. Se la respondo prenas alian vojon, duan suprenligon, politikan vojon aŭ provizanton, kiu neniam aŭdis pri via privata gamo, la stata inversa traduko neniam okazas kaj la kliento vidas unudirektan trafikon. Aldoni pli da fonta NAT malofte riparas mankantan revenan vojon; ĝi povas kaŝi la simpton sur unu fluo dum ĝi rompas adres-bazitan politikon ĉie alie.

La alia ofta eraro estas atendi, ke tunelo kreu enkursigeblecon. Privata kliento, kies paketoj iras al la interreto, bezonas validan eliran aranĝon: defaŭltan vojon, plusendan pordegon kaj kutime fontan tradukon al publika adreso. Ĉifrado sola ne faras privatan adreson atingebla.

Masquerade aŭ eksplicita SNAT

Komparu la du laŭ tio, kion ili promesas. Masquerade elektas la eliran adreson, eksplicita SNAT fiksas ĝin. Sur pordego kun stabila publika adreso, fiksado donas al protokoloj kaj al partnerecaj permeslistoj unu antaŭvideblan valoron. Sur dinamika WAN-ligilo, fiksita SNAT-adreso fariĝas malĝusta en la momento, kiam la luo ŝanĝiĝas, kaj ĝuste por tiu kazo Masquerade estis konstruita.

La amplekso gravas same kiel la elekto. Regulo Masquerade, kiu kongruas kun ĉiu paketo forlasanta la pordegon, sen limo de fonto aŭ celo, tradukas ankaŭ trafikon, kiun vi intencis konservi sendifekta, inkluzive trafikon al aliaj privataj retoj. Limigu la regulon al la klienta gamo, la celata celo kaj la interfaco.

Politik-bazita IPsec estas kie tio mordas plej forte. La gvidilo de strongSwan pri plusendado trairas ŝaltadon de IP-plusendado kaj aldonadon de fonta-NAT-regulo por klientoj, kaj la sama dokumentaro kovras ekskludon de trafiko, kiu devas konservi sian originalan adreson. Traduku fonton antaŭ ol la sekurec-politiko kongruas kun ĝi, kaj la tunelo povas leviĝi dum la trafiko ankoraŭ falas, ĉar la paketo ne plu aspektas kiel la intertraktita selektilo.

Decidu ankaŭ, kion la malproksima flanko devas vidi. Post la traduko servo vidas la pordegon, ne la individuan klienton. Tio simpligas revenan enkursigadon kaj samtempe platigas protokolojn kaj nuligas permeslistojn por unuopa kliento. Se konservado de klientaj adresoj gravas, planu enkursigitan revenan vojon anstataŭ kaŝi ilin por ke testo sukcesu.

Legi la regulojn sur Linux-pordego

Pordego por fora aliro kun klientoj sur 10.8.0.0/24 kaj WAN-interfaco nomata eth0 bezonas ŝaltitan plusendadon kaj filtran politikon, kiu permesas la fluon, antaŭ ol iu ajn NAT-regulo povas helpi. La iptables-versio tenas ambaŭ direktojn en la tabelo 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

La formo nftables uzas la samajn du hokojn kun nomita interfaco kaj eksplicita ĉeno:

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

Ambaŭ fragmentoj supozas, ke la filtra ĉeno jam akceptas la plusenditan fluon. NAT ne estas permesa regulo, kaj ĝuste tradukita paketo povas ankoraŭ esti forĵetita unu tabelon poste. Konfirmu la vivan mapadon per conntrack -L, konfirmu, kio estas ŝarĝita, per nft list ruleset aŭ iptables-save -t nat, kaj poste kaptu sur ambaŭ interfacoj por vidi, ke la adreso vere ŝanĝiĝas.

Fiaskmanieroj, kiuj aspektas kiel malbona regulo

Hararloka trafiko estas la klasikaĵo. Interna kliento, kiu atingas internan servilon per la publika adreso de la servilo, bezonas la DNAT survoje enen kaj fontan tradukon survoje reen, alie la servilo respondas rekte al la kliento kaj la respondo estas rifuzita. La solvo estas dua, pli mallarĝa regulo por tiu kazo interna-al-publika, ne pli larĝa regulo Masquerade por ĉio.

Duobla traduko estas la kvieta. Kliento jam malantaŭ NAT de operatora grado alvenas al via pordego kun adreso, kiun vi ne povas enkursigi reen, do vi tradukas denove. Ĝi funkcias, sed protokoloj nun portas du saltojn de privata adresado kaj iu ajn esploro bezonas ambaŭ mapadojn. Politik-bazita IPsec aldonas trian tordon: traduku antaŭ la politika kongruo kaj vi ricevas SA, kiu estas levita sen trafiko pasanta, kio legiĝas kiel fajroŝirma cimo, ne NATa.

Poste estas la testo, kiu sukcesas, kaj la lanĉo, kiu fiaskas. Ruli la NAT-komandon permane pruvas la mekanismon, ne la agordon. Regulo aldonita dum runtime malaperas ĉe restartigo aŭ ĉe la sekva interfaca evento, kaj Masquerade-regulo ligita al interfaco, kiu renumeriĝas, povas silente ŝanĝi la adreson, kiun la malproksima flanko vidas. Metu la regulon en la agordon de la posedanta fajroŝirmilo kaj retestu post rekonekto.

Kontrola listo antaŭ ol konservi la regulon

Unue nomu la direkton: fonto, celo aŭ ambaŭ. Poste identigu, kiu devas teni la staton — la pordego, la supra enkursigilo aŭ la IPsec-partnero — kaj konfirmu, ke la responda vojo revenas tra ĝi. Limigu la regulon al la klienta gamo, la celo kaj la interfaco, kiujn vi vere intencas, kaj anticipe decidu, ĉu la malproksima flanko devas vidi la pordegon aŭ la originalan klientan adreson.

Testu de kliento, ne de la pordego. Retumilo sur la pordego mem povas tute ĉirkaŭiri la klientan tradukan regulon, do paĝo funkcianta tie pruvas nenion pri la tunelo. Sendu unu peton originantan de kliento, observu la nombrilojn kaj la tabelon conntrack, kaj ripetu post rekonekto de la tunelo kaj ŝanĝo de WAN-adreso, se iu el la du eblas tie, kie vi laboras.