AWS Client VPN është i lidhur, por EC2 prapë nuk përgjigjet

Laptopi im dha të lidhur. Klienti AWS Client VPN tregonte gjendjen e tij të gjelbër, endpoint-i regjistroi një sesion, dhe prapë nuk mund të hapja një port MongoDB në një instancë EC2 në një nënrrjet privat. Asgjë nuk ishte haptazi e prishur: certifikata ishte e vlefshme, profili erdhi nga konsola dhe tuneli mbante trafikun. Gabimi ishte imi, sepse e lexoja të lidhur si të autorizuar.

Hyrja përgjigjet saktësisht një pyetjeje: a mundet ky identitet të krijojë një sesion? Gjithçka pas kësaj vendoset nga rregulla të veçanta që nuk e shohin kurrë certifikatën tënde. Një sesion që autentikohet dhe një paketë që mbërrin janë dy suksese të ndryshme, dhe hendeku mes tyre është vendi ku jetojnë shumica e raportimeve të tipit VPN-ja është lart, por hosti nuk arrihet.

Kontrollet më poshtë janë radha që përdor tani.

Çfarë provon vërtet një sesion i lidhur

Gjatë handshake-ut endpoint-i vërteton certifikatën e klientit kundrejt trust store-it të vet, ose e ridrejton shfletuesin te ofruesi i identitetit kur SAML është konfiguruar. Nëse kjo kalon, klienti merr një adresë nga CIDR-i i klientit të endpoint-it dhe konsola tregon një lidhje aktive. Në asnjë moment të asaj shkëmbimi nuk pyetet nëse mund të arrish 10.0.4.17 në portën 27017.

Leja për një destinacion është një objekt i veçantë në endpoint. Çdo rrjedhë krahasohet me rregullat e autorizimit, dhe secila prej tyre çiftëzon një CIDR destinacioni me grupin të cilit i jepet rregulli. Kur asnjë rregull nuk e mbulon destinacionin, endpoint-i e pranon sesionin dhe e hedh trafikun. Nuk ka baner, nuk ka cikël rilidhjeje dhe asgjë në ndërfaqen e klientit që thotë refuzuar.

Krahaso rregullin e autorizimit me burimin, jo me VPC-në

Listo rregullat dhe vendosi pranë adresës që instanca ka vërtet:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Dalja tregon një CIDR destinacioni dhe një ID grupi për çdo rregull. Në të fshihen dy dështime. Rregulli mund të autorizojë 10.0.0.0/16 ndërsa instanca ndodhet në një VPC të peer-uar në 10.1.0.0/16; rruga e peering-ut ekziston, por askush nuk shkroi një rregull autorizimi për diapazonin e dytë. Ose rregulli tregon një grup drejtorie ku përdoruesi është anëtar në drejtori, por jo në grupin që vlerëson endpoint-i.

Shkruaj rregullin më të ngushtë që mbulon destinacionin, dhe shto një të dytë vetëm kur një CIDR i dytë është vërtet i nevojshëm. Një rregull i gjerë 0.0.0.0/0 nga një nisje e shpejtë funksionon, dhe pikërisht për këtë mbijeton deri në prodhim dhe e fsheh modelin.

Dy tabela rrugësh vendosin nëse paketa lëviz

Një rrugë endpoint-i e harton një CIDR destinacioni në një nga nënrrjetet me të cilat endpoint-i është i lidhur. Kjo është gjysma e rrugës. Tabela e rrugëve e vetë nënrrjetit duhet të dijë ende si ta përcjellë paketën, dhe kjo ka rëndësi në momentin kur destinacioni ndodhet pas një lidhjeje peering, një transit gateway ose një diapazoni lokal të arritshëm përmes një tuneli site-to-site.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Kërko një rrugë, destinacioni i së cilës përputhet me CIDR-in e burimit dhe objektivi i së cilës është një nënrrjet i lidhur. Nëse rruga mungon, shtoje. Nëse ekziston dhe hosti vazhdon të heshtë, hendeku është në anën e VPC-së, ndaj krahasoje me tabelën e rrugëve të nënrrjetit të asociimit.

Një rregullim në anën e klientit e prish rrugëtimin pa e prishur tunelin: një profil që përmban route-nopull. Direktiva i thotë një klienti të bazuar në OpenVPN t'i injorojë rrugët që shtyn serveri, kështu që ndërfaqja ngrihet vetëm me adresën e vetë endpoint-it dhe destinacioni thjesht nuk ka rrugë. Kontrollo me ip route show në Linux ose netstat -rn në macOS nëse ekziston një rrugë përmes ndërfaqes tun. Nëse nuk ekziston, hiqe route-nopull nga profili i eksportuar dhe rilidhu që rrugët e shtyra të zbatohen.

Grupet e sigurisë nuk e shohin adresën e klientit tënd

Kjo është pjesa që e kisha gabim gjysmë dite. Për një endpoint IPv4 të lidhur me një nënrrjet, shërbimi e përkthen adresën burimore të klientit në adresën e ndërfaqes së rrjetit të endpoint-it në atë nënrrjet. Paketa që mbërrin në instancë nuk e mbart adresën që shfaqte klienti yt, ndaj një rregull i grupit të sigurisë që lejon grupin e klientëve, të themi 172.16.0.0/22, nuk përputhet me asgjë.

Lejo portën nga grupi i sigurisë i endpoint-it, i cili është i bashkangjitur në ndërfaqen e asociimit, jo nga CIDR-i i klientit. Referimi i grupit është më i qëndrueshëm sesa kodimi i fortë i një adrese, sepse adresa e ndërfaqes nuk është e jotja për ta kontrolluar. ACL-të e rrjetit janë pa gjendje, ndaj aty ku ka zëra të personalizuar, të dy drejtimet, hyrëse dhe dalëse, duhet ta lejojnë rrjedhën.

Lidhu edhe me adresën private të instancës. Një IP publike e nxjerr paketën nga VPC-ja dhe e kthen brenda nëpër një rrugë tjetër me rregulla të tjera, ndaj një provë nga adresa publike nuk thotë asgjë për rrugën private.

Një radhë izolimi që ndalon në dështimin e parë

Kalo këto me radhë dhe ndalo aty ku njëri dështon. Çdo hap përjashton një shtresë, jo të gjitha.

1. Konfirmo cilin identitet përdori sesioni dhe cilin grup vlerëson endpoint-i. Një certifikatë nga një trust store nuk është i njëjti principal si një pohim SAML nga drejtoria.
2. Konfirmo që një rregull autorizimi e mbulon CIDR-in e burimit për atë grup.
3. Konfirmo që ekziston një rrugë endpoint-i dhe synon një nënrrjet të lidhur, pastaj që tabela e rrugëve e nënrrjetit mund të përçojë më tej.
4. Konfirmo që grupi i sigurisë e lejon portën nga ndërfaqja e endpoint-it dhe jo nga grupi i klientëve.
5. Testo nga brenda VPC-së, me një sesion SSM në një instancë tjetër në të njëjtin nënrrjet, për të ndarë një problem aplikacioni nga një problem i rrugës së klientit.

Kur hapat nuk janë vendimtarë, kjo tabelë është ajo ku mbështetem:

Dy hollësi të llogarisë prodhojnë simptoma që duken si dështime lejeje. Çdo përdorues ka nevojë për një certifikatë klienti të veçantë; ndarja e njërës mes dy makinave i bën sesionet të shtyjnë njëri-tjetrin, dhe rezultati është një cikël rilidhjeje, jo një refuzim. Kur krijohet një endpoint i ri, konsola shfaq një emër DNS që disa versione të klientit e pranojnë vetëm me prefiksin e rastësishëm të shfaqur në faqen e endpoint-it, ndaj kopjo emrin e plotë në vend që ta rindërtosh.

Nëse hapi i pestë të bllokon, nxirr login e lidhjeve të endpoint-it dhe lexo zërat e autorizimit përpara se të ndryshosh gjë. Logu emërton destinacionin e kontrolluar dhe rregullin që përputhej ose jo, dhe kjo e zvogëlon pyetjen me katër shtresa në një përgjigje të vetme.