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

Ett Client VPN-endepunkt kan nå en VPC som er peeret med sin tilknyttede VPC, og du trenger ikke en bastion for å gjøre det legitimt. Valget som er verdt å ta, er hvor trafikken skifter hender: en endepunkt-rute som lander i assosiasjonssubnettet og krysser peering-forbindelsen, eller en vert i den peerete VPC-en som avslutter økten. Begge veier fungerer, og de feiler på forskjellige steder, så beslutningen handler om eierskap og revisjon, ikke om hva AWS tillater. Her er hvordan jeg velger mellom dem, og de fire oppføringene som får den rutete veien til å virke.

To veier, ett endepunkt, forskjellige eiere

På den rutete veien når klienttrafikken endepunktet, oversettes til adressen til Client VPN-nettverksgrensesnittet i assosiasjonssubnettet og forlater det subnettet over A-til-B-peering-forbindelsen. VPC B avslutter ingen VPN-økt; den ser vanlig trafikk fra VPC A, og derfor peker returruten på VPC A, ikke på klientpoolen.

På bastionveien når klienten først en vert. En bastion i A lar fortsatt det siste hoppet krysse peering-forbindelsen, så du beholder peering-arbeidet og legger til en økt. En bastion i B trenger også en vei fra klienten, og når den veien er den samme endepunkt-ruten, har du det rutete designet pluss ett hopp. Bastionen fjerner bare arbeid når den allerede finnes, allerede er godkjent, og det bak den trenger en øktgrense fremfor en nettverksgrense.

Fire oppføringer får den rutete veien til å virke

AWS dokumenterer dette scenariet på Client VPN how-it-works-siden, og i praksis kommer det ned til fire oppføringer som to eller tre team eier. Områdene er illustrative; peering-området må være unikt, og returområdet må passe planen din.

Rute og tillatelse er separate kontroller. En korrekt endepunkt-rute uten en samsvarende autorisasjonsregel gir klienten ingenting; en autorisasjonsregel for en destinasjon endepunktet ikke kan rute gir den et svart hull. Begge må nevne det samme området.

Endepunkt-ruten peker på et subnett i endepunktets egen VPC, aldri på peering-forbindelsen. VPC-rutetabellene peker på peering-forbindelsen, aldri på en instans eller et grensesnitt. Å kopiere en verdi mellom de to lagres uten klage og ruter ingenting.

Fordi assosiasjonssubnettet oversetter klientkilden, må B rute tilbake til VPC A, ikke til klientpoolen. Å sende klientområdet over peering-forbindelsen ser symmetrisk ut, består gjennomgangen og feiler stille fordi B aldri ser en pakke med klientkilde.

Sikkerhetsgrupper og den siste meteren tillatelse

Ruting får pakker inn i B; B bestemmer fortsatt. For en aktiv peering-forbindelse i samme region kan en sikkerhetsgruppe i B referere til gruppen som brukes på Client VPN-assosiasjonen, noe som holder regelen smal og overlever adresseendringer. Der en gruppereferanse ikke er mulig, tillat assosiasjonssubnettets område eksplisitt i stedet for å utvide til 0.0.0.0/0, som gjør en rute feil om til en uforklart tidsavbrudd.

Kontroller deretter det ruting aldri berører: nettverks-ACL-er på begge subnett, applikasjonens tillatelsesliste eller tokenets målgruppe, og DNS. Peering kopierer ikke private hostede soner, så laptopen kan holde en fungerende rute til en adresse den ikke kan slå opp, og en peering-forbindelse legger ikke til tillit til et sertifikat. Pek endepunktet mot en resolver som svarer for B, og bekreft deretter at det private navnet og sertifikatet stemmer.

Når bastionen er det ærlige svaret

Jeg holder tre utløsere for bevisst å velge en bastion. Den peerete VPC-en tilhører et team som ikke vil legge til en returrute for området ditt eller ikke vil akseptere en gruppereferanse. Tilgang må godkjennes eller registreres per økt, og applikasjonen kan ikke bære det selv. Eller det siste hoppet må bli inne i B fordi tjenesten bare slås opp der, og TLS-identiteten er festet til et internt navn.

Ingenting av dette er en omvei rundt at peering ikke er transitivt. Ikke-transitivitet begrenser hva ressurser i B kan gjøre: de kan ikke bruke A som transit til en tredje VPC som A er peeret med. Det betydde aldri at en VPN-bruker ikke kan nå en direkte peeret VPC, og en bastion bygget for å omgå den feillesningen er en vert som patches uten grunn.

Den motsatte feilen koster mer over tid: press alle team gjennom den ene bastionen som allerede finnes, og oppdag deretter at sikkerhetsgruppen, rutetabellen og patch-vinduet er produksjonsavhengigheten. Skriv ned hvilken utløser verten tjener, og avvikle den når utløseren forsvinner.

Transit Gateway og flere assosiasjoner endrer regnestykket

Hvis endepunktet er knyttet direkte til en Transit Gateway i stedet for til et subnett, endres modellen: klienter oversettes ikke lenger til en grensesnittadresse i et assosiasjonssubnett, og gateway-rutetabellene må bære klientområdet pluss tilknytningen som fører til den peerete VPC-en. Det er renere i skala, men arbeidet flytter fra fire oppføringer til gateway-rutetabeller.

Flere assosiasjoner multipliserer kontrollene. Endepunkt-ruten tilhører endepunktet, men hvert assosiasjonssubnett trenger en rutetabell med et ekte peering-neste hopp. En økt kan lykkes gjennom én assosiasjon mens en annen ikke har noen returvei, så test hver enkelt.

Verifiseringsrekkefølge som finner bruddet raskt

Kjør disse i rekkefølge; hvert trinn kan bestå mens det neste feiler, og en klienttidsavbrudd sier nesten aldri hvilket som brøt.

1. Slå opp applikasjonsnavnet fra klienten, og kontroller at adressen ligger innenfor peering-området.
2. Koble til, og les deretter endepunktets tilkoblingslogg for assosiasjonen som avsluttet økten.
3. På det assosiasjonssubnettet bekrefter du at rutetabellen peker peering-området mot en aktiv peering-forbindelse.
4. På ressurs-subnettet i B bekrefter du en returoppføring for grensesnittområdet og samsvarende grupperegler.
5. Test én tillatt operasjon og én ressurs som må forbli utilgjengelig; den andre fanger rester av feilsøking.
6. Koble til på nytt etter enhver endring av split-tunnel-ruten, fordi en kjørende tunnel ikke tar inn et nytt rutesett.

To symptomer er verdt å huske. En SYN som når B uten svar er nesten alltid den manglende returruten. En tilkobling som fullføres og deretter tilbakestilles, er vanligvis gruppen, ACL-en eller applikasjonen. Ingen av dem vises i endepunktloggen som årsak, så hold de fire oppføringene med en eier ved hver.

Hvis ingen av de tre utløserne gjelder, fullfør den rutete veien og registrer de fire oppføringene. Hvis én gjelder, behold bastionen bare for den grensen og la endepunkt-ruten være for tjenester som ikke trenger en økt foran seg.