AWS Client VPN na split tunnel: aling mga ruta ang dapat i-publish

Nag-aalok ang console ng toggle para sa split tunnel, kaya parang checkbox ang desisyon. Hindi. Ang talagang umaabot sa kliyente ay ang naka-publish na set ng ruta ng endpoint, at ang listahang iyon ang nagtatakda kung aling pribadong prefix ang gumagamit ng tunnel, kung nananatiling lokal ang pangkalahatang trapiko ng internet o lumalabas sa AWS, at kung aling resolver ang kaya pang kausapin ng kliyente. Tatlong tanong ang nagtatakda ng disenyo, at bawat isa ay maaaring sagutin nang mali habang nagtatagumpay pa rin ang koneksyon.

Ang flag ng split tunnel ay hindi listahan ng destinasyon

Inilalarawan ng AWS ang split tunneling bilang pagdaragdag ng mga ruta ng endpoint sa routing table ng kliyente kapag naitatag ang koneksyon. Ang ruta para sa pribadong VPC ay naglilimita sa tunnel sa destinasyong iyon; ang lahat ng iba ay sumusunod sa karaniwang landas ng kliyente. Ang default na ruta ay ibang tagubilin na may ibang epekto, kaya't ang dokumentasyon ng split tunnel ay nagbabala laban sa pag-publish ng 0.0.0.0/0 sa endpoint na naka-configure para sa mode na ito: kadalasan ito ay sumisira sa konektibidad sa halip na palawakin ito. Ang routing table ng endpoint ang patakaran, at ang routing table ng kliyente ang resulta na maaari mong siyasatin.

Basahin ang routing table ng endpoint at ang mga naka-install na ruta ng kliyente nang magkasama. Inilalarawan ng label ang layunin; inilalarawan ng mga ruta kung ano ang nangyayari.

Unang desisyon: dapat bang manatiling lokal ang pangkalahatang trapiko ng internet?

Kung ang pag-browse ay dapat gumamit ng sariling koneksyon ng user, i-publish lamang ang mga pribadong destinasyon na kailangan ng trabaho at huminto doon. Huwag magdagdag ng ruta ng internet dahil may isa sa tutorial ng buong tunnel, at huwag ipagpalagay na pinapabuti ng dagdag na ruta ang seguridad. Binabago nito ang landas, hindi nagdadagdag ng patakaran, at kadalasan ay nagkakahalaga ng latency na hindi mo binudget.

Kung ang trapiko ng internet ay dapat lumabas sa AWS, buuin ang dokumentadong arkitektura ng pag-access sa internet: ruta ng endpoint, mga tuntunin ng awtorisasyon, landas ng kaugnay na subnet, patakaran sa seguridad at gumaganang upstream egress. Ang default na ruta lamang ay hindi nagbibigay ng alinman sa mga iyon.

Ikalawang desisyon: aling pribadong prefix, awtorisado ng sino?

I-publish ang pinakamaliit na set ng destinasyon na naglilingkod sa tunay na workload, at tiyakin na ang bawat kaugnay na subnet ay makakapag-route patungo sa kanila. Ang target ng ruta ng endpoint at ang VPC routing ng subnet ay magkaibang antas, at ang rutang umiiral sa isa ay hindi patunay tungkol sa isa. Ang awtorisasyon ay hiwalay muli: ang isang destinasyon ay maaaring maabot at tanggihan pa rin dahil walang tuntunin ang grupo ng kliyente na pumapayag dito.

Ang pagsubok ng isang matagumpay na session ay nagpapatunay ng isang landas. Suriin ang bawat kaugnay na subnet, dahil ang subnet association na idinagdag mamaya ang eksaktong lugar kung saan kadalasang naroroon ang nawawalang ruta.

Kapag ang destinasyon ay dapat maabot sa pangalan, tandaan na ang susunod na tanong ay ang paglutas ng pangalan, hindi ang ruta.

Ikatlong desisyon: aling resolver ang sumusunod sa tunnel?

Ang kliyente ay maaaring makatanggap ng DNS server na maaabot lamang sa pamamagitan ng VPN, at gumagana lamang ang resolver na iyon kung ang address nito mismo ay nasa loob ng awtorisadong ruta. Tiyakin ang dalawang hati: ang address ng resolver ay sumusunod sa naka-publish na ruta, at sinasagot ng server ang mga pangalang hinihiling ng aplikasyon. Ang kahilingang nagtatagumpay sa address ngunit nabigo sa hostname ay tumutukoy sa pagpapangalan, hindi sa routing, at ang pag-debug ng tunnel sa kasong iyon ay nag-aaksaya ng hapon.

Dapat malutas ang mga pampublikong pangalan tulad ng bago ang koneksyon, na isa pang dahilan upang maging tumpak sa iyong ipinapublish.

Baguhin ang set ng ruta, pagkatapos ay tiyakin ang dalawang mundo

Itinatala ng AWS na ang pagbabago ng mga ruta sa split tunnel endpoint ay nagre-reset ng mga koneksyon ng kliyente. Planuhin ang pagbabago na isinasaalang-alang iyon: ilapat ito, muling kumonekta sa sinusuportahang kliyente, at basahin muli ang mga naka-install na ruta sa halip na magtiwala sa estadong inilapat bago ang pag-edit. Ang lumang inilapat na estado ang pinakakaraniwang dahilan kung bakit ang tamang pagbabago ay mukhang sira.

Tanggapin ang disenyo lamang kapag ang isang pribadong mapagkukunan at isang pampublikong destinasyon ay kumikilos ayon sa layunin, sa pangalan at sa address, sa mga pamilya ng address na talagang sinusuportahan mo. Ang tunnel na nagpapatunay ng pagkakakilanlan ay hindi katulad ng tunnel na wastong naghahati.

Isulat ang listahan ng ruta sa runbook sa tabi ng pangangatwiran, upang ang susunod na tao ay makilala ang sinadyang pagbubukod sa nalimutan.