Jeden koncový bod Client VPN dosáhne na VPC, který je v peeringu s jeho přidruženým VPC, a k tomu, aby to bylo legitimní, bastion nepotřebujete. Volba, která stojí za to, je, kde provoz mění ruce: trasa koncového bodu, která skončí v podsíti přidružení a překročí peeringové spojení, nebo host v peerovaném VPC, který ukončí relaci. Obě cesty fungují a selhávají na různých místech, takže rozhodnutí je o vlastnictví a auditu, ne o tom, co AWS dovoluje. Tady je, jak mezi nimi volím, a čtyři záznamy, které dostanou směrovanou cestu do provozu.

Dvě cesty, jeden koncový bod, různí vlastníci

Na směrované cestě se klientský provoz dostane ke koncovému bodu, přeloží se na adresu síťového rozhraní Client VPN v podsíti přidružení a opustí tuto podsíť přes peeringové spojení z A do B. VPC B neukončuje žádnou VPN relaci; vidí běžný provoz z VPC A, proto jeho zpětná trasa ukazuje na VPC A, ne na klientský pool.

Na cestě přes bastion se klient dostane nejprve na host. Bastion v A stále nechává poslední skok přes peeringové spojení, takže si ponecháte peeringovou práci a přidáte relaci. Bastion v B také potřebuje cestu od klienta, a když je tou cestou stejná trasa koncového bodu, máte směrovaný návrh plus jeden skok. Bastion ubere práci jen tehdy, když už existuje, už má schválení a věc za ním potřebuje hranici relace, ne síťovou hranici.

Čtyři záznamy dostanou směrovanou cestu do provozu

AWS tento scénář dokumentuje na stránce Client VPN how-it-works a v praxi jde o čtyři záznamy, které vlastní dva nebo tři týmy. Rozsahy jsou ilustrativní; peerovaný rozsah musí být jedinečný a zpětný rozsah musí odpovídat vašemu plánu.

ControlWhat it must say
Endpoint route10.70.0.0/16 targets the association subnet
Authorization ruleThe approved group may reach 10.70.0.0/16
VPC A association-subnet table10.70.0.0/16 targets the peering connection
VPC B resource-subnet tableVPC A's range targets the same peering connection

Trasa a oprávnění jsou samostatné kontroly. Správná trasa koncového bodu bez odpovídajícího autorizačního pravidla klientovi nic nedá; autorizační pravidlo pro cíl, který koncový bod neumí směrovat, mu dá černou díru. Obě musí uvádět stejný rozsah.

Trasa koncového bodu ukazuje na podsíť ve vlastním VPC koncového bodu, nikdy na peeringové spojení. Směrovací tabulky VPC ukazují na peeringové spojení, nikdy na instanci nebo rozhraní. Zkopírování hodnoty mezi nimi se uloží bez námitky a nic nesměruje.

Protože podsíť přidružení překládá zdroj klienta, musí B směrovat zpět na VPC A, ne na klientský pool. Posílat klientský rozsah přes peeringové spojení vypadá symetricky, projde revizí a tiše selže, protože B nikdy nevidí paket s klientským zdrojem.

Skupiny zabezpečení a poslední metr oprávnění

Směrování dostane pakety do B; B stále rozhoduje. Pro aktivní peeringové spojení ve stejné oblasti může skupina zabezpečení v B odkazovat na skupinu použitou na přidružení Client VPN, což drží pravidlo úzké a přežije změny adres. Kde odkaz na skupinu není proveditelný, povolte rozsah podsítě přidružení výslovně místo rozšíření na 0.0.0.0/0, které mění chybu směrování v nevysvětlitelný timeout.

Pak zkontrolujte, čeho se směrování nikdy nedotkne: síťové ACL na obou podsítích, allow-list aplikace nebo publikum tokenu, a DNS. Peering nekopíruje privátní hostované zóny, takže notebook může mít funkční trasu na adresu, kterou neumí přeložit, a peeringové spojení nepřidává certifikátu žádnou důvěru. Namiřte koncový bod na resolver, který odpovídá za B, a pak potvrďte, že privátní jméno a certifikát si odpovídají.

Kdy je bastion poctivá odpověď

Držím tři spouštěče pro záměrnou volbu bastionu. Peerované VPC patří týmu, který pro váš rozsah nepřidá zpětnou trasu nebo nepřijme odkaz na skupinu. Přístup musí být schvalován nebo zaznamenáván pro každou relaci a aplikace to neumí nést sama. Nebo musí poslední skok zůstat uvnitř B, protože služba se překládá jen tam a její TLS identita je připnutá k internímu jménu.

Nic z toho není obchvatem faktu, že peering není tranzitivní. Netranzitivita omezuje, co smějí dělat prostředky v B: nemohou použít A jako tranzit do třetího VPC, s nímž je A v peeringu. Nikdy to neznamenalo, že uživatel VPN nemůže dosáhnout přímo peerovaného VPC, a bastion postavený kolem tohoto chybného čtení je host k záplatování bez důvodu.

Opačná chyba časem stojí víc: protlačte každý tým jediným bastionem, který už existuje, a pak zjistěte, že jeho skupina zabezpečení, směrovací tabulka a okno záplatování jsou produkční závislost. Zapište, kterému spouštěči host slouží, a vyřaďte ho, až spouštěč zmizí.

Transit Gateway a několik přidružení mění aritmetiku

Je-li koncový bod připojen přímo k Transit Gateway místo k podsíti, model se mění: klienti se už nepřekládají na adresu rozhraní v podsíti přidružení a směrovací tabulky brány musí nést klientský rozsah plus připojení, které vede k peerovanému VPC. Ve velkém je to čistší, ale práce se přesouvá ze čtyř záznamů do směrovacích tabulek brány.

Několik přidružení násobí kontroly. Trasa koncového bodu patří koncovému bodu, ale každá podsíť přidružení potřebuje směrovací tabulku se skutečným peeringovým dalším skokem. Relace může projít jedním přidružením, zatímco jiné nemá zpětnou cestu, takže testujte každé.

Pořadí ověření, které rychle najde zlom

Provádějte je v pořadí; každý krok může projít, zatímco další selže, a timeout klienta téměř nikdy neřekne, který se zlomil.

  1. Přeložte jméno aplikace z klienta a zkontrolujte, že adresa je uvnitř peerovaného rozsahu.
  2. Připojte se a pak si přečtěte log spojení koncového bodu pro přidružení, které relaci ukončilo.
  3. Na této podsíti přidružení potvrďte, že směrovací tabulka ukazuje peerovaný rozsah na aktivní peeringové spojení.
  4. Na podsíti prostředků v B potvrďte zpětný záznam pro rozsah rozhraní a odpovídající pravidla skupiny.
  5. Otestujte jednu povolenou operaci a jeden prostředek, který musí zůstat nedostupný; druhý chytá zbytky ladění.
  6. Po každé změně trasy split-tunnel se připojte znovu, protože běžící tunel nepřevezme novou sadu tras.

Dva příznaky stojí za zapamatování. SYN, který dorazí do B bez odpovědi, je téměř vždy chybějící zpětná trasa. Spojení, které se dokončí a pak se resetuje, je obvykle skupina, ACL nebo aplikace. Ani jedno se v logu koncového bodu neobjeví jako příčina, takže držte čtyři záznamy s vlastníkem u každého.

Pokud neplatí žádný ze tří spouštěčů, dokončete směrovanou cestu a zapište ty čtyři záznamy. Pokud platí jeden, držte bastion jen pro tuto hranici a nechte trasu koncového bodu službám, které před sebou relaci nepotřebují.

Související články