Lägga till ett lokalt subnät i en AWS VPN: VGW kontra Transit Gateway

En befintlig Site-to-Site VPN transporterar 10.60.0.0/16, ett nytt tjänstenätverk dyker upp bakom samma lokala gateway som 10.70.0.0/16, och någon frågar om en proxy behövs. Oftast inte: en routad väg kan bära prefixet, men bara om tre saker stämmer, och vilka tre beror på den AWS-arkitektur du redan kör. En virtuell privat gateway har en routetabellgräns; en transit gateway lägger till en andra. Rätt annons och fel tabell ger en session som ser frisk ut och inte levererar något.

Annonsera ett prefix som gatewayen faktiskt kan leverera

Den lokala gatewayen behöver en vidare väg till det nya nätet innan någon annons är meningsfull. Att annonsera 10.70.0.0/16 via BGP berättar för AWS vart paket för det intervallet ska skickas; det skapar inte den lokala vidarebefordringsvägen som gör intervallet nåbart i andra änden. Bekräfta att gatewayen har en rutt för prefixet som pekar på enheten som håller det, och att enheten är konfigurerad att svara för dessa adresser. Exportpolicy och accepterade prefixgränser är nästa begränsning, eftersom ett prefix som sessionen filtrerar bort aldrig når AWS.

Håll aggregat och mer specifika rutter medvetna. Överlappande vägar som kommer från två håll är ett designbeslut, inte en detalj man upptäcker senare.

Väg ett: gränsen för den virtuella privata gatewayen

Med en virtuell privat gateway beskriver AWS VPN-dokumentationen för routing två distributionslägen, statiska rutter och BGP-annonser, och båda beror på subnätets routetabell som applikationen faktiskt använder. Propagering är praktiskt när du kontrollerar hela intervallet, och en explicit rutt är lättare att resonera kring när du vill ha destinationen listad bredvid målet. Oavsett är kontrollen densamma: innehåller tabellen för det specifika applikationssubnätet en fungerande väg till VPN-målet för det nya prefixet, och vinner den mot något mer specifikt?

En frisk BGP-session bevisar att kanalen finns. Den säger inget om huruvida en viss subnättabell har tagit upp rutten.

Väg två: transit gateway lägger till en tabell

En transit gateway delar den enda frågan i två. VPC-subnätet måste skicka destinationen till transit gateway-anslutningen, och sedan måste transit gateway-routetabellen välja VPN-anslutningen för samma prefix. Valen för associering och propagering avgör vilka anslutna nät som får rutten, så ett prefix kan annonseras korrekt av VPN:en och ändå aldrig nå den VPC vars tabell aldrig associerades med rätt routetabell.

Det vanliga felet är en rutt som finns i den ena tabellen och inte i den andra, där varje team är övertygat om att deras sida är korrekt. När du jämför de två arkitekturerna är denna extra gräns hela skillnaden: fler ställen att titta på, och mer exakt kontroll över vem som får rutten.

Ruttspridning ger inte heller varje anslutning prefixet. Den distribuerar det till tabellerna som är konfigurerade att ta emot det.

Returvägen är ett eget policybeslut

Trafiken som anländer är bara halva utbytet. Det nya lokala nätet behöver en väg tillbaka till AWS-källprefixen genom rätt gateway, och säkerhetspolicyn i båda ändar måste tillåta det paret av källa och destination. Om tunneln förhandlar ett skyddsområde med trafikväljare måste det nya prefixet ligga inom det, annars kastas paketet innan någon routetabell konsulteras.

Adressöverlapp är den andra fällan. Åtskilda, uttryckligen ägda intervall håller detta enkelt; överlappande intervall innebär översättning eller en ny design, och ingen av dem är en utbytbar variant av samma recept.

Testa med en källa i det nya nätet och en destination i applikationssubnätet, och upprepa sedan i den andra riktningen. Ett enkelriktat test bevisar bara en riktning.

När proxyn verkligen är den bättre gränsen

En proxy förtjänar sin plats när kravet är ett smalt tjänstegränssnitt, när applikationen redan förväntar sig den arkitekturen, eller när nätvägen inte kan fås att bära prefixet utan en översättning du inte vill ha. Den är inte reservlösningen för en routetabellpost som ingen har kontrollerat.

Bestäm i denna ordning: lokal vidarebefordran, annons, tabellgräns, returpolicy. Åtgärda den första som misslyckas, och fråga först då om den routade vägen alls är rätt svar.