Én VPN mellom lokasjoner for flere VPC-er på AWS Transit Gateway

To VPC-er trenger kontornettverket dette kvartalet, og det er ved den andre tunnelen anslaget brister. AWS Transit Gateway kan fungere som et felles rutingsenter: VPN-en kobles til én gang, og hver VPC kobles til samme senter. Deretter når det lokale nettverket hver tilkoblede VPC gjennom én forbindelse. Det endrer hvem som eier rutingsbeslutningen, og det er den delen de fleste design gjør feil.

VPN-tilkoblingen og VPC-tilkoblingene er separate objekter på samme gateway, derfor må ruterelasjonene bygges etterpå.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Hvorfor peering ikke er den snarveien folk håper på

Det fristende alternativet er å avslutte VPN-en på VPC A og peering-koble VPC B til den. Vanlig VPC-peering gir ikke transitt fra kant til kant gjennom A sin VPN-forbindelse. En peer når bare adressene som peeringen selv tilbyr, og en VPN-kant er ikke en av dem. Transitt er det et senter gir; peering gir deg et par.

Den begrensningen er en egenskap ved peering, ikke en kvote du kan øke.

Tilknytning og spredning gjør ulikt arbeid

Inne i transit gatewayen velger tilknytningen den rutetabellen som brukes til å slå opp trafikk som kommer fra en tilkobling. Spredning avgjør hvilke tabeller som får de lærte eller tilkoblede prefiksene til en tilkobling. Én tilkobling kan være tilknyttet én tabell mens den spres til flere. Å blande de to er måten et design ender med en nåbarhet ingen hadde planlagt.

Et fullt sammenkoblet lite senter er det enkle tilfellet.

Sett hver tilkobling i én tabell, og VPN-en pluss begge VPC-prefiksene løses rent. Det tillater også nåbarhet mellom VPC-er som organisasjonen kanskje aldri mente, fordi en delt tabell ikke kjenner begrepet spoke.

Arbeidsbelastningenes ruter bor andre steder

Hvert arbeidsbelastningssubnett trenger fortsatt sin egen rute mot transit gatewayen for de tiltenkte lokale prefiksene. De VPC-rutetabellene er separate objekter fra transit gatewayens egne tabeller. Legg til prefiksene du trenger og behold eksisterende ruter i stedet for å erstatte hver destinasjon med en ny standard. En subnett-rute annonserer heller ingenting til kundeenheten.

Velg dynamisk eller statisk ruting med vilje; peering gir ingen av dem.

Isoler spokes uten å miste lokal tilgang

Når A og B begge kan nå kontoret men ikke skal rute til hverandre, del tabellene. Den tilknyttede tabellen for VPN-tilkoblingen holder VPC-prefiksene. Den tilknyttede tabellen for VPC-tilkoblingene holder de lokale prefiksene, uten en rute som forbinder A med B. Spredningen skaper den relasjonen, så du trenger aldri å godta hver standardtilknytning.

Dette er ruteisolering, og det er ikke applikasjonsautorisasjon.

Sikkerhetsgrupper, nettverks-ACL-er, vertsbrannmurer og hver tjenestes egne tillatelser avgjør fortsatt hvilken trafikk som slippes inn. Hvis inspeksjon er nødvendig, designer du dens støttede vei eksplisitt i stedet for å anta at senteret gjør det.

Hva senteret ikke fikser

Adresseplaner må fortsatt være uten overlapp, fordi senteret ikke lar ett prefiks identifisere to arbeidsbelastninger. Hver VPC-tilkobling trenger den Availability Zone-dekningen arbeidsbelastningene forventer. Med BGP må kundeenhetens ruter tilbake til hvert påkrevde prefiks samsvare med designet og dets importpolicy. En manglende annonsering ser nøyaktig ut som en brutt tunnel.

VPN-forbindelsen og transit gatewayen er nå felles infrastruktur.

Planlegg tunellredundans, enhetskapasitet, overvåking og vedlikehold rundt alle avhengige VPC-er i stedet for å behandle hver som uavhengig tilkoblet.

Migrering fra en eksisterende virtual private gateway-ordning fortjener samme eksplisitte plan. Bygg tilkoblingene og policyene, flytt én kontrollert arbeidsbelastningsrute, og bekreft de tillatte og avviste relasjonene før du avvikler den gamle ruten. Sentralisering hjelper når den gir nettverksteamet ett sted å administrere felles tilkobling, og skader når den skjuler hvem som kan nå hvem bak én stor tabell.