AWS Client VPN s rozdeleným tunelom: ktoré trasy publikovať

Konzola ponúka prepínač rozdeleného tunela, takže rozhodnutie vyzerá ako zaškrtávacie pole. Nie je. Ku klientovi sa skutočne dostane publikovaná sada trás koncového bodu a tento zoznam rozhoduje, ktoré privátne prefixy používajú tunel, či všeobecná internetová prevádzka zostáva lokálna alebo vychádza cez AWS a s ktorým resolverom môže klient ešte hovoriť. Tri otázky rozhodujú o návrhu a na každú sa dá odpovedať zle, kým spojenie stále uspeje.

Príznak rozdeleného tunela nie je zoznam cieľov

AWS opisuje rozdelený tunel ako pridanie trás koncového bodu do smerovacej tabuľky klienta pri nadviazaní spojenia. Trasa pre privátnu VPC obmedzuje tunel na tento cieľ; všetko ostatné ide obvyklou cestou klienta. Predvolená trasa je iná inštrukcia s iným účinkom, a preto dokumentácia rozdeleného tunela varuje pred publikovaním 0.0.0.0/0 na koncovom bode nakonfigurovanom pre tento režim: zvyčajne spojenie skôr preruší, než rozšíri. Smerovacia tabuľka koncového bodu je zásada a smerovacia tabuľka klienta je výsledok, ktorý môžete preskúmať.

Čítajte smerovaciu tabuľku koncového bodu a nainštalované trasy klienta spoločne. Označenie opisuje zámer; trasy opisujú, čo sa deje.

Prvé rozhodnutie: má všeobecná internetová prevádzka zostať lokálna?

Ak má prehliadanie používať vlastné pripojenie používateľa, publikujte len privátne ciele, ktoré práca potrebuje, a tam prestaňte. Nepridávajte internetovú trasu preto, že návod na plný tunel jednu obsahoval, a nepredpokladajte, že trasa navyše zlepšuje zabezpečenie. Mení cestu, nepridáva zásadu a zvyčajne stojí latenciu, ktorú ste neplánovali.

Ak má internetová prevádzka vychádzať cez AWS, postavte dokumentovanú architektúru prístupu na internet: trasu koncového bodu, pravidlá autorizácie, cestu pridruženej podsiete, bezpečnostnú zásadu a funkčný výstup nahor. Predvolená trasa sama o sebe nič z toho neposkytuje.

Druhé rozhodnutie: ktoré privátne prefixy a s akým oprávnením?

Publikujte najmenšiu sadu cieľov, ktorá obslúži skutočnú prácu, a overte, že každá pridružená podsiet dokáže k nim smerovať. Cieľ trasy koncového bodu a smerovanie VPC v podsieti sú rôzne vrstvy a trasa, ktorá existuje v jednej, nie je dôkazom o druhej. Autorizácia je opäť samostatná: cieľ môže byť dostupný a napriek tomu odmietnutý, pretože skupina klienta nemá pravidlo, ktoré ho povoľuje.

Otestovanie jednej úspešnej relácie dokazuje jednu cestu. Skontrolujte každú pridruženú podsiet, pretože pridruženie podsiete pridané neskôr je presne to miesto, kde chýbajúca trasa zvyčajne žije.

Keď má byť cieľ dostupný podľa mena, všimnite si, že ďalšou otázkou je preklad mien, nie trasa.

Tretie rozhodnutie: ktorý resolver nasleduje tunel?

Klient môže dostať DNS server dostupný len cez VPN a tento resolver funguje len vtedy, ak je jeho adresa sama vnútri autorizovanej trasy. Overte obe polovice: adresa resolvera nasleduje publikovanú trasu a server odpovedá na mená, na ktoré sa aplikácia pýta. Požiadavka, ktorá uspeje podľa adresy, ale zlyhá podľa mena hostiteľa, ukazuje na pomenovanie, nie na smerovanie, a ladenie tunela v takom prípade premrhá popoludnie.

Verejné mená by sa mali prekladať ako pred pripojením, čo je ďalší dôvod byť presný v tom, čo publikujete.

Zmeňte sadu trás a potom overte oba svety

AWS uvádza, že zmena trás na koncovom bode s rozdeleným tunelom resetuje klientske spojenia. Naplánujte zmenu s tým: aplikujte ju, znova sa pripojte podporovaným klientom a prečítajte nainštalované trasy odznova, namiesto toho, aby ste dôverovali stavu aplikovanému pred úpravou. Zastaraný aplikovaný stav je najčastejším dôvodom, prečo správna zmena vyzerá pokazená.

Prijmite návrh len vtedy, keď sa jeden privátny prostriedok a jeden verejný cieľ správajú podľa zámeru, podľa mena aj podľa adresy, v adresných rodinách, ktoré skutočne podporujete. Tunel, ktorý overuje identitu, nie je to isté ako tunel, ktorý správne rozdeľuje prevádzku.

Zapíšte zoznam trás do runbooku vedľa odôvodnenia, aby ďalší človek rozoznal úmyselné vylúčenie od zabudnutého.