Prerušovaný prístup cez AWS Client VPN: skontrolujte každú pridruženú podsieť

Používateľ sa pripojí, otvorí internú aplikáciu a dostane odpoveď; kolega na tom istom koncovom bode dostane časový limit z identického notebooku na tej istej Wi-Fi. Tento vzorec je podpis koncového bodu client VPN s viac ako jednou pridruženou podsietňou, kde cesty nie sú rovnocenné. Prechádzam to od konzoly smerom von, pretože dve karty rozhodujú, či má zvyšok vyšetrovania zmysel. Nič v konfigurácii klienta to nevysvetľuje.

Začnite pri koncovom bode a vypíšte pridruženia

V konzole VPC otvorte Client VPN endpoints, vyberte koncový bod a prečítajte kartu Associations. Každé pridruženie je podsieť v zóne dostupnosti a klient pristane na tej, ktorú služba vyberie pri zostavovaní spojenia. Poznačte si ID podsietí a tabuľku trás, ktorú každá skutočne používa, pretože tieto dva zoznamy sú porovnanie, ktoré sa chystáte urobiť.

Ak koncový bod zobrazuje jediné pridruženie, táto teória je nesprávna a lepším podozrivým je klient.

Porovnajte tabuľku trás koncového bodu s každým pridružením

Otvorte kartu Route table na tom istom koncovom bode. Každý cieľový CIDR tam má cieľ a pri client VPN je cieľom pridruženie, nie brána. AWS vyžaduje záznam cieľa pre každú pridruženú podsieť, takže trasa, ktorá mieri len na jednu z nich, robí prístup závislým od toho, kde spojenie pristálo. Skontrolujte cieľ, na ktorom vám skutočne záleží, a potom jeho autorizačné pravidlo, pretože trasa dodáva cestu a pravidlo rozhoduje, kto ju smie použiť.

Keď obe vrstvy zanesiete do tabuľky, poruchu je ťažké prehliadnuť.

Druhý riadok je vo väčšine tiketov celá chyba. Trasa koncového bodu existuje, takže sa nikto nepozerá ďalej, a paket umiera o jeden skok neskôr vnútri VPC.

Sledujte každú podsieť do jej efektívnej tabuľky trás

Podsieť bez výslovného pridruženia k tabuľke trás dedí hlavnú tabuľku VPC. Čítajte tabuľku, ktorá je skutočne v platnosti, nie tú, ktorej názov vyzerá správne, a porovnávajte cieľ a smer, nie označenie riadku.

Príručka AWS pre prerušovaný prístup to opisuje ako pokrytie trasami naprieč pridruženiami, čo je správny model. Koncový bod doručí paket do podsiete a tabuľka tejto podsiete stále musí vedieť, kde sídli sieť aplikácie.

Opravte chýbajúci riadok v tabuľke, ktorá ho vlastní. Kopírovanie celej tabuľky trás z funkčnej podsiete skopíruje aj voľby pre internet, zariadenia a izoláciu, ktoré pre túto neboli nikdy zamýšľané, a táto výmena je zvyčajne horšia než výpadok, s ktorým ste začali.

Skontrolujte autorizačné pravidlá a potom cestu späť

Autorizačné pravidlá sú pre cieľ a pre skupinu a vyhodnocujú sa oddelene od trás. Cieľ s trasami všade, ale bez pravidla pre skupinu používateľa, sa správa ako čierna diera s tabuľkou trás, ktorá vyzerá zdravo.

Späťná cesta si zaslúži rovnakú pozornosť. Prepojenie peering potrebuje trasu vo VPC aplikácie mieriacu späť na CIDR klienta, pravidlá bezpečnostných skupín, ktoré povolia prevádzku na oboch koncoch, a sieťové ACL, ktoré ho nezahodia. Jednosmerná dostupnosť, keď ping funguje a TCP handshake nie, zvyčajne ukazuje na ACL alebo bezpečnostnú skupinu, nie na VPN.

Vlastné bezpečnostné skupiny koncového bodu sedia na elastických sieťových rozhraniach pridruženia, takže pravidlo, ktoré povoľuje port aplikácie z CIDR klienta, musí byť pripojené k pridruženiu, nielen k inštancii.

Overujte opätovným pripojením, nie jednou šťastnou žiadosťou

Pri split tuneli sa trasy koncového bodu odovzdávajú pri nadviazaní spojenia, takže zmenená sada trás sa nikdy nedostane ku klientovi, ktorý zostáva pripojený. Odpojte sa a znova sa pripojte podporovaným klientom, potom overte, že nové trasy sú v stroji prítomné.

Nakoniec spárujte záznam spojení s adresou, ktorú klient dostal, a test opakujte dostatočne krát, aby ste zasiahli viac ako jedno pridruženie. Jediná úspešná žiadosť po oprave dokazuje, že jedna cesta funguje, a tiket bol o tej druhej.