AWS Client VPN s rozděleným tunelem: které trasy publikovat

Konzola nabízí přepínač rozděleného tunelu, takže rozhodnutí vypadá jako zaškrtávací políčko. Není. Ke klientovi skutečně dorazí publikovaná sada tras koncového bodu a tento seznam rozhoduje o tom, které privátní prefixy používají tunel, zda obecný internetový provoz zůstává lokálně nebo vychází přes AWS a se kterým resolverem může klient ještě mluvit. Tři otázky rozhodují o návrhu a na každou lze odpovědět špatně, zatímco spojení stále uspěje.

Příznak rozděleného tunelu není seznam cílů

AWS popisuje rozdělený tunel jako přidání tras koncového bodu do směrovací tabulky klienta při navázání spojení. Trasa pro privátní VPC omezuje tunel na tento cíl; vše ostatní jde obvyklou cestou klienta. Výchozí trasa je jiná instrukce s jiným účinkem, a proto dokumentace rozděleného tunelu varuje před publikováním 0.0.0.0/0 na koncovém bodu nakonfigurovaném pro tento režim: obvykle spojení spíše přeruší, než rozšíří. Směrovací tabulka koncového bodu je zásada a směrovací tabulka klienta je výsledek, který můžete prozkoumat.

Čtěte směrovací tabulku koncového bodu a nainstalované trasy klienta společně. Označení popisuje záměr; trasy popisují, co se děje.

První rozhodnutí: má obecný internetový provoz zůstat lokálně?

Pokud má prohlížení používat vlastní připojení uživatele, publikujte jen privátní cíle, které práce potřebuje, a tam přestaňte. Nepřidávejte internetovou trasu proto, že návod na plný tunel jednu obsahoval, a nepředpokládejte, že trasa navíc zlepšuje zabezpečení. Mění cestu, nepřidává zásadu a obvykle stojí latenci, kterou jste neplánovali.

Pokud má internetový provoz vycházet přes AWS, postavte dokumentovanou architekturu přístupu k internetu: trasu koncového bodu, pravidla autorizace, cestu přidružené podsítě, bezpečnostní zásadu a funkční výstup nahoru. Výchozí trasa sama o sobě nic z toho neposkytuje.

Druhé rozhodnutí: které privátní prefixy a s čím oprávněním?

Publikujte nejmenší sadu cílů, která obslouží skutečnou práci, a ověřte, že každá přidružená podsíť k nim umí směrovat. Cíl trasy koncového bodu a směrování VPC v podsíti jsou různé vrstvy a trasa, která existuje v jedné, není důkazem o druhé. Autorizace je opět samostatná: cíl může být dostupný a přesto odmítnutý, protože skupina klienta nemá pravidlo, které ho povoluje.

Otestování jednoho úspěšného sezení dokazuje jednu cestu. Zkontrolujte každou přidruženou podsíť, protože přidružení podsítě přidané později je přesně to místo, kde chybějící trasa obvykle žije.

Když má být cíl dostupný podle jména, všimněte si, že další otázkou je překlad jmen, ne trasa.

Třetí rozhodnutí: který resolver následuje tunel?

Klient může dostat DNS server dostupný jen přes VPN a tento resolver funguje jen tehdy, je-li jeho adresa sama uvnitř autorizované trasy. Ověřte obě poloviny: adresa resolveru následuje publikovanou trasu a server odpovídá na jména, na která se aplikace ptá. Požadavek, který uspěje podle adresy, ale selže podle jména hostitele, ukazuje na pojmenování, ne na směrování, a ladění tunelu v takovém případě promarní odpoledne.

Veřejná jména by se měla překládat jako před připojením, což je další důvod být přesní v tom, co publikujete.

Změňte sadu tras a potom ověřte oba světy

AWS uvádí, že změna tras na koncovém bodu s rozděleným tunelem resetuje klientská spojení. Naplánujte změnu s tím: aplikujte ji, znovu se připojte podporovaným klientem a přečtěte nainstalované trasy znovu, místo abyste věřili stavu aplikovanému před úpravou. Zastaralý aplikovaný stav je nejčastějším důvodem, proč správná změna vypadá rozbitá.

Přijměte návrh jen tehdy, když se jeden privátní prostředek a jeden veřejný cíl chovají podle očekávání, podle jména i podle adresy, v adresních rodinách, které skutečně podporujete. Tunel, který ověří identitu, není totéž jako tunel, který správně rozděluje provoz.

Zapište seznam tras do runbooku vedle odůvodnění, aby příští člověk rozeznal úmyslné vyloučení od zapomenutého.