Dalawang kliyenteng VPN, dalawang pampublikong address: itugma ang SNAT

Dalawang kliyenteng VPN ang maaaring lumabas sa dalawang magkaibang pampublikong address na IPv4, at ang tuntuning gumagawa nito ay mas maikli kaysa inaasahan ng karamihan. Hindi ang sintaks ng iptables ang nagpapagana nito kundi ang kalagayan ng packet kapag umabot ito sa egress chain: kailangan pa ring makilala ng pinagmulang address doon ang mga kliyente. Kung pinagsama na ng naunang masquerade ang dalawa sa isang address, walang tuntunin kada kliyente ang makapagbabalik ng pagkakaiba. Ayusin muna ang isyung iyon, pagkatapos isulat ang salin.

Aling pagkakakilanlan ang nakaligtas hanggang sa gateway

Tinutugma ng tuntunin ang pinagmulang address ng packet, hindi ang username ng VPN at hindi ang pangalang ipinapakita ng aplikasyon ng kliyente. Ang lahat ng nagsasalin ng packet nang mas maaga sa landas ang nagtatakda kung ano pa ang nakikita ng iyong tuntunin. Patakbuhin ang talahanayang nat sa pagkakasunod-sunod at hanapin ang punto kung saan hiwalay pa rin ang pinagmulan sa bawat kliyente.

iptables -t nat -S POSTROUTING

Basahin ang listahang iyon mula sa itaas. Ang tuntuning masquerade malapit sa itaas ay nagre-rewrite ng pinagmulan para sa bawat tugmang daloy, at ang mga entry kada kliyente na inilagay pagkatapos nito ay tumutugma sa address na wala na. Kapag dalawang kagamitang LAN ang nagbabahagi ng isang tunnel at dumarating bilang isang panloob na address, kailangang magbago ang disenyo bago pa gawin ito ng firewall: panatilihing hiwalay ang kanilang mga saklaw ng pinagmulan o bigyan ang bawat isa ng sariling panloob na address.

Itali ang pagtatalaga ng panloob na address sa authenticated na kliyente. Ang pagbibigay ng address na iyon sa ibang kagamitan ay nagbibigay din ng patakaran sa labas, at ang pagsasalin ng pinagmulan ay hindi patunay ng pagkakakilanlan sa sarili nito.

Hindi makakaimbento ng address ang pagsasalin

Bawat pampublikong address ay dapat italaga o i-route sa egress point na ito, at ang mga sagot ay dapat makahanap ng daan pabalik. Ang tuntuning nagpapadala ng trapiko mula sa address na walang nagro-route pabalik ay itinatapon sa dulong bahagi o sinasagot sa host na hindi kailanman humiling nito. Ang instans ng cloud provider ay karaniwang may pampublikong address na isinalin sa pribadong interface address bago lumabas ang packet, kaya ang pinagmulan ng SNAT ay dapat ang address na tatanggapin ng provider, hindi ang halagang ipinapakita ng console. Basahin ang modelo ng address ng provider at sundin ito sa halip na kopyahin ang pampublikong halaga sa bawat packet.

Sa pagsasagawa, nangangahulugan ito ng pagsuri sa naka-route na prefix sa console ng provider bago hawakan ang firewall, at paggamit ng pribadong interface address bilang pinagmulan ng pagsasalin kapag ang pagmamapa ay isa-sa-isa. Ang mga address sa mga halimbawa sa ibaba ay galing sa mga saklaw ng dokumentasyon, kaya ang unang dapat palitan ay ang teksto ng address mismo.

Ipasok bago ang generic na masquerade

Kumpirmahin ang egress interface at ang kasalukuyang chain bago magdagdag ng anuman. Ang una ang nagtatakda kung aling mga packet ang matutugunan ng tuntunin, at ang pangalawa ay nagpapakita kung ano ang nakatayo na sa harap nito.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Pinapangalanan ng unang utos ang interface kung saan talaga lumalabas ang packet patungong internet. Ipinapakita ng pangalawa ang chain kasama ang mga numero ng linya. Ang generic na entry ng masquerade ang linyang dapat mong manatili sa itaas.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Ang dalawang tuntunin sa itaas ay tumutugma sa tig-isang panloob na address, nililimitahan ang tugma sa egress interface at tahasang itinatakda ang pinagmulan. Ipasok sa halip na idagdag: sa posisyon 1 sinusuri ang mga ito bago ang linya ng masquerade. Hindi mahalaga ang pagkakasunod-sunod ng dalawa dahil magkaiba ang kanilang pinagmulan. Palitan ang ens3 ng iniulat ng utos ng ruta, at ilayo ang iba pang tagapamahala ng firewall sa parehong hook, dahil dalawang tool na nagsusulat ng isang talahanayan ang karaniwang dahilan kung bakit walang epekto ang tamang tuntunin.

Patunayan ang pinagmulan sa bagong daloy

Ang stateful NAT ay nagtatali ng pagsasalin kapag nagsisimula ang isang daloy at ginagamit muli ito para sa mga susunod na packet, kaya ang sesyong binuksan bago ang pagbabago ay pinapanatili ang lumang pinagmulan pagkatapos ng pagbabago. Tanging bagong sinimulang koneksyon ang nagpapatunay ng tuntunin.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Basahin ang direksyon ng sagot ng entry na iyon: ang destinasyon nito ay ang address na nakikita ng malayong dulo bilang pinagmulan. Ihambing ito sa pampublikong address na nilayon mo, at ituring ang entry na may lumang address bilang patunay ng daloy na nagsimula nang masyadong maaga, hindi ng sirang tuntunin. Hilingin sa kliyente na magbukas ng bagong koneksyon, pagkatapos ulitin ang query. Ang pag-flush ng buong tracking table para pilitin ang pagsubok ay nakakaabala sa bawat iba pang sesyon sa gateway.

Hindi pa rin pumipili ng ruta ang pagsasalin, hindi pinapapasok ang daloy sa filter at hindi naglalathala ng inbound na serbisyo. Ang maling ruta at kulang na allow na tuntunin ay patuloy na nabigo kahit pagkatapos ng perpektong tuntunin ng SNAT. Suriin din ang IPv6 at anumang pangalawang egress path, pagkatapos itala ang mga pares na panloob-sa-pampubliko sa dokumentasyon ng firewall upang ang susunod na pagbabago ay magsimula sa pagmamapa at hindi sa teksto ng tuntunin.