SNAT, DNAT at Masquerade: ano ang ginagawa ng bawat NAT rule ng VPN

Maglagay ng capture sa magkabilang panig ng gateway ng VPN at isang flow ay maaaring magpakita ng apat na magkakaibang address. Binabago ng source NAT kung saan sinasabing galing ang packet; binabago ng destination NAT kung saan ito patungo. Ang Masquerade ay hindi ikatlong direksyon, ito ay tuntunin ng source NAT na kumukuha ng address mula sa palabas na interface sa halip na fixed na halaga. Pangalanan kung alin sa tatlo ang talagang kailangan mo at karamihan ng „sira ang VPN“ na ticket ay nagiging tanong tungkol sa daan pabalik.

Ano ang binabago ng bawat tuntunin

Ang source NAT, karaniwang isinusulat na SNAT, ay nagbabago ng source address ng isang flow kapag lumalabas ito sa router o gateway. Sinasagot ng serbisyong tumatanggap ang isinaling address, at binabalik ng kahon na nagtutumbas ang pagbabago gamit ang estado na itinago nito para sa koneksyong iyon. Sa Linux ang estadong iyon ay naninirahan sa conntrack, kaya ang conntrack -L ay nagpi-print ng orihinal at sagot na tuple nang magkatabi.

Ang destination NAT, DNAT, ay nagbabago ng destinasyon sa halip. Ang packet na nakasulat sa pampublikong address sa UDP 51820 ay maaaring isulat muli sa panloob na WireGuard server sa 10.8.0.2:51820. Ganito naglalathala ang router sa bahay o cloud load balancer ng tagapakinig ng VPN, at wala itong sinasabi tungkol sa maaaring dalhin ng tunnel pagkatapos.

Ang Masquerade ay kabilang sa pamilya ng SNAT. Hindi nagpapangalan ng address ang tuntunin; ginagamit nito ang address na hawak ng palabas na interface kapag umalis ang packet. Binibigyan ito ng Linux ng sariling target, at ito ang karaniwang pinipili sa WAN interface na kumukuha ng address mula sa DHCP o PPPoE.

Kung saan nakatira ang mapping ang nagtatakda ng pagkasira

Itala ang tuple sa bawat hangganan: bago ang tunnel, sa loob nito at sa pampublikong interface. Ang capture sa loob ng tunnel ay lehitimong naiiba sa nasa labas, at sinumang naghahambing sa dalawa nang hindi alam kung saan nangyayari ang pagsasalin ay hahabulin ang maling host.

Ang trapikong pabalik ay dapat dumaan sa device na may hawak ng mapping. Kung ang sagot ay kukuha ng ibang ruta, ikalawang uplink, ruta ng patakaran o provider na hindi pa nakarinig ng iyong pribadong saklaw, hindi kailanman mangyayari ang stateful na baliktad na pagsasalin at makikita ng kliyente ang trapikong isang direksyon. Ang pagdagdag ng mas maraming source NAT ay bihirang nag-aayos ng nawawalang ruta pabalik; maaari nitong itago ang sintomas sa isang flow habang sinisira ang patakarang nakabatay sa address sa lahat ng ibang lugar.

Ang isa pang karaniwang pagkakamali ay ang asahan na ang tunnel ay lilikha ng kakayahang ma-ruta. Ang pribadong kliyente na ang mga packet ay lumalabas sa internet ay kailangan ng wastong kaayusan sa paglabas: default na ruta, gateway na nagpapasa at karaniwang pagsasalin ng source sa pampublikong address. Ang encryption lamang ay hindi nagpapatawid sa pribadong address.

Masquerade o tahasang SNAT

Ihambing ang dalawa sa ipinapangako nila. Pinipili ng Masquerade ang address ng labasan, ipinupirmi ito ng tahasang SNAT. Sa gateway na may matatag na pampublikong address, ang pagpirmi ay nagbibigay sa mga log at listahan ng pahintulot ng partner ng isang mahuhulaang halaga. Sa pabagu-bagong WAN link, ang nakapirming SNAT address ay nagiging mali sa sandaling magbago ang lease, at ito mismo ang kaso na ginawa para sa Masquerade.

Ang saklaw ay kasinghalaga ng pagpili. Ang Masquerade na tuntuning tumutugma sa bawat packet na lumalabas sa gateway, na walang hangganan sa source o destinasyon, ay nagsasalin din ng trapikong nais mong iwanang buo, kasama ang trapiko patungo sa ibang pribadong network. Limitahan ang tuntunin sa saklaw ng kliyente, nilalayong destinasyon at interface.

Ang IPsec na nakabatay sa patakaran ang pinakamalupit na kagat nito. Ang gabay sa pagpapasa ng strongSwan ay dumadaan sa pagpapagana ng pagpapasa ng IP at pagdaragdag ng source NAT na tuntunin para sa mga kliyente, at sakop din ng parehong dokumento ang pagbubukod ng trapikong dapat panatilihin ang orihinal na address. Isalin ang source bago ito itugma ng patakarang panseguridad at maaaring umangat ang tunnel habang bumabagsak pa rin ang trapiko, dahil hindi na mukhang napagkasunduang selector ang packet.

Magpasya rin kung ano ang dapat makita ng malayong dulo. Pagkatapos ng pagsasalin, ang serbisyo ay nakikita ang gateway, hindi ang indibidwal na kliyente. Pinapasimple nito ang pagruruta pabalik at kasabay nitong pinapantay ang mga log at pinapawalang-bisa ang listahan ng pahintulot bawat kliyente. Kung mahalaga ang pagpapanatili ng address ng kliyente, magplano ng rutadong daan pabalik sa halip na itago ang mga ito para makapasa ang isang pagsubok.

Pagbasa ng mga tuntunin sa gateway na Linux

Ang gateway para sa malayuang pag-access na may mga kliyente sa 10.8.0.0/24 at WAN interface na tinatawag na eth0 ay kailangan ng nakapasang pagpapasa at patakaran ng pagsasala na pumapayag sa flow, bago makatulong ang anumang tuntunin ng NAT. Hinahawakan ng bersyon ng iptables ang dalawang direksyon sa talahanayang 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

Ginagamit ng anyong nftables ang parehong dalawang hook na may pinangalanang interface at tahasang chain:

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

Ipinapalagay ng dalawang sipi na tinatanggap na ng chain ng pagsasala ang ipinasang flow. Ang NAT ay hindi tuntunin ng pahintulot, at ang wastong isinaling packet ay maaari pa ring itapon sa susunod na talahanayan. Tiyakin ang buhay na mapping gamit ang conntrack -L, tiyakin kung ano ang nakaload gamit ang nft list ruleset o iptables-save -t nat, pagkatapos ay kumuha ng capture sa dalawang interface upang makita ang address na talagang nagbabago.

Mga moda ng pagkasira na mukhang masamang tuntunin

Ang hairpin traffic ang klasiko. Ang panloob na kliyente na umaabot sa panloob na server sa pamamagitan ng pampublikong address ng server ay kailangan ng DNAT sa papasok at pagsasalin ng source sa palabas pabalik, kung hindi ay direktang sasagot ang server sa kliyente at tatanggihan ang sagot. Ang lunas ay ikalawang mas makitid na tuntunin para sa kasong panloob-patungong-publiko, hindi mas malawak na Masquerade na tuntunin para sa lahat.

Ang dobleng pagsasalin ang tahimik. Ang kliyenteng nasa likod na ng carrier-grade NAT ay dumarating sa iyong gateway na may address na hindi mo maaaring iruta pabalik, kaya nagsasalin ka muli. Gumagana ito, ngunit may dalawang pagtalon na ng pribadong address ang mga log at kailangan ng imbestigasyon ang dalawang mapping. Ang IPsec na nakabatay sa patakaran ay nagdaragdag ng ikatlong biku: isalin bago ang tugma ng patakaran at makakakuha ka ng SA na nakatayo nang walang trapikong dumadaan, na binabasa na parang bug ng firewall at hindi ng NAT.

Pagkatapos ay may pagsubok na pumapasa at deployment na bigo. Ang pagpapatakbo ng NAT command sa kamay ay nagpapatunay ng mekanismo, hindi ng configuration. Ang tuntuning idinagdag habang tumatakbo ay nawawala sa reboot o sa susunod na pangyayari sa interface, at ang Masquerade na tuntuning nakatali sa interface na nagbabago ng numero ay maaaring tahimik na magbago ng address na nakikita ng malayong dulo. Ilagay ang tuntunin sa configuration ng firewall na nagmamay-ari nito at muling subukan pagkatapos ng muling pagkonekta.

Listahan ng pagsusuri bago i-save ang tuntunin

Pangalanan muna ang direksyon: source, destinasyon o pareho. Pagkatapos ay tukuyin kung sino ang dapat humawak ng estado — ang gateway, ang router sa itaas o ang kapareha ng IPsec — at tiyakin na bumabalik ang daan ng sagot sa pamamagitan nito. Limitahan ang tuntunin sa saklaw ng kliyente, destinasyon at interface na talagang nilalayon mo, at magpasya nang maaga kung ang malayong dulo ay dapat makakita ng gateway o ng orihinal na address ng kliyente.

Subukan mula sa kliyente, hindi mula sa gateway. Ang browser sa gateway mismo ay maaaring lubusang lumampas sa tuntunin ng pagsasalin ng kliyente, kaya ang pahinang gumagana doon ay walang pinapatunayan tungkol sa tunnel. Magpadala ng isang kahilingang nagmumula sa kliyente, panoorin ang mga counter at ang talahanayang conntrack, at ulitin pagkatapos ng muling pagkonekta ng tunnel at pagbabago ng address ng WAN kung alinman sa dalawa ay posible sa lugar na iyong pinagtatrabahuhan.