Szaggatott hozzáférés AWS Client VPN-nel: ellenőrizze az összes kapcsolt alhálózatot

Egy felhasználó csatlakozik, megnyitja a belső alkalmazást és választ kap; egy kolléga ugyanazon a végponton időtúllépést kap egy azonos laptopról, ugyanazon a Wi-Fi-n. Ez a minta egy client VPN végpont aláírása, amelynek egynél több kapcsolt alhálózata van, ahol az útvonalak nem egyenértékűek. Kívülről befelé haladok a konzoltól, mert két lap dönti el, hogy a vizsgálat többi része megéri-e. A kliens konfigurációjában semmi nem magyarázza ezt.

Kezdje a végpontnál, és listázza a kapcsolatokat

A VPC-konzolon nyissa meg a Client VPN endpoints elemet, válassza ki a végpontot, és olvassa el az Associations lapot. Minden kapcsolat egy alhálózat egy rendelkezésre állási zónában, és a kliens arra száll le, amelyiket a szolgáltatás a kapcsolat felépítésekor választ. Jegyezze fel az alhálózat-azonosítókat és az útvonaltáblát, amelyet mindegyik valóban használ, mert ez a két lista az az összehasonlítás, amelyet hamarosan elvégez.

Ha a végpont csak egy kapcsolatot mutat, ez az elmélet téves, és a kliens a jobb gyanúsított.

Hasonlítsa össze a végpont útvonaltábláját minden kapcsolattal

Nyissa meg a Route table lapot ugyanazon a végponton. Minden cél-CIDR-nek van célja, és client VPN esetén a cél egy kapcsolat, nem pedig átjáró. Az AWS minden kapcsolt alhálózathoz célbejegyzést kér, így az az útvonal, amely csak az egyikre mutat, a hozzáférést attól teszi függővé, hogy a munkamenet hová szállt le. Ellenőrizze a számára valóban fontos célt, majd annak engedélyezési szabályát, mert az útvonal adja az utat, a szabály pedig eldönti, ki használhatja.

Ha mindkét réteget táblázatba foglalja, a hibát nehéz nem észrevenni.

A második sor a legtöbb jegyben maga a hiba. A végpont útvonala létezik, ezért senki nem néz tovább, és a csomag egy ugrással később meghal a VPC-n belül.

Kövesse minden alhálózatot a tényleges útvonaltáblájáig

Az az alhálózat, amelynek nincs kifejezett útvonaltábla-kapcsolata, a VPC fő tábláját örökli. A ténylegesen érvényben lévő táblát olvassa, ne azt, amelynek a neve helyesnek tűnik, és a sor címkéje helyett a célt és a célobjektumot hasonlítsa össze.

Az AWS szaggatott hozzáférésről szóló útmutatója ezt útvonal-lefedettségként írja le a kapcsolatok között, ami a helyes modell. A végpont eljuttatja a csomagot egy alhálózathoz, és annak az alhálózatnak a táblájának még mindig tudnia kell, hol található az alkalmazás hálózata.

Javítsa ki a hiányzó sort abban a táblában, amelyik birtokolja. Egy teljes útvonaltábla átmásolása egy működő alhálózatról átmásolja az internetre, eszközre és elkülönítésre vonatkozó döntéseket is, amelyeket soha nem ennek szántak, és ez a csere általában rosszabb, mint a kimaradás, amellyel kezdte.

Ellenőrizze az engedélyezési szabályokat, majd a visszautat

Az engedélyezési szabályok célonként és csoportonként érvényesek, és az útvonalaktól elkülönítve értékelődnek. Az a cél, amelynek mindenhol van útvonala, de a felhasználó csoportjára nincs szabálya, fekete lyukként viselkedik egészségesnek látszó útvonaltáblával.

A visszaút ugyanannyi figyelmet érdemel. Egy peering kapcsolatnak útvonalra van szüksége az alkalmazás VPC-jében vissza a kliens CIDR-je felé, biztonsági csoportszabályokra, amelyek mindkét végén engedik a forgalmat, és olyan hálózati ACL-ekre, amelyek nem dobják el. Az egyirányú elérhetőség, ahol a ping működik és a TCP-kézfogás nem, általában ACL-re vagy biztonsági csoportra mutat, nem a VPN-re.

A végpont saját biztonsági csoportjai a kapcsolat rugalmas hálózati interfészein ülnek, ezért az alkalmazás portját a kliens CIDR-jéből engedélyező szabályt a kapcsolathoz kell rögzíteni, nem csak a példányhoz.

Újracsatlakozással ellenőrizze, nem egyetlen szerencsés kéréssel

Split tunnel esetén a végpont útvonalai a kapcsolat létrejöttekor kerülnek leküldésre, így a megváltozott útvonalkészlet soha nem ér el egy csatlakozva maradó klienst. Szakítsa meg és létesítse újra a kapcsolatot a támogatott klienssel, majd erősítse meg, hogy az új útvonalak jelen vannak a gépen.

Végül korrelálja a kapcsolati naplót a kliens által kapott címmel, és ismételje meg a tesztet elég alkalommal ahhoz, hogy egynél több kapcsolatot érjen el. Egyetlen sikeres kérés javítás után azt bizonyítja, hogy egy útvonal működik, a jegy pedig a másikról szólt.