Akses me ndërprerje në AWS Client VPN: audito çdo nënrrjet të lidhur
Disa sesione të AWS Client VPN arrijnë VPC-në e aplikacionit dhe të tjera skadojnë. Fillimisht krahasoni rrugët e pikës fundore me tabelën e rrugëve VPC të secilit asociacion.
Një përdorues lidhet, hap aplikacionin e brendshëm dhe merr përgjigje; një koleg në të njëjtën pikë fundore merr një skadim kohe nga një laptop identik në të njëjtin Wi-Fi. Ky model është firma e një pike fundore client VPN me më shumë se një nënrrjet të lidhur, ku shtigjet nuk janë ekuivalente. Unë e ndjek këtë nga konsola drejt jashtë, sepse dy skeda vendosin nëse pjesa tjetër e hetimit ia vlen. Asgjë në konfigurimin e klientit nuk e shpjegon atë.
Filloni nga pika fundore dhe listoni asociacionet
Në konsolën VPC, hapni Client VPN endpoints, zgjidhni pikën fundore dhe lexoni skedën Associations. Çdo asociacion është një nënrrjet në një zonë disponueshmërie, dhe klienti zbret në atë që zgjedh shërbimi kur ndërtohet lidhja. Shënoni ID-të e nënrrjeteve dhe tabelën e rrugëve që secili përdor në të vërtetë, sepse këto dy lista janë krahasimi që do të bëni.
Nëse pika fundore tregon vetëm një asociacion, kjo teori është e gabuar dhe klienti është i dyshuari më i mirë.
Krahasoni tabelën e rrugëve të pikës fundore me çdo asociacion
Hapni skedën Route table në të njëjtën pikë fundore. Çdo CIDR destinacioni atje ka një objektiv, dhe në një client VPN objektivi është një asociacion dhe jo një portë. AWS kërkon një zë destinacioni për çdo nënrrjet të lidhur, kështu që një rrugë që synon vetëm një prej tyre e bën aksesin të varur nga vendi ku zbriti sesioni. Kontrolloni destinacionin që ju intereson vërtet, pastaj rregullin e autorizimit të tij, sepse rruga ofron shtegun dhe rregulli vendos kush mund ta përdorë.
Pasi t’i tabeloni të dy shtresat, defekti është i vështirë për t’u anashkaluar.
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
Rreshti i dytë është i gjithë defekti në shumicën e tiketave. Rruga e pikës fundore është aty, kështu që askush nuk shikon më tej, dhe paketa vdes një hop më vonë brenda VPC-së.
Ndiqni çdo nënrrjet në tabelën e tij efektive të rrugëve
Një nënrrjet pa asociacion të shprehur me tabelën e rrugëve trashëgon tabelën kryesore të VPC-së. Lexoni tabelën që është në fuqi në të vërtetë, jo atë emri i së cilës duket i saktë, dhe krahasoni destinacionin dhe objektivin në vend të etiketës në rresht.
Udhëzuesi i AWS për aksesin me ndërprerje e përshkruan këtë si mbulim rrugësh nëpër asociacione, që është modeli i saktë. Pika fundore e çon paketën në një nënrrjet, dhe tabela e atij nënrrjeti ende duhet të dijë ku ndodhet rrjeti i aplikacionit.
Rregulloni rreshtin që mungon në tabelën që e zotëron. Kopjimi i një tabele të tërë rrugësh nga një nënrrjet që funksionon kopjon edhe zgjedhjet për internet, pajisje dhe izolim që nuk ishin menduar kurrë për këtë, dhe ky shkëmbim zakonisht është më i keq se ndërprerja me të cilën filluat.
Kontrolloni rregullat e autorizimit, pastaj rrugën e kthimit
Rregullat e autorizimit janë për destinacion dhe për grup, dhe vlerësohen ndaras nga rrugët. Një destinacion me rrugë kudo por pa rregull për grupin e përdoruesit sillet si një vrimë e zezë me një tabelë rrugësh që duket e shëndetshme.
Rruga e kthimit meriton të njëjtën vëmendje. Një lidhje peering kërkon një rrugë në VPC-në e aplikacionit që tregon përsëri drejt CIDR-it të klientit, rregulla të grupeve të sigurisë që lejojnë trafikun në të dy skajet, dhe ACL rrjeti që nuk e hedhin. Arritshmëria njëkahëshe, ku ping funksionon dhe shtrëngimi i duarve TCP nuk funksionon, zakonisht tregon një ACL ose një grup sigurie dhe jo VPN-në.
Grupet e sigurisë të vetë pikës fundore ndodhen në ndërfaqet elastike të rrjetit të asociacionit, kështu që një rregull që lejon portin e aplikacionit nga CIDR-i i klientit duhet të bashkëngjitet asociacionit, jo vetëm instancës.
Verifikoni me një rilidhje, jo me një kërkesë me fat
Me split tunnel, rrugët e pikës fundore dërgohen kur vendoset lidhja, kështu që një grup rrugësh i ndryshuar nuk arrin kurrë te një klient që mbetet i lidhur. Shkëputuni dhe rilidhuni përmes klientit të mbështetur, pastaj konfirmoni që rrugët e reja janë të pranishme në makinë.
Së fundi, lidhni regjistrin e lidhjeve me adresën që mori klienti, dhe përsëritni testin sa herë të mjaftojnë për të goditur më shumë se një asociacion. Një kërkesë e suksesshme pas një korrigjimi provon që një shteg funksionon, dhe tiketa kishte të bënte me tjetrin.