Én VPN mellem lokationer til flere VPC'er på AWS Transit Gateway

To VPC'er har brug for kontornetværket i dette kvartal, og det er ved den anden tunnel, at estimatet brækker. AWS Transit Gateway kan fungere som et fælles routingknudepunkt: VPN'en tilsluttes én gang, og hver VPC tilsluttes samme knudepunkt. Derefter når det lokale netværk hver tilsluttet VPC gennem én forbindelse. Det ændrer, hvem der ejer routingbeslutningen, og det er den del, de fleste designs får forkert.

VPN-tilslutningen og VPC-tilslutningerne er separate objekter på samme gateway, og derfor skal routingrelationerne bygges bagefter.

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

Hvorfor peering ikke er den genvej, folk håber på

Det fristende alternativ er at afslutte VPN'en på VPC A og peering-forbinde VPC B til den. Almindelig VPC-peering giver ikke transit fra kant til kant gennem A's VPN-forbindelse. En peer når de adresser, som peeringen selv stiller til rådighed, og en VPN-kant er ikke en af dem. Transit er det, et knudepunkt giver; peering giver et par.

Den begrænsning er en egenskab ved peering, ikke en kvote, du kan hæve.

Tilknytning og udbredelse udfører forskelligt arbejde

Inde i transit gatewayen vælger tilknytningen den rutetabel, der bruges til at slå trafik op, som ankommer fra en tilslutning. Udbredelse afgør, hvilke tabeller der modtager en tilslutnings lærte eller forbundne præfikser. En enkelt tilslutning kan tilknyttes én tabel, mens den udbredes til flere. Forveksling af de to er måden, hvorpå et design ender med en rækkevidde, ingen havde planlagt.

Et fuldt forbundet lille knudepunkt er det nemme tilfælde.

Sæt hver tilslutning i én tabel, og VPN'en plus begge VPC-præfikser opløses rent. Det tillader også VPC-til-VPC-rækkevidde, som organisationen måske aldrig havde tænkt sig, fordi en fælles tabel ikke har noget begreb om en spoke.

Arbejdsbelastningers ruter bor andre steder

Hvert arbejdsbelastningssubnet har stadig brug for sin egen rute mod transit gatewayen for de tilsigtede lokale præfikser. De VPC-rutetabeller er separate objekter fra transit gatewayens egne tabeller. Tilføj de præfikser, du har brug for, og bevar eksisterende ruter i stedet for at erstatte hver destination med en ny default. En subnetrute annoncerer heller intet til kundeenheden.

Vælg dynamisk eller statisk routing med vilje; peering leverer ingen af dem.

Isolér spokes uden at miste lokal adgang

Når A og B begge må nå kontoret, men ikke må route til hinanden, skal du dele tabellerne. VPN-tilslutningens tilknyttede tabel holder VPC-præfikserne. VPC-tilslutningernes tilknyttede tabel holder de lokale præfikser uden en rute, der forbinder A med B. Udbredelse skaber den relation, så du behøver aldrig acceptere enhver standardtilknytning.

Det er routingisolering, og det er ikke applikationsautorisation.

Sikkerhedsgrupper, netværks-ACL'er, host-firewalls og hver tjenestes egne tilladelser afgør stadig, hvilken trafik der tillades. Hvis inspektion er påkrævet, skal du designe dens understøttede vej eksplicit i stedet for at antage, at knudepunktet udfører den.

Hvad knudepunktet ikke løser

Adresseplaner skal stadig være ikke-overlappende, fordi knudepunktet ikke lader ét præfiks identificere to arbejdsbelastninger. Hver VPC-tilslutning har brug for den Availability Zone-dækning, dens arbejdsbelastninger forventer. Med BGP skal kundeenhedens ruter tilbage til hvert påkrævet præfiks matche designet og dets importpolitik. En manglende annoncering ser præcis ud som en brækket tunnel.

VPN-forbindelsen og transit gatewayen er nu fælles infrastruktur.

Planlæg tunelredundans, enhedskapacitet, overvågning og vedligeholdelse omkring alle afhængige VPC'er i stedet for at behandle hver enkelt som uafhængigt tilsluttet.

Migrering fra en eksisterende virtual private gateway-ordning fortjener samme eksplicitte plan. Byg tilslutningerne og politikkerne, flyt én kontrolleret arbejdsbelastningsrute, og bekræft de tilladte og afviste relationer, før du nedlægger den gamle rute. Centralisering hjælper, når den giver netværksteamet ét sted at styre fælles forbindelse, og skader, når den skjuler, hvem der må nå hvem, bag én stor tabel.