Ang Elastic IP ng EC2 ay hindi ang pribadong VPN address ng instance

May pribadong address ang instance, ang Elastic IP ay nauugnay dito, at may rutang idinadagdag sa VPN para sa publikong /32 na iyon sa pag-asang magiging isang bagay ang dalawa. Hindi sila nagiging isa. Ang Elastic IP ay isang pagsasalin na ginagawa sa labas ng bisita, ng gateway ng internet, sa trapikong dumadaan sa landas ng internet. Hindi kailanman nakikita ng operating system ng bisita ang address na iyon na naka-configure sa isang interface. Ang pagdaragdag nito sa isang interface ng tunnel ay hindi nagbubuo muli ng pagsasalin sa itaas at lumilikha ng pangalawa at magkasalungat na pagkakakilanlan para sa parehong makina.

Dalawang address, isang instance

Ang network interface ng instance ay may pribadong address sa loob ng VPC, at iyon ang address na alam ng bisita. Ang Elastic IP ay nauugnay sa parehong interface ngunit naninirahan sa publikong bahagi ng pagmamapa.

Lahat ng nakakarating sa instance sa pamamagitan ng internet ay dumarating na isinalin sa pribadong address. Lahat ng ipinapadala ng instance sa internet ay lumalabas na may Elastic IP bilang pinagmulan, muli dahil sa pagsasaling iyon.

Sa loob ng bisita may isang address. Sa labas may dalawa. Ang kawalan ng simetriya na iyon ang nagpapaliwanag sa karamihan ng kalituhan sa larangang ito. Hindi maaaring i-configure ng bisita kung ano ang isinasalin ng gateway. Maaari lamang itong sumagot sa address na talagang hawak nito.

Ano ang talagang ginagawa ng gateway ng internet

Ang dokumentasyon ng AWS tungkol sa gateway ng internet ay naglalarawan ng kaayusan: alam ng instance ang pribadong address nitong IPv4, at ibinibigay ng gateway ang katumbas na pagsasalin sa publikong IPv4 o Elastic IP para sa trapiko sa landas ng internet.

Iyon ay pagsasalin ng mga address ng network, hindi isang alias. Ang pagmamapa ay pinapanatili ng gateway, nakatali sa asosasyon, at nalalapat lamang sa mga packet na dumadaan dito. Alisin ang asosasyon at mawawala ang publikong pagkakakilanlan nang walang napapansin ang bisita.

Kaya ang pribadong packet ng VPN na nakatuon sa publikong /32 ay hindi muling binibigyang-kahulugan bilang pribadong packet patungo sa lokal na address ng bisita. Sinusundan ng packet ang rutang tumutugma dito, na nagpapadala nito sa gateway ng internet, at ang pag-uugali ng gateway ay depende sa kung pinapayagan ang landas sa dalawang direksyon.

Bakit nabibigo ang panlilinlang sa interface ng tunnel

Ang paglalaan ng Elastic IP sa isang interface ng tunnel ay humihiling sa bisita na ituring ang publikong address na lokal. Ngayon dalawang bagay ang nag-aangkin ng parehong address: ang pagsasalin ng gateway sa landas ng internet at ang lokal na interface sa loob ng tunnel. Walang pare-parehong sagot ang trapikong pabalik kung alin ang nalalapat.

Kahit mukhang gumagana ito, itinago ng disenyo ang tunay na tanong. Ang mga kliyente ay nakakarating sa pribadong address sa pamamagitan ng tunnel o sa publikong endpoint sa pamamagitan ng internet, at ang dalawang landas ay may magkaibang grupo ng seguridad, magkaibang pag-log at magkaibang paraan ng pagkasira.

Ang address ay hindi kailanman naging problema. Ang pagpili ng landas ang naging problema.

Tatlong layunin, tatlong disenyo

Kung ang layunin ay publikong endpoint ng VPN, ang Elastic IP ang tamang kasangkapan: kumokonekta ang malalayong kapares dito sa pamamagitan ng internet at nagtatapos ang naka-encrypt na transportasyon sa instance. Ginagamit pagkatapos ng panloob na trapiko ng aplikasyon ang pribadong address.

Kung ang layunin ay pribadong pag-access sa aplikasyon, ang destinasyon ay ang pribadong address o isang pribadong pangalan ng DNS na nagre-resolve dito, at ang ruta ng VPN, grupo ng seguridad at landas ng pagbabalik ay dapat magtugma lahat. Ang Elastic IP ay hindi lumilitaw sa disenyong iyon.

Kung ang layunin ay isang matatag na publikong pagkakakilanlan ng labasan para sa mga gumagamit ng VPN, iyon ay isang disenyong NAT sa panig ng labasan, hindi isang address sa tunnel ng kliyente. Tatlong layuning magkatulad ang tunog ay gumagawa ng tatlong magkaibang diagram, at isa lamang sa mga ito ang may kinalaman sa paglalagay ng Elastic IP sa isang bagong lugar.

I-verify ang landas na pinili mo

Para sa pribadong pag-access, tiyakin na ang ruta ng VPN ay sumasakop sa pribadong prefix, na ibinabalik ng talahanayan ng ruta ng VPC ang trapiko sa tunnel, na pinapayagan ng grupo ng seguridad ang pinagmulan ng kliyente at na pinapayagan ng sariling firewall ng kliyente ang tugon. Pagkatapos subukan ang isang tunay na kahilingan sa halip na ping.

Para sa publikong pag-access, tiyakin ang labasan ng kliyente sa internet, ang pagruruta ng publikong pasukan at ang patakaran sa seguridad nito. Kung maaaring maabot ng kliyente ng VPN ang publikong endpoint sa pamamagitan ng tunnel ay depende sa mga tuntunin ng labasan at firewall ng tunnel, hindi sa asosasyon ng Elastic IP.

Kung ang publikong pangalan ng host ay kailangang gumana mula sa magkabilang panig, gumamit ng disenyong DNS na sumasagot gamit ang pribadong address para sa mga kliyente ng VPN at ang publikong address para sa lahat ng iba, at panatilihing wasto ang sertipiko para sa pangalan at hindi sa address. Ayos ng trabaho: pangalanan ang layunin, piliin ang address na kabilang dito, pagkatapos i-verify ang mga ruta, patakaran at isang kahilingan.