AWS Client VPN eller en bastion för att nå en peering-VPC

En enda Client VPN-endpoint kan nå en VPC som är peerad med sin associerade VPC, och du behöver ingen bastion för att göra det legitimt. Valet som är värt att göra är var trafiken byter händer: en endpoint-rutt som landar i associationssubnätet och korsar peering-anslutningen, eller en värd i den peerade VPC:n som avslutar sessionen. Båda vägarna fungerar och de brister på olika ställen, så beslutet handlar om ägarskap och revision, inte om vad AWS tillåter. Här är hur jag väljer mellan dem, och de fyra posterna som får den routade vägen att fungera.

Två vägar, en endpoint, olika ägare

På den routade vägen når klienttrafiken endpointen, översätts till adressen för Client VPN-nätverksgränssnittet i associationssubnätet och lämnar det subnätet över A-till-B-peering-anslutningen. VPC B avslutar ingen VPN-session; den ser vanlig trafik från VPC A, därför pekar dess returrutt på VPC A och inte på klientpoolen.

På bastionvägen når klienten först en värd. En bastion i A låter fortfarande det sista hoppet korsa peering-anslutningen, så du behåller peering-arbetet och lägger till en session. En bastion i B behöver också en väg från klienten, och när den vägen är samma endpoint-rutt har du den routade designen plus ett hopp. Bastionen tar bara bort arbete när den redan finns, redan är godkänd, och det bakom den behöver en sessionsgräns snarare än en nätverksgräns.

Fyra poster får den routade vägen att fungera

AWS dokumenterar detta scenario på Client VPN how-it-works-sidan, och i praktiken kokar det ner till fyra poster som två eller tre team äger. Intervallen är illustrativa; peering-intervallet måste vara unikt och returintervallet måste matcha din plan.

Rutt och tillstånd är separata kontroller. En korrekt endpoint-rutt utan en matchande auktoriseringsregel ger klienten ingenting; en auktoriseringsregel för en destination som endpointen inte kan routa ger den ett svart hål. Båda måste ange samma intervall.

Endpoint-rutten pekar på ett subnät i endpointens egen VPC, aldrig på peering-anslutningen. VPC:ns routtabeller pekar på peering-anslutningen, aldrig på en instans eller ett gränssnitt. Att kopiera ett värde mellan de två sparas utan klagomål och routar ingenting.

Eftersom associationssubnätet översätter klientkällan, måste B routa tillbaka till VPC A, inte till klientpoolen. Att skicka klientintervallet över peering-anslutningen ser symmetriskt ut, passerar granskningen och misslyckas tyst eftersom B aldrig ser ett paket med klientkälla.

Säkerhetsgrupper och den sista metern tillstånd

Routning får paket in i B; B bestämmer fortfarande. För en aktiv peering-anslutning i samma region kan en säkerhetsgrupp i B referera till gruppen som tillämpas på Client VPN-associationen, vilket håller regeln smal och överlever adressändringar. Där en gruppreferens inte är genomförbar, tillåt associationssubnätets intervall explicit i stället för att vidga till 0.0.0.0/0, vilket förvandlar ett routningsfel till en oförklarad timeout.

Kontrollera sedan det som routning aldrig rör: nätverks-ACL:er på båda subnäten, applikationens allowlist eller tokenets målgrupp, och DNS. Peering kopierar inte privata hostade zoner, så laptopen kan hålla en fungerande rutt till en adress den inte kan slå upp, och en peering-anslutning lägger inte till något förtroende för ett certifikat. Peka endpointen mot en resolver som svarar för B och bekräfta sedan att det privata namnet och certifikatet stämmer.

När bastionen är det ärliga svaret

Jag håller tre utlösare för att medvetet välja en bastion. Den peerade VPC:n tillhör ett team som inte lägger till en returrutt för ditt intervall eller inte accepterar en gruppreferens. Åtkomst måste godkännas eller registreras per session och applikationen kan inte bära det själv. Eller så måste det sista hoppet stanna inuti B eftersom tjänsten bara löses upp där och dess TLS-identitet är fäst vid ett internt namn.

Inget av detta är en omväg runt att peering inte är transitivt. Icke-transitivitet begränsar vad resurser i B får göra: de kan inte använda A som transit till en tredje VPC som A är peerad med. Det har aldrig betytt att en VPN-användare inte kan nå en direkt peerad VPC, och en bastion byggd för att kringgå den felläsningen är en värd som patchas utan anledning.

Det omvända felet kostar mer över tid: pressa varje team genom den enda bastion som redan finns och upptäck sedan att dess säkerhetsgrupp, routtabell och patchfönster är produktionsberoendet. Skriv ner vilken utlösare värden tjänar och avveckla den när utlösaren försvinner.

Transit Gateway och flera associationer ändrar aritmetiken

Om endpointen är kopplad direkt till en Transit Gateway i stället för till ett subnät ändras modellen: klienter översätts inte längre till en gränssnittsadress i ett associationssubnät, och gatewayens routtabeller måste bära klientintervallet plus den anslutning som leder till den peerade VPC:n. Det är renare i skala, men arbetet flyttar från fyra poster till gateway-routtabeller.

Flera associationer multiplicerar kontrollerna. Endpoint-rutten tillhör endpointen, men varje associationssubnät behöver en routtabell med ett verkligt peering-nästa hopp. En session kan lyckas genom en association medan en annan inte har någon returväg, så testa var och en.

Verifieringsordning som hittar brottet snabbt

Kör dessa i ordning; varje steg kan lyckas medan nästa misslyckas, och en klienttimeout säger nästan aldrig vilket som brast.

1. Slå upp applikationsnamnet från klienten och kontrollera att adressen ligger inom peering-intervallet.
2. Anslut och läs sedan endpointens anslutningslogg för den association som avslutade sessionen.
3. På det associationssubnätet, bekräfta att routtabellen pekar peering-intervallet mot en aktiv peering-anslutning.
4. På resurssubnätet i B, bekräfta en returpost för gränssnittsintervallet och matchande gruppregler.
5. Testa en tillåten operation och en resurs som måste förbli oåtkomlig; den andra fångar rester av felsökning.
6. Anslut igen efter varje ändring av split-tunnel-rutten, eftersom en pågående tunnel inte tar upp en ny ruttuppsättning.

Två symtom är värda att minnas. En SYN som når B utan svar är nästan alltid den saknade returrutten. En anslutning som slutförs och sedan återställs är vanligtvis gruppen, ACL:en eller applikationen. Ingen av dem visas i endpointloggen som orsak, så håll de fyra posterna med en ägare bredvid varje.

Om ingen av de tre utlösarna gäller, slutför den routade vägen och registrera de fyra posterna. Om en gäller, behåll bastionen bara för den gränsen och lämna endpoint-rutten för tjänster som inte behöver en session framför sig.