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

Eitt Client VPN-endepunkt kan nå ein VPC som er peera med sin tilknytte VPC, og du treng ikkje ein bastion for å gjere det legitimt. Valet som er verdt å ta, er kvar trafikken skiftar hender: ei endepunkt-rute som landar i assosiasjonssubnettet og kryssar peering-sambandet, eller ein vert i den peerte VPC-en som avsluttar økta. Begge vegar fungerer, og dei feilar på ulike stader, så avgjerda handlar om eigarskap og revisjon, ikkje om kva AWS tillèt. Her er korleis eg vel mellom dei, og dei fire oppføringane som får den ruta vegen til å verke.

To vegar, eitt endepunkt, ulike eigarar

På den ruta vegen når klienttrafikken endepunktet, vert omsett til adressa til Client VPN-nettverksgrensesnittet i assosiasjonssubnettet og forlèt det subnettet over A-til-B-peering-sambandet. VPC B avsluttar inga VPN-økt; det ser vanleg trafikk frå VPC A, og difor peikar returruta på VPC A, ikkje på klientbassenget.

På bastionvegen når klienten fyrst ein vert. Ein bastion i A lèt framleis det siste hoppet krysse peering-sambandet, så du held peering-arbeidet og legg til ei økt. Ein bastion i B treng òg ein veg frå klienten, og når den vegen er den same endepunkt-ruta, har du det ruta designet pluss eitt hopp. Bastionen fjernar berre arbeid når han allereie finst, allereie er godkjend, og det bak han treng ei øktgrense framfor ei nettverksgrense.

Fire oppføringar får den ruta vegen til å verke

AWS dokumenterer dette scenariet på Client VPN how-it-works-sida, og i praksis kjem det ned til fire oppføringar som to eller tre team eig. Områda er illustrative; peering-området må vere unikt, og returområdet må passe planen din.

Rute og løyve er separate kontrollar. Ei korrekt endepunkt-rute utan ei samsvarande autorisasjonsregel gjev klienten ingenting; ei autorisasjonsregel for ein destinasjon endepunktet ikkje kan rute gjev han eit svart hol. Begge må nemne det same området.

Endepunkt-ruta peikar på eit subnett i endepunktet si eiga VPC, aldri på peering-sambandet. VPC-rutetabellane peikar på peering-sambandet, aldri på ein instans eller eit grensesnitt. Å kopiere ein verdi mellom dei to vert lagra utan klage og ruter ingenting.

Fordi assosiasjonssubnettet omset klientkjelda, må B rute tilbake til VPC A, ikkje til klientbassenget. Å sende klientområdet over peering-sambandet ser symmetrisk ut, går gjennom gjennomgangen og feilar stille fordi B aldri ser ein pakke med klientkjelde.

Tryggingsgrupper og den siste meteren løyve

Ruting får pakkar inn i B; B avgjer framleis. For eit aktivt peering-samband i same region kan ei tryggingsgruppe i B referere til gruppa som er brukt på Client VPN-assosiasjonen, noko som held regelen smal og overlever adresseendringar. Der ei gruppereferanse ikkje er mogeleg, lèt assosiasjonssubnettet sitt område eksplisitt i staden for å utvide til 0.0.0.0/0, som gjer ein rute feil om til ein uforklart tidsavbrot.

Kontroller deretter det ruting aldri rører: nettverks-ACL-ar på begge subnett, tillatingslista eller målgruppa til applikasjonen, og DNS. Peering kopierer ikkje private hosta soner, så laptopen kan halde ei fungerande rute til ei adresse han ikkje kan slå opp, og eit peering-samband legg ikkje til tillit til eit sertifikat. Peik endepunktet mot ein resolver som svarar for B, og stadfest deretter at det private namnet og sertifikatet stemmer.

Når bastionen er det ærlege svaret

Eg held tre utløysarar for medvite å velje ein bastion. Den peerte VPC-en høyrer til eit team som ikkje vil leggje til ei returrute for området ditt eller ikkje vil godta ei gruppereferanse. Tilgang må godkjennast eller registrerast per økt, og applikasjonen kan ikkje bere det sjølv. Eller det siste hoppet må bli inne i B fordi tenesta berre vert slått opp der, og TLS-identiteten er fest til eit internt namn.

Ingenting av dette er ein omveg rundt at peering ikkje er transitivt. Ikkje-transitivitet avgrensar kva ressursar i B kan gjere: dei kan ikkje bruke A som transit til ein tredje VPC som A er peera med. Det har aldri tydd at ein VPN-brukar ikkje kan nå ein direkte peera VPC, og ein bastion bygd for å omgå den feillesinga er ein vert som vert patcha utan grunn.

Den motsette feilen kostar meir over tid: press alle team gjennom den eine bastionen som allereie finst, og oppdag deretter at tryggingsgruppa, rutetabellen og patch-vindauget er produksjonsavhengnaden. Skriv ned kva utløysar verten tener, og avvikle han når utløysaren forsvinn.

Transit Gateway og fleire assosiasjonar endrar reknestykket

Viss endepunktet er knytt direkte til ein Transit Gateway i staden for til eit subnett, endrar modellen seg: klientar vert ikkje lenger omsette til ei grensesnittadresse i eit assosiasjonssubnett, og gateway-rutetabellane må bere klientområdet pluss tilknytinga som fører til den peerte VPC-en. Det er reinare i skala, men arbeidet flyttar frå fire oppføringar til gateway-rutetabellar.

Fleire assosiasjonar multipliserer kontrollane. Endepunkt-ruta høyrer til endepunktet, men kvart assosiasjonssubnett treng ein rutetabell med eit ekte peering-neste hopp. Ei økt kan lukkast gjennom éin assosiasjon medan ein annan ikkje har nokon returveg, så test kvar einskild.

Verifiseringsrekkjefølgje som finn brotet raskt

Køyr desse i rekkjefølgje; kvart steg kan bestå medan det neste feilar, og eit klienttidsavbrot seier nesten aldri kva som braut.

1. Slå opp applikasjonsnamnet frå klienten, og kontroller at adressa ligg innanfor peering-området.
2. Kople til, og les deretter tilkoplingsloggen til endepunktet for assosiasjonen som avslutta økta.
3. På det assosiasjonssubnettet stadfestar du at rutetabellen peikar peering-området mot eit aktivt peering-samband.
4. På ressurs-subnettet i B stadfestar du ei returoppføring for grensesnittområdet og samsvarande grupperegler.
5. Test éin tillaten operasjon og éin ressurs som må halde fram med å vere utilgjengeleg; den andre fangar restar av feilsøking.
6. Kople til på nytt etter kvar endring av split-tunnel-ruta, fordi ein køyrande tunnel ikkje tek inn eit nytt rutesett.

To symptom er verdt å hugse. Ein SYN som når B utan svar er nesten alltid den manglande returruta. Ei tilkopling som fullførast og deretter vert nullstilt, er vanlegvis gruppa, ACL-en eller applikasjonen. Ingen av dei viser seg i endepunktloggen som årsak, så hald dei fire oppføringane med ein eigar ved kvar.

Viss ingen av dei tre utløysarane gjeld, fullfør den ruta vegen og registrer dei fire oppføringane. Viss éin gjeld, hald bastionen berre for den grensa og la endepunkt-ruta vere for tenester som ikkje treng ei økt framfor seg.