Ett plats-till-plats-VPN för flera VPC i AWS Transit Gateway
Anslut VPN:en en gång och varje VPC till en transit gateway, och separera sedan associering från spridning så att spokes når kontoret men inte varandra.
Två VPC behöver kontorsnätverket det här kvartalet, och det är vid den andra tunneln uppskattningen brister. AWS Transit Gateway kan fungera som ett delat routingnav: VPN:en ansluts en gång och varje VPC ansluts till samma nav. Det lokala nätverket når då varje ansluten VPC via en enda förbindelse. Det ändrar vem som äger routingbeslutet, och det är den delen de flesta design gör fel.
VPN-anslutningen och VPC-anslutningarna är separata objekt på samma gateway, därför måste routingrelationerna byggas efteråt.
On-premises network <-> Site-to-Site VPN <-> Transit Gateway
|- VPC A
|- VPC B
Varför peering inte är den genväg folk hoppas på
Det frestande alternativet är att avsluta VPN:en på VPC A och peering-ansluta VPC B till den. Vanlig VPC-peering ger ingen transit från kant till kant genom A:s VPN-anslutning. En peer når bara de adresser som peeringen själv tillhandahåller, och en VPN-kant är inte en av dem. Transit är vad ett nav ger; peering ger dig ett par.
Den begränsningen är en egenskap hos peering, inte en kvot du kan höja.
Associering och spridning gör olika arbete
Inne i transit gatewayen väljer associeringen den routningstabell som används för att slå upp trafik som kommer från en anslutning. Spridningen avgör vilka tabeller som får en anslutnings inlärda eller anslutna prefix. En enda anslutning kan vara associerad med en tabell medan den sprids till flera. Att blanda ihop de två är hur en design slutar med en nåbarhet ingen hade planerat.
Ett fullt sammankopplat litet nav är det enkla fallet.
Sätt varje anslutning i en enda tabell och VPN:en plus båda VPC-prefixen löses rent. Det tillåter också nåbarhet mellan VPC som organisationen kanske aldrig avsåg, eftersom en delad tabell inte känner till begreppet spoke.
Arbetslastarnas rutter bor någon annanstans
Varje arbetslastsubnät behöver fortfarande sin egen rutt mot transit gatewayen för de avsedda lokala prefixen. De VPC-routningstabellerna är separata objekt från transit gatewayens egna tabeller. Lägg till prefixen du behöver och behåll befintliga rutter i stället för att ersätta varje destination med en ny standard. En subnätsrutt annonserar inte heller något till kundenheten.
Välj dynamisk eller statisk routing med avsikt; peering ger ingen av dem.
Isolera spokes utan att förlora lokal åtkomst
När A och B båda får nå kontoret men inte ska routa till varandra, dela tabellerna. Den associerade tabellen för VPN-anslutningen håller VPC-prefixen. Den associerade tabellen för VPC-anslutningarna håller de lokala prefixen, utan en rutt som förbinder A med B. Spridningen skapar den relationen, så du behöver aldrig acceptera varje standardassociering.
Detta är routingisolering, och det är inte applikationsauktorisering.
Säkerhetsgrupper, nätverks-ACL:er, värdars brandväggar och varje tjänsts egna behörigheter avgör fortfarande vilken trafik som släpps in. Om inspektion krävs, designa dess stödda väg explicit i stället för att anta att navet utför den.
Vad navet inte fixar
Adressplaner måste fortfarande vara utan överlappning, eftersom navet inte låter ett prefix identifiera två arbetslaster. Varje VPC-anslutning behöver den Availability Zone-täckning dess arbetslaster förväntar sig. Med BGP måste kundenhetens rutter tillbaka till varje nödvändigt prefix matcha designen och dess importpolicy. En saknad annonsering ser exakt ut som en bruten tunnel.
VPN-anslutningen och transit gatewayen är nu delad infrastruktur.
Planera tunnlarnas redundans, enhetskapacitet, övervakning och underhåll kring alla beroende VPC i stället för att behandla var och en som oberoende ansluten.
Migrering från ett befintligt virtual private gateway-arrangemang förtjänar samma explicita plan. Bygg anslutningarna och policyerna, flytta en kontrollerad arbetslastväg och bekräfta de tillåtna och nekade relationerna innan du avvecklar den gamla vägen. Centralisering hjälper när den ger nätverksteamet en plats att hantera delad anslutning, och skadar när den döljer vem som kan nå vem bakom en enda stor tabell.