Přerušovaný přístup přes AWS Client VPN: prověřte každou přidruženou podsíť

Uživatel se připojí, otevře interní aplikaci a dostane odpověď; kolega na stejném koncovém bodu dostane časový limit z identického notebooku na stejné Wi-Fi. Tento vzorec je podpis koncového bodu client VPN s více než jednou přidruženou podsítí, kde cesty nejsou rovnocenné. Procházím to od konzoly směrem ven, protože dvě karty rozhodují o tom, zda má zbytek vyšetřování smysl. Nic v konfiguraci klienta to nevysvětluje.

Začněte u koncového bodu a vypište přidružení

V konzole VPC otevřete Client VPN endpoints, vyberte koncový bod a přečtěte kartu Associations. Každé přidružení je podsíť v zóně dostupnosti a klient přistane na té, kterou služba zvolí při sestavení spojení. Poznamenejte si ID podsítí a tabulku tras, kterou každá skutečně používá, protože tyto dva seznamy jsou porovnání, které se chystáte udělat.

Pokud koncový bod ukazuje jediné přidružení, tato teorie je chybná a lepším podezřelým je klient.

Porovnejte tabulku tras koncového bodu s každým přidružením

Otevřete kartu Route table na stejném koncovém bodu. Každý cílový CIDR tam má cíl a u client VPN je cílem přidružení, nikoli brána. AWS vyžaduje záznam cíle pro každou přidruženou podsíť, takže trasa, která míří jen na jednu z nich, činí přístup závislým na tom, kde spojení přistálo. Zkontrolujte cíl, na kterém vám skutečně záleží, a pak jeho autorizační pravidlo, protože trasa dodává cestu a pravidlo rozhoduje, kdo ji smí použít.

Jakmile obě vrstvy zanesete do tabulky, poruchu je těžké přehlédnout.

Druhý řádek je ve většině tiketů celá chyba. Trasa koncového bodu existuje, takže se nikdo nedívá dál, a paket umírá o jeden skok později uvnitř VPC.

Sledujte každou podsíť do její efektivní tabulky tras

Podsíť bez výslovného přidružení k tabulce tras dědí hlavní tabulku VPC. Čtěte tabulku, která je skutečně v platnosti, ne tu, jejíž název vypadá správně, a porovnávejte cíl a směr, ne označení řádku.

Průvodce AWS pro přerušovaný přístup to popisuje jako pokrytí trasami napříč přidruženími, což je správný model. Koncový bod doručí paket do podsítě a tabulka této podsítě stále musí vědět, kde sídlí síť aplikace.

Opravte chybějící řádek v tabulce, která ho vlastní. Kopírování celé tabulky tras z funkční podsítě zkopíruje i volby pro internet, zařízení a izolaci, které pro tuto nebyly nikdy zamýšlené, a tato výměna je obvykle horší než výpadek, se kterým jste začali.

Zkontrolujte autorizační pravidla a pak cestu zpět

Autorizační pravidla jsou pro cíl a pro skupinu a vyhodnocují se odděleně od tras. Cíl s trasami všude, ale bez pravidla pro skupinu uživatele, se chová jako černá díra s tabulkou tras, která vypadá zdravě.

Zpáteční cesta si zaslouží stejnou pozornost. Propojení peering potřebuje trasu ve VPC aplikace mířící zpět na CIDR klienta, pravidla bezpečnostních skupin, která provoz na obou koncích povolí, a síťové ACL, která ho nezahodí. Jednosměrná dosažitelnost, kdy ping funguje a TCP handshake ne, obvykle ukazuje na ACL nebo bezpečnostní skupinu, ne na VPN.

Vlastní bezpečnostní skupiny koncového bodu sedí na elastických síťových rozhraních přidružení, takže pravidlo, které povoluje port aplikace z CIDR klienta, musí být připojeno k přidružení, ne jen k instanci.

Ověřujte opětovným připojením, ne jednou šťastnou žádostí

Při split tunnel se trasy koncového bodu předávají při navázání spojení, takže změněná sada tras se nikdy nedostane ke klientovi, který zůstává připojený. Odpojte se a znovu se připojte podporovaným klientem, poté ověřte, že nové trasy jsou na stroji přítomné.

Nakonec spárujte protokol spojení s adresou, kterou klient dostal, a test opakujte dostatečněkrát, abyste zasáhli více než jedno přidružení. Jediný úspěšný požadavek po opravě dokazuje, že jedna cesta funguje, a tiket byl o té druhé.