AWS Client VPN apo bastion për të arritur një VPC me peering
Të dyja rrugët funksionojnë, por thyhen në vende të ndryshme. Krahasoni rrugët e endpoint-it, routing-un e kthimit dhe tre rastet kur bastion është kufiri i ndershëm.
Një endpoint Client VPN mund të arrijë një VPC që është në peering me VPC-në e tij të lidhur, dhe nuk ju nevojitet një bastion për ta bërë atë legjitim. Zgjedhja që ia vlen të bëhet është ku trafiku ndryshon duar: një rrugë endpoint që zbret në nënrrjetin e asociimit dhe kalon lidhjen e peering-ut, ose një host në VPC-në me peering që përfundon sesionin. Të dyja rrugët funksionojnë dhe dështojnë në vende të ndryshme, pra vendimi është për pronësinë dhe audimin, jo për atë që lejon AWS. Ja si zgjedh midis tyre, dhe katër hyrjet që e bëjnë rrugën e rrugëtuar funksionale.
Dy rrugë, një endpoint, pronarë të ndryshëm
Në rrugën e rrugëtuar trafiku i klientit arrin endpoint-in, përkthehet në adresën e ndërfaqes së rrjetit Client VPN në nënrrjetin e asociimit dhe largohet nga ai nënrrjet përmes lidhjes peering nga A në B. VPC B nuk përfundon asnjë sesion VPN; sheh trafik të zakonshëm nga VPC A, prandaj rruga e tij e kthimit tregon VPC A, jo grupin e klientëve.
Në rrugën e bastionit klienti arrin së pari një host. Një bastion në A lë akoma hop-in e fundit të kalojë lidhjen peering, kështu që e mbani punën e peering-ut dhe shtoni një sesion. Një bastion në B gjithashtu ka nevojë për një rrugë nga klienti, dhe kur ajo rrugë është e njëjta rrugë endpoint, keni dizajnin e rrugëtuar plus një hop. Bastioni heq punë vetëm kur ekziston tashmë, është miratuar tashmë, dhe gjëja pas tij ka nevojë për një kufi sesioni e jo për një kufi rrjeti.
Katër hyrje e bëjnë rrugën e rrugëtuar funksionale
AWS e dokumenton këtë skenar në faqen Client VPN how-it-works, dhe në praktikë zbret në katër hyrje që zotërohen nga dy ose tre ekipe. Gammat janë ilustruese; gama me peering duhet të jetë unike dhe gama e kthimit duhet të përputhet me planin tuaj.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
Rruga dhe leja janë kontrolle të ndara. Një rrugë endpoint e saktë pa rregullin përkatës të autorizimit nuk i jep asgjë klientit; një rregull autorizimi për një destinacion që endpoint-i nuk mund ta rrugëtojë i jep një vrimë të zezë. Të dyja duhet të përmendin të njëjtën gamë.
Rruga e endpoint-it tregon një nënrrjet në VPC-në e vetë endpoint-it, kurrë lidhjen peering. Tabelat e rrugëve të VPC-së tregojnë lidhjen peering, kurrë një instancë ose ndërfaqe. Kopjimi i një vlere midis të dyjave ruhet pa ankesë dhe nuk rrugëton asgjë.
Meqenëse nënrrjeti i asociimit përkthen burimin e klientit, B duhet të rrugëtojë përsëri në VPC A, jo në grupin e klientëve. Dërgimi i gamës së klientëve përmes lidhjes peering duket simetrik, kalon rishikimin dhe dështon në heshtje sepse B nuk sheh kurrë një paketë me burim klienti.
Grupet e sigurisë dhe metri i fundit i lejes
Rrugëtimi i sjell paketat në B; B vendos akoma. Për një lidhje peering aktive në të njëjtin rajon, një grup sigurie në B mund t'i referohet grupit të aplikuar në asociimin e Client VPN, gjë që e mban rregullin të ngushtë dhe i reziston ndryshimeve të adresave. Aty ku një referencë grupi nuk është e realizueshme, lejo në mënyrë eksplicite gamën e nënrrjetit të asociimit në vend që ta zgjerosh në 0.0.0.0/0, që e kthen një gabim rrugëtimi në një timeout të pashpjeguar.
Pastaj kontrollo atë që rrugëtimi nuk e prek kurrë: ACL-të e rrjetit në të dy nënrrjetet, lista e lejuar ose audienca e token-it të aplikacionit, dhe DNS. Peering nuk kopjon zona private të hostuara, kështu që laptop-i mund të mbajë një rrugë funksionale drejt një adrese që nuk mund ta zgjidhë, dhe një lidhje peering nuk i shton besim një certifikate. Drejto endpoint-in në një resolver që përgjigjet për B, pastaj konfirmo që emri privat dhe certifikata përputhen.
Kur bastioni është përgjigjja e ndershme
Mbaj tre nxitës për të zgjedhur me qëllim një bastion. VPC-ja me peering i përket një ekipe që nuk do të shtojë një rrugë kthimi për gamën tuaj ose nuk do të pranojë një referencë grupi. Aksesi duhet të miratohet ose regjistrohet për çdo sesion dhe aplikacioni nuk mund ta mbajë vetë. Ose hop-i i fundit duhet të mbetet brenda B sepse shërbimi zgjidhet vetëm atje dhe identiteti i tij TLS është i fiksuar në një emër të brendshëm.
Asgjë nga këto nuk është një anashkalim i faktit që peering nuk është transitiv. Jo-transitiviteti kufizon çfarë mund të bëjnë burimet në B: ato nuk mund të përdorin A si transit drejt një VPC të tretë me të cilin A është në peering. Kjo nuk ka nënkuptuar kurrë që një përdorues VPN nuk mund të arrijë drejtpërdrejt një VPC me peering, dhe një bastion i ndërtuar për të anashkaluar atë lexim të gabuar është një host që bëhet patch pa arsye.
Gabimi i kundërt kushton më shumë me kalimin e kohës: kaloni çdo ekip nga bastioni i vetëm që ekziston tashmë, pastaj zbuloni se grupi i tij i sigurisë, tabela e rrugëve dhe dritarja e patch-it janë varësia e prodhimit. Shënoni cilës nxitës i shërben host-i, dhe tërhiqeni kur nxitësi largohet.
Transit Gateway dhe disa asociime ndryshojnë aritmetikën
Nëse endpoint-i është i lidhur drejtpërdrejt me një Transit Gateway e jo me një nënrrjet, modeli ndryshon: klientët nuk përkthehen më në një adresë ndërfaqeje në një nënrrjet asociimi, dhe tabelat e rrugëve të portës duhet të mbajnë gamën e klientëve plus lidhjen që çon në VPC-në me peering. Kjo është më e pastër në shkallë, por puna transferohet nga katër hyrje në tabelat e rrugëve të portës.
Disa asociime i shumëfishojnë kontrollet. Rruga e endpoint-it i përket endpoint-it, megjithatë çdo nënrrjet asociimi ka nevojë për një tabelë rrugësh me një hop tjetër peering të vërtetë. Një sesion mund të ketë sukses përmes një asociimi ndërsa një tjetër nuk ka rrugë kthimi, prandaj testoni secilin.
Rendi i verifikimit që e gjen shpejt thyerjen
Ekzekutoni këto me radhë; çdo hap mund të kalojë ndërsa hapi tjetër dështon, dhe një timeout klienti pothuajse kurrë nuk thotë cili u thye.
- Zgjidhni emrin e aplikacionit nga klienti dhe kontrolloni që adresa është brenda gamës me peering.
- Lidhuni, pastaj lexoni regjistrin e lidhjeve të endpoint-it për asociimin që përfundoi sesionin.
- Në atë nënrrjet asociimi, konfirmoni që tabela e rrugëve e drejton gamën me peering drejt një lidhjeje peering aktive.
- Në nënrrjetin e burimeve në B, konfirmoni një hyrje kthimi për gamën e ndërfaqes dhe rregulla grupi që përputhen.
- Testoni një operacion të lejuar dhe një burim që duhet të mbetet i paarritshëm; i dyti kap mbetjet e korrigjimit.
- Rilidhuni pas çdo ndryshimi të rrugës split-tunnel, sepse një tunel në punë nuk do të marrë një grup të ri rrugësh.
Dy simptoma ia vlen të mbahen mend. Një SYN që arrin B pa përgjigje është pothuajse gjithmonë rruga e kthimit që mungon. Një lidhje që përfundon dhe pastaj riniset është zakonisht grupi, ACL-ja ose aplikacioni. Asnjëra nuk shfaqet në regjistrin e endpoint-it si shkak, prandaj mbaj katër hyrjet me një pronar pranë secilës.
Nëse asnjë nga tre nxitësit nuk zbatohet, përfundoni rrugën e rrugëtuar dhe regjistroni ato katër hyrje. Nëse një zbatohet, mbaj bastionin vetëm për atë kufi dhe lëre rrugën e endpoint-it për shërbimet që nuk kanë nevojë për një sesion përpara.