AWS Client VPN o bastion para maabot ang isang VPC na may peering

Ang isang endpoint ng Client VPN ay makakaabot sa isang VPC na may peering sa kaugnay nitong VPC, at hindi mo kailangan ng bastion para gawing lehitimo iyon. Ang pagpipiliang sulit gawin ay kung saan nagpapalit ng kamay ang trapiko: isang rutang endpoint na dumarating sa subnet ng asosasyon at tumatawid sa koneksyon ng peering, o isang host sa VPC na may peering na nagtatapos ng sesyon. Gumagana ang dalawang landas at nabibigo sila sa magkaibang lugar, kaya ang desisyon ay tungkol sa pagmamay-ari at audit, hindi sa kung ano ang pinapayagan ng AWS. Narito kung paano ako pumipili sa pagitan nila, at ang apat na entry na nagpapagana sa rutang landas.

Dalawang landas, isang endpoint, magkaibang may-ari

Sa rutang landas, umaabot ang trapiko ng kliyente sa endpoint, isinasalin sa address ng interface ng network ng Client VPN sa subnet ng asosasyon, at lumalabas sa subnet na iyon sa koneksyon ng peering mula A patungong B. Hindi tinatapos ng VPC B ang anumang sesyon ng VPN; nakikita nito ang ordinaryong trapiko mula sa VPC A, kaya ang rutang pabalik nito ay tumuturo sa VPC A, hindi sa pool ng kliyente.

Sa landas ng bastion, naaabot muna ng kliyente ang isang host. Ang bastion sa A ay hinahayaan pa rin ang huling pagtalon na tumawid sa koneksyon ng peering, kaya pinapanatili mo ang trabaho ng peering at nagdaragdag ng sesyon. Ang bastion sa B ay nangangailangan din ng landas mula sa kliyente, at kapag ang landas na iyon ay ang parehong rutang endpoint, mayroon ka ng rutang disenyo dagdag ng isang pagtalon. Tinatanggal lamang ng bastion ang trabaho kapag mayroon na ito, aprubado na, at ang bagay sa likod nito ay nangangailangan ng hangganan ng sesyon hindi hangganan ng network.

Apat na entry ang nagpapagana sa rutang landas

Idinodokumento ng AWS ang senaryong ito sa pahina ng Client VPN how-it-works, at sa praktika bumaba ito sa apat na entry na pagmamay-ari ng dalawa o tatlong team. Ang mga saklaw ay halimbawa; ang saklaw na may peering ay dapat natatangi at ang saklaw ng pagbabalik ay dapat tumugma sa iyong plano.

Ang ruta at pahintulot ay magkahiwalay na kontrol. Ang tamang rutang endpoint na walang tugmang tuntunin ng awtorisasyon ay walang ibinibigay sa kliyente; ang tuntunin ng awtorisasyon para sa destinasyong hindi kayang iruta ng endpoint ay nagbibigay dito ng itim na butas. Dapat pareho nilang banggitin ang parehong saklaw.

Ang rutang endpoint ay tumuturo sa subnet sa sariling VPC ng endpoint, hindi kailanman sa koneksyon ng peering. Ang mga talahanayan ng ruta ng VPC ay tumuturo sa koneksyon ng peering, hindi kailanman sa instance o interface. Ang pagkopya ng halaga sa pagitan ng dalawa ay nai-save nang walang reklamo at walang niruruta.

Dahil isinasalin ng subnet ng asosasyon ang pinagmulan ng kliyente, dapat iruta ng B pabalik sa VPC A, hindi sa pool ng kliyente. Ang pagpapadala ng saklaw ng kliyente sa koneksyon ng peering ay mukhang simetriko, pumapasa sa pagsusuri, at tahimik na nabibigo dahil hindi kailanman nakikita ng B ang packet na may pinagmulang kliyente.

Mga security group at ang huling metro ng pahintulot

Dinadala ng pag-ruta ang mga packet sa B; nagpapasya pa rin ang B. Para sa aktibong koneksyon ng peering sa parehong rehiyon, ang security group sa B ay maaaring sumangguni sa group na inilapat sa asosasyon ng Client VPN, na nagpapanatili ng tuntunin na makitid at nakakaligtas sa mga pagbabago ng address. Kung saan hindi posible ang sanggunian ng group, hayagang payagan ang saklaw ng subnet ng asosasyon sa halip na palawakin sa 0.0.0.0/0, na ginagawang hindi maipaliwanag na timeout ang isang pagkakamali sa pag-ruta.

Pagkatapos ay suriin ang hindi kailanman hinahawakan ng pag-ruta: ang mga ACL ng network sa dalawang subnet, ang allow-list o audience ng token ng aplikasyon, at DNS. Hindi kinokopya ng peering ang mga pribadong host na zone, kaya ang laptop ay maaaring may gumaganang ruta patungo sa address na hindi nito maresolba, at ang koneksyon ng peering ay walang idinadagdag na tiwala sa certificate. Ituro ang endpoint sa resolver na sumasagot para sa B, pagkatapos ay kumpirmahin na tugma ang pribadong pangalan at certificate.

Kung kailan ang bastion ang tapat na sagot

Nagtatago ako ng tatlong trigger para sa sadyang pagpili ng bastion. Ang VPC na may peering ay pag-aari ng team na hindi magdadagdag ng rutang pabalik para sa iyong saklaw o hindi tatanggap ng sanggunian ng group. Ang pag-access ay dapat aprubado o naitala bawat sesyon at hindi kayang dalhin iyon ng aplikasyon nang mag-isa. O ang huling pagtalon ay dapat manatili sa loob ng B dahil doon lamang nare-resolba ang serbisyo at ang identidad ng TLS nito ay naka-pin sa isang panloob na pangalan.

Wala sa mga ito ang pag-iwas sa katotohanang hindi transitive ang peering. Nililimitahan ng hindi pagiging transitive ang maaaring gawin ng mga resource sa B: hindi nila magagamit ang A bilang transit patungo sa ikatlong VPC na may peering ang A. Hindi kailanman nangangahulugan iyon na hindi maaabot ng user ng VPN ang direktang peering na VPC, at ang bastion na itinayo para iwasan ang maling pagbasa ay host na pina-patch nang walang dahilan.

Ang kabaligtarang pagkakamali ay mas mahal sa paglipas ng panahon: ipadala ang bawat team sa nag-iisang bastion na mayroon na, pagkatapos ay tuklasin na ang security group, talahanayan ng ruta at window ng patch nito ang dependency sa produksyon. Isulat kung aling trigger ang pinaglilingkuran ng host, at alisin ito sa serbisyo kapag nawala ang trigger.

Binabago ng Transit Gateway at maraming asosasyon ang aritmetika

Kung ang endpoint ay direktang nakakabit sa Transit Gateway sa halip na sa subnet, nagbabago ang modelo: hindi na isinasalin ang mga kliyente sa address ng interface sa subnet ng asosasyon, at dapat dalhin ng mga talahanayan ng ruta ng gateway ang saklaw ng kliyente at ang attachment na patungo sa VPC na may peering. Mas malinis iyon sa sukat, pero lumilipat ang trabaho mula sa apat na entry patungo sa mga talahanayan ng ruta ng gateway.

Pinaparami ng maraming asosasyon ang mga pagsusuri. Ang rutang endpoint ay pag-aari ng endpoint, gayunpaman ang bawat subnet ng asosasyon ay nangangailangan ng talahanayan ng ruta na may tunay na susunod na pagtalon ng peering. Ang isang sesyon ay maaaring magtagumpay sa isang asosasyon habang ang isa ay walang rutang pabalik, kaya subukan ang bawat isa.

Pagkakasunod-sunod ng beripikasyon na mabilis makahanap ng sira

Patakbuhin ang mga ito nang sunod-sunod; ang bawat hakbang ay maaaring pumasa habang nabibigo ang susunod, at ang timeout ng kliyente ay halos hindi kailanman nagsasabi kung alin ang nasira.

1. I-resolba ang pangalan ng aplikasyon mula sa kliyente at suriin na ang address ay nasa loob ng saklaw ng peering.
2. Kumonekta, pagkatapos ay basahin ang log ng mga koneksyon ng endpoint para sa asosasyong nagtapos ng sesyon.
3. Sa subnet ng asosasyong iyon, kumpirmahin na itinuturo ng talahanayan ng ruta ang saklaw ng peering sa aktibong koneksyon ng peering.
4. Sa subnet ng resource sa B, kumpirmahin ang entry ng pagbabalik para sa saklaw ng interface at tugmang mga tuntunin ng group.
5. Subukan ang isang pinapayagang operasyon at isang resource na dapat manatiling hindi maabot; nahuhuli ng pangalawa ang mga labi ng debugging.
6. Kumonekta muli pagkatapos ng anumang pagbabago ng rutang split-tunnel, dahil ang tumatakbong tunnel ay hindi kukuha ng bagong set ng ruta.

Dalawang sintomas ang sulit tandaan. Ang SYN na umaabot sa B nang walang sagot ay halos palaging ang nawawalang rutang pabalik. Ang koneksyong natapos at pagkatapos ay na-reset ay karaniwang ang group, ACL o aplikasyon. Wala sa kanila ang lumilitaw sa log ng endpoint bilang sanhi, kaya itago ang apat na entry na may may-ari sa tabi ng bawat isa.

Kung wala sa tatlong trigger ang naaangkop, tapusin ang rutang landas at itala ang apat na entry. Kung may isang naaangkop, itago ang bastion para lamang sa hangganang iyon at iwanan ang rutang endpoint para sa mga serbisyong hindi nangangailangan ng sesyon sa harap nila.