Panatilihin o SNAT ang mga IP ng kliyenteng VPN sa hangganan ng cloud

Ang pagpapanatili ng address ng kliyenteng VPN hanggang sa aplikasyon ay ginagawang pareho ang ibig sabihin ng bawat linya ng log at bawat entry sa listahan ng pinapayagan. Ang muling pagsulat nito sa gilid ng cloud ay ginagawang mas simple ang talahanayan ng ruta at mas hindi kapaki-pakinabang ang mga log. Wala sa dalawang pagpipilian ang mali sa sarili nito, at ang argumentong nagpapasya dito ay bihirang tungkol sa pagganap. Tatlong kundisyon ang nagpapasya: kung kailangan ng aplikasyon na malaman kung sinong tao ang kumonekta, kung tatanggapin ng tela ng cloud ang pinagmulang balak mong ipadala, at kung sino ang handang tumanggap ng responsibilidad sa pabalik na ruta pagkatapos.

Tatlong kundisyon ang nagpapasya

Magsimula sa pangangailangan ng aplikasyon, hindi sa diagram ng network. Kung ang awtorisasyon o audit ay nakasalalay sa indibidwal na address ng kliyente, ang pagpapanatili nito ay functional na pangangailangan at ang pagsasalin ay pag-urong. Kung kailangan lang malaman ng aplikasyon na dumating ang trapiko sa daan ng malayuang pag-access, sapat na ang isinaling address at mas mura itong patakbuhin.

Ang ikalawang kundisyon ay mekanikal. Ang isang virtual na network ay hindi awtomatikong nagtitiwala sa packet na nagsasabing address na hindi itinalaga sa nagpapadalang interface. Karamihan sa mga tela ng cloud ay nagpapatupad nito, sa iba't ibang paraan at pangalan, at ang disenyong bumabalewala dito ay magmumukhang tama sa diagram at tahimik na babagsak sa produksiyon.

Ang ikatlo ay organisasyonal. Ang pagpapanatili ng pinagmulan ay nangangahulugang ang talahanayan ng ruta ng subnet ng aplikasyon ay dapat tumuro pabalik sa gateway para sa prefix ng kliyente, at bawat koponang nagdadagdag ng subnet mamaya ay dapat panatilihing pare-pareho ang rutang iyon. Iyon ay maliit na gastos nang isang beses, at paulit-ulit na gastos sa dose-dosenang account. Magpasya kung sino ang magbabayad nito bago mo ipangako ang pag-uugali.

Ang ruta ay hindi pahintulot na manggaya

Ang pagdaragdag ng pabalik na ruta ay nagsasabi sa iyong subnet kung saan dapat pumunta ang mga sagot. Hindi nito sinasabi sa tela na ang instance na nagpapasa ng mga packet ay pinapayagang ilabas ang mga ito gamit ang banyagang pinagmulan. Sa AWS ang kaugnay na kontrol ay ang pagsusuri ng pinagmulan at destinasyon, at nakikita ito sa bawat instance:

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Patayin ito para lamang sa instance na ang dokumentadong trabaho ay pagpapasa, at wala nang iba. Bawat VM ng aplikasyon na nag-iiwan ng pagsusuring buhay ay isang makinang mas kaunti na maaaring gamitin upang maglabas ng trapiko gamit ang hiram na pinagmulan. Kung ang iyong plataporma ay hindi AWS, hanapin ang katumbas na setting ng anti-spoofing o pinapayagang address sa halip na ipagpalagay na susunod ang pag-uugali.

Ang mabilis na paghuli ng packet ay nagtatapos ng tanong nang mas mabilis kaysa sa pagbasa ng console. Kung lumalabas ang mga sagot at hindi ito nakikita ng kliyente, ang tela ang nagtatapon ng pekeng pinagmulan, at hindi ang aplikasyon ang nabigo.

Ano ang binibili ng pagsasalin, at ano ang halaga

Ang muling pagsulat ng pinagmulan sa gateway ay nag-aalis ng problema sa pabalik na landas. Nakikita ng aplikasyon ang isang address na alam na nito kung paano marating, at ang prefix ng kliyente ay hindi kailanman kailangang lumitaw sa talahanayan ng ruta ng cloud. Sa Linux ang tuntunin ay isang linya, at sulit na isulat ang pinakamakitid na bersiyon na kaya mo:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

Pansinin kung ano ang itinatala ng aplikasyon ngayon: 10.40.3.10 para sa bawat user, sa bawat koneksiyon, magpakailanman. Anumang listahan ng pinapayagang address na itinayo sa halagang iyon ay nagbibigay na ngayon ng access sa buong populasyon ng malayuang pag-access, at anumang pagsusuri ng insidente ay dapat bumalik sa gateway upang sagutin kung sino ito.

Ang solusyon ay hindi ang talikuran ang pagsasalin, ito ay ang itigil ang pagpapanggap na ang address ay pagkakakilanlan. Dalhin ang pagkakakilanlan ng kliyente sa isang na-authenticate na field, itala ito sa gateway kasama ng isinaling tuple, at hayaang sumali ang aplikasyon dito. Kung walang susi ng pagsasama, ginagawang permanenteng problemang forensik ng pagsasalin ang isang problema sa network.

Ang relay ay ibang interface

Ang reverse proxy sa harap ng aplikasyon ay lumalampas nang buo sa tanong ng naka-rutang landas. Binubuksan ng proxy ang sarili nitong koneksiyon sa backend, kaya ang prefix ng kliyente ay hindi kailanman kailangang maging naka-ruta sa loob ng virtual na network, at ang aplikasyon ay makakatanggap ng pagkakakilanlan sa header na itinatakda ng proxy.

Ang header na iyon ay mapagkakatiwalaan lamang kapag tinatanggap ito ng backend mula sa proxy at wala nang iba. Sa mga termino ng nginx nangangahulugan iyon ng hayagang pagpangalan sa pinagkakatiwalaang kapareha sa halip na maniwala sa anumang dumarating:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Anumang kliyenteng direktang makakaabot sa backend ay maaaring gumawa ng parehong header, kaya dapat na hindi maabot ang backend maliban sa pamamagitan ng proxy. Iyon ay katotohanan ng firewall, hindi opinyon sa konfigurasyon, at iyon ang palagay na nilalaktawan ng mga tao kapag kinokopya ang snippet.

Binabago rin ng relay ang binibili mo. Nakakakuha ka ng pagkakakilanlan sa antas ng aplikasyon at likas na lugar upang itala ito; isinusuko mo ang pagiging pangkalahatan, dahil bawat bagong protocol ay nangangailangan ng sarili nitong suporta sa proxy. Para sa mga serbisyong HTTP ang palitang iyon ay karaniwang mabuti, at para sa anumang hindi HTTP karaniwang wala itong makukuha.

Isulat kung ano ang nakikita ng bawat hangganan

Anuman ang piliin mo, ang pagsusuri ng disenyo ay dapat magtapos sa isang talahanayang nagpangalan sa address ng pinagmulan at ang mapapatunayan na pagkakakilanlan sa bawat pagtalon. Kung wala ito, ang unang insidente ay gumagawa ng tatlong koponang bawat isa ay naglalarawan ng ibang kliyente.

Pagkatapos pumili. Panatilihin ang pinagmulan kapag ang awtorisasyon ng aplikasyon ay talagang nakasalalay sa address ng kliyente at kaya mong pasanin ang ruta. Isalin kapag hindi at kaya mong dalhin ang pagkakakilanlan sa labas ng banda, at gamitin ang gabay ng AWS para sa mga instance ng pagpapasa para sa mga setting ng pagpapasang partikular sa plataporma. Dumulog sa relay kapag ang serbisyo ay nagsasalita ng HTTP at gusto mong tumigil ang pagkakakilanlan sa pagiging address.