AWS Client VPN eller en bastion for at nå en peering-VPC

Ét Client VPN-endpoint kan nå en VPC, der er peered med sin tilknyttede VPC, og du har ikke brug for en bastion for at gøre det legitimt. Det valg, der er værd at træffe, er, hvor trafikken skifter hænder: en endpoint-rute, der lander i associationssubnettet og krydser peering-forbindelsen, eller en vært i den peered VPC, der afslutter sessionen. Begge veje virker, og de fejler forskellige steder, så beslutningen handler om ejerskab og revision, ikke om hvad AWS tillader. Her er hvordan jeg vælger mellem dem, og de fire poster, der får den rutede vej til at virke.

To veje, ét endpoint, forskellige ejere

På den rutede vej når klienttrafikken endpointet, oversættes til adressen på Client VPN-netværksgrænsefladen i associationssubnettet og forlader det subnettet over A-til-B-peering-forbindelsen. VPC B afslutter ingen VPN-session; den ser almindelig trafik fra VPC A, og derfor peger dens returrute på VPC A, ikke på klientpuljen.

På bastionvejen når klienten først en vært. En bastion i A lader stadig det sidste hop krydse peering-forbindelsen, så du beholder peering-arbejdet og tilføjer en session. En bastion i B har også brug for en vej fra klienten, og når den vej er den samme endpoint-rute, har du det rutede design plus et hop. Bastionen fjerner kun arbejde, når den allerede findes, allerede er godkendt, og det bag den har brug for en sessionsgrænse frem for en netværksgrænse.

Fire poster får den rutede vej til at virke

AWS dokumenterer dette scenarie på Client VPN how-it-works-siden, og i praksis kommer det ned til fire poster, som to eller tre teams ejer. Områderne er illustrative; det peered område skal være unikt, og returområdet skal passe til din plan.

Rute og tilladelse er separate kontroller. En korrekt endpoint-rute uden en matchende autorisationsregel giver klienten intet; en autorisationsregel for en destination, som endpointet ikke kan route, giver den et sort hul. Begge skal nævne det samme område.

Endpoint-ruten peger på et subnet i endpointets egen VPC, aldrig på peering-forbindelsen. VPC-rutetabellerne peger på peering-forbindelsen, aldrig på en instans eller en grænseflade. At kopiere en værdi mellem de to gemmes uden klage og router intet.

Fordi associationssubnettet oversætter klientkilden, skal B route tilbage til VPC A, ikke til klientpuljen. At sende klientområdet over peering-forbindelsen ser symmetrisk ud, består gennemgangen og fejler lydløst, fordi B aldrig ser en pakke med en klientkilde.

Sikkerhedsgrupper og den sidste meter tilladelse

Routing får pakker ind i B; B bestemmer stadig. For en aktiv peering-forbindelse i samme region kan en sikkerhedsgruppe i B referere til den gruppe, der er anvendt på Client VPN-tilknytningen, hvilket holder reglen smal og overlever adresseændringer. Hvor en gruppereference ikke er mulig, tillad associationssubnettets område eksplicit i stedet for at udvide til 0.0.0.0/0, hvilket gør en routingfejl til en uforklaret timeout.

Kontroller derefter det, routing aldrig rører: netværks-ACL'er på begge subnets, applikationens allow-list eller tokenets målgruppe, og DNS. Peering kopierer ikke private hostede zoner, så laptop'en kan holde en fungerende rute til en adresse, den ikke kan slå op, og en peering-forbindelse tilføjer ingen tillid til et certifikat. Peg endpointet på en resolver, der svarer for B, og bekræft derefter, at det private navn og certifikatet passer sammen.

Når bastionen er det ærlige svar

Jeg holder tre triggere for bevidst at vælge en bastion. Den peered VPC tilhører et team, der ikke vil tilføje en returrute for dit område eller ikke vil acceptere en gruppereference. Adgang skal godkendes eller registreres pr. session, og applikationen kan ikke bære det selv. Eller det sidste hop skal blive inde i B, fordi tjenesten kun slår op der, og dens TLS-identitet er fastgjort til et internt navn.

Intet af det er en omvej omkring, at peering ikke er transitiv. Ikke-transitivitet begrænser, hvad ressourcer i B må gøre: de kan ikke bruge A som transit til en tredje VPC, som A er peered med. Det betød aldrig, at en VPN-bruger ikke kan nå en direkte peered VPC, og en bastion bygget for at omgå den fejllæsning er en vært, der skal patches uden grund.

Den omvendte fejl koster mere over tid: pres alle teams gennem den ene bastion, der allerede findes, og opdag så, at dens sikkerhedsgruppe, rutetabell og patch-vindue er produktionsafhængigheden. Skriv ned, hvilken trigger værten tjener, og afvikl den, når triggeren forsvinder.

Transit Gateway og flere tilknytninger ændrer regnestykket

Hvis endpointet er knyttet direkte til en Transit Gateway i stedet for til et subnet, ændres modellen: klienter oversættes ikke længere til en grænsefladeadresse i et associationssubnet, og gateway-rutetabellerne skal bære klientområdet plus den tilknytning, der fører til den peered VPC. Det er renere i skala, men arbejdet flytter fra fire poster til gateway-rutetabeller.

Flere tilknytninger multiplicerer kontrollerne. Endpoint-ruten tilhører endpointet, men hvert associationssubnet har brug for en rutetabell med et rigtigt peering-next-hop. En session kan lykkes gennem én tilknytning, mens en anden ikke har nogen returvej, så test hver enkelt.

Verifikationsrækkefølge, der hurtigt finder bruddet

Kør disse i rækkefølge; hvert trin kan bestå, mens det næste fejler, og en klient-timeout siger næsten aldrig, hvilket der brød.

1. Slå applikationens navn op fra klienten, og kontroller, at adressen ligger inden for det peered område.
2. Forbind, og læs derefter endpoint-forbindelsesloggen for den tilknytning, der afsluttede sessionen.
3. På det associationssubnet skal du bekræfte, at rutetabellen peger det peered område på en aktiv peering-forbindelse.
4. På ressource-subnettet i B skal du bekræfte en returpost for grænsefladeområdet og matchende grupperegler.
5. Test én tilladt operation og én ressource, der skal forblive uopnåelig; den anden fanger rester fra fejlfinding.
6. Genopret forbindelsen efter enhver ændring af split-tunnel-ruten, fordi en kørende tunnel ikke optager et nyt rutesæt.

To symptomer er værd at huske. En SYN, der når B uden svar, er næsten altid den manglende returrute. En forbindelse, der fuldføres og derefter nulstilles, er normalt gruppen, ACL'en eller applikationen. Ingen af dem vises i endpoint-loggen som årsag, så hold de fire poster med en ejer ved hver.

Hvis ingen af de tre triggere gælder, færdiggør den rutede vej, og registrer de fire poster. Hvis én gælder, behold bastionen kun for den grænse og lad endpoint-ruten være til tjenester, der ikke har brug for en session foran sig.