Bakit nabibigo ang GRE at ESP sa isang AWS NAT gateway

Nabibigo ang tunnel, pinapayagan na ng security group ang lahat ng trapiko, at ang konklusyon ay hinaharangan ng AWS ang VPN. Wala itong hinaharangan. Ang pinamamahalaang NAT gateway ay nagpapasa ng dokumentadong hanay ng mga panlabas na protocol, at ang native GRE o native ESP ay wala roon, kaya walang panuntunang idagdag mo ang magpipilit sa gateway na dalhin ang mga iyon. Ang panuntunan ng pahintulot at ang kakayahan sa paghahatid ay dalawang magkaibang bagay, at isa lamang sa kanila ang maaari mong baguhin.

Ang hanay ng panuntunan ay hindi ang hanay ng protocol

Ang security group ang nagpapasya kung aling trapiko ang pinapayagang umalis sa instance. Ang NAT gateway ang nagpapasya kung ano ang kaya nitong isalin at ipasa. Kapag umiiral ang pangalawang limitasyon, ang mapagpahintulot na panuntunan ay gumagawa ng eksaktong sintomas na mali ang pagbasa ng mga tao bilang problema sa firewall: umaalis ang mga packet sa instance, maaaring matapos pa ang palitan ng kontrol, at walang dumarating sa kapares.

Ang espesipikasyon ng protocol ng NAT gateway ng AWS ay naglilista ng TCP, UDP at ICMP para sa pinamamahalaang serbisyo. Iyon ang buong sinusuportahang hanay. Ang panuntunan ng pahintulot para sa ibang protocol ng IP ay hindi makapagpapalawak nito, dahil sinusuri ang panuntunan nang matagal bago maabot ang landas ng pagpapasa ng gateway.

Mahalaga ang pagkakaiba dahil magkapareho ang hitsura ng dalawang kabiguan mula sa kliyente at ganap na magkaiba ang mga pagwawasto.

Ipinapakita ng PPTP kung bakit nagsisinungaling ang pagsubok sa port

Ang PPTP ang pinakamalinaw na lumang halimbawa ng pagsusuri sa port na walang pinatutunayan. Nagbubukas ito ng kontrol na koneksyon sa TCP sa port 1723 at pagkatapos ay dinadala ang data ng tunnel sa GRE, na protocol ng IP 47. Ang protocol 47 ay hindi port ng TCP 47, at ang dalawang numerong ito ay walang kaugnayan sa isa't isa maliban sa pagbabahagi ng mga digit.

Ang operator na sumusubok ng konektibidad sa 1723 at nakakita ng natapos na handshake ay naghihinuha na gumagana ang landas. Pagkatapos ay hindi kailanman nakapasa ang channel ng data ng kahit isang packet, dahil walang suporta sa GRE na maiaalok ang gateway. Ito ay isang interpretasyon ng mga pangangailangan ng lumang protocol, hindi payo na mag-deploy ng PPTP, na matagal nang lipas.

Ang parehong pangangatwiran ay nalalapat sa anumang protocol na ang channel ng kontrol ay TCP o UDP samantalang ang landas ng data nito ay hindi.

Ang IPsec ay nabubuhay lamang bilang UDP

Ang IPsec ay ang kaso kung saan ang sagot ay may kondisyon sa halip na isang tuwirang hindi. Idinodokumento ng AWS ang NAT traversal bilang ang sinusuportahang kaayusan para sa IPsec sa pamamagitan ng NAT gateway. Kapag napagkasunduan ang NAT-T, ang ESP ay naka-encapsulate sa loob ng UDP at ang gateway ay nakakakita ng ordinaryong UDP sa halip na protocol 50.

Ang pagpayag sa UDP 4500 ay hindi nagpapagamit ng NAT traversal sa mga endpoint. Pinapayagan lamang nito ang mga packet kung ganito na ang hugis ng mga ito. Kumpirmahin mula sa output ng negosasyon ng kliyente mismo kung aling encapsulation ang pinili, at kumpirmahin sa panig na tumatanggap na tinanggap ito ng kapares. Ang dalawang endpoint na naka-configure para sa native ESP ay patuloy na magpapadala ng native ESP, anuman ang sabihin ng hanay ng panuntunan.

Ang VPN na nakabatay sa TCP o UDP ay umaangkop sa dokumentadong hanay ng paghahatid at maaari pa ring mabigo dahil sa ruta, pagsasala o pagpapatunay. Ang umangkop sa hanay ay kailangan, hindi sapat.

Suriin ang landas bago palawakin ang patakaran

I-verify ang aktwal na ruta ng subnet ng workload at ang pagkakakilanlan ng susunod na hop nito muna. Ang direktang pampublikong landas, instance ng NAT, pinamamahalaang NAT gateway at pribadong landas sa pamamagitan ng transit gateway ay apat na magkaibang disenyo, at isa lamang sa kanila ang pinamamahalaang serbisyong inilarawan dito.

Pagkatapos ay itala ang sinubukang endpoint, ang pamilya ng address, ang panlabas na protocol at ang port kung mayroon ang protocol. Gamitin ang diagnostiko ng kliyente at ang mga obserbasyon sa daloy ng may-ari ng network sa halip na isang matagumpay na kahilingan ng browser, na nagpapatunay lamang na gumagana ang TCP at UDP. Pagkatapos nito, repasuhin ang security group, ang ACL ng subnet, ang firewall ng bisita at ang patakaran ng serbisyo para sa parehong direksyon ng daloy.

Huwag buksan ang lahat ng trapiko para mabayaran ang paghahatid na hindi kayang dalhin ng serbisyo. Hindi ito maaayos ng pagbabago ng panuntunan, at mabubuhay ito pagkatapos ng insidente.

Kapag hindi umaangkop ang paghahatid

Kung ang panlabas na protocol ay labas ng sinusuportahang hanay, ang pagwawasto ay arkitektural: pumili ng paghahatid na kayang dalhin ng landas, o ilipat ang labasan sa isang bagay na nagdadala ng kailangan mo. OpenVPN sa UDP, WireGuard sa UDP at mga tunnel na nakabatay sa TLS ay umaangkop lahat sa dokumentadong hanay. Ang instance ng NAT na pinamamahalaan ng kostumer ay ang opsyon kapag kailangang dumaan ang isang partikular na protocol at ang gastos sa pagpapatakbo nito ay katanggap-tanggap.

Ang pagho-host ng papasok na VPN server ay hiwalay na problema na may hiwalay na sagot. Ang NAT gateway ay nagbibigay ng palabas na pagsasalin at walang pangkalahatang pagpapasa ng papasok na port, kaya ang server sa likod nito ay nangangailangan ng aprubadong pampublikong pasukan na dinisenyo sa sariling mga tuntunin.

Pagkakasunod-sunod ng trabaho: pangalanan ang panlabas na protocol, kumpirmahin ang susunod na hop, ihambing ito sa dokumentadong hanay, pagkatapos ay baguhin ang arkitektura o paghahatid. Hindi magagawang TCP ng ibang numero ng port ang GRE, at hindi magagawang gumaganang channel ng data ng isa pang mapagpahintulot na panuntunan ang natapos na palitan ng kontrol.