Een lokaal subnet aan een AWS VPN toevoegen: VGW versus Transit Gateway

Een bestaande Site-to-Site VPN vervoert 10.60.0.0/16, achter dezelfde lokale gateway verschijnt een nieuw servicenetwerk als 10.70.0.0/16, en iemand vraagt of een proxy nodig is. Meestal niet: een gerouteerd pad kan het prefix vervoeren, maar alleen als drie dingen kloppen, en welke drie hangt af van de AWS-architectuur die u al draait. Een virtuele privégateway heeft één routetabelgrens; een transit gateway voegt een tweede toe. De juiste aankondiging bij de verkeerde tabel levert een sessie op die gezond lijkt en niets aflevert.

Publiceer een prefix die de gateway echt kan afleveren

De lokale gateway heeft een doorgaande route naar het nieuwe netwerk nodig voordat enige aankondiging betekenis heeft. Het aankondigen van 10.70.0.0/16 via BGP vertelt AWS waar pakketten voor dat bereik heen moeten; het maakt niet het lokale doorstuurpad dat het bereik aan de andere kant bereikbaar maakt. Bevestig dat de gateway een route voor het prefix heeft die naar het apparaat wijst dat het vasthoudt, en dat het apparaat is geconfigureerd om voor die adressen te antwoorden. Exportbeleid en geaccepteerde prefixlimieten zijn de volgende beperking, want een prefix die de sessie eruit filtert bereikt AWS helemaal niet.

Houd aggregaten en specifiekere routes bewust. Overlappende paden die uit twee richtingen komen zijn een ontwerpbeslissing, geen detail dat je later ontdekt.

Pad één: de grens van de virtuele privégateway

Met een virtuele privégateway beschrijft de AWS VPN-routingdocumentatie twee distributiemodi, statische routes en BGP-aankondigingen, en beide hangen af van de subnet-routetabel die de applicatie werkelijk gebruikt. Propagatie is handig wanneer u het hele bereik beheert, en een expliciete route is gemakkelijker te beredeneren wanneer u de bestemming naast het doel wilt zien. Hoe dan ook is de controle dezelfde: bevat de tabel van het specifieke applicatiesubnet een werkend pad naar het VPN-doel voor het nieuwe prefix, en wint dat van iets specifiekers?

Een gezonde BGP-sessie bewijst dat het kanaal bestaat. Ze zegt niets over de vraag of een bepaalde subnettabel de route heeft overgenomen.

Pad twee: de transit gateway voegt een tabel toe

Een transit gateway splitst die ene vraag in twee. Het VPC-subnet moet de bestemming naar de transit gateway-koppeling sturen, en dan moet de routetabel van de transit gateway de VPN-koppeling voor hetzelfde prefix kiezen. De keuzes voor associatie en propagatie bepalen welke aangesloten netwerken de route ontvangen, dus een prefix kan correct door de VPN worden aangekondigd en toch nooit de VPC bereiken waarvan de tabel nooit aan de juiste routetabel was gekoppeld.

De gebruikelijke fout is een route die in de ene tabel bestaat en niet in de andere, waarbij elk team ervan overtuigd is dat zijn kant klopt. Wanneer u de twee architecturen vergelijkt, is deze extra grens het hele verschil: meer plaatsen om te kijken, en preciezere controle over wie de route krijgt.

Routepropagatie geeft ook niet elke koppeling het prefix. Ze distribueert het naar de tabellen die zijn geconfigureerd om het te ontvangen.

Het retourpad is een eigen beleidsbeslissing

Inkomend verkeer is slechts de helft van de uitwisseling. Het nieuwe lokale netwerk heeft een route terug naar de AWS-bronprefixen via de juiste gateway nodig, en het beveiligingsbeleid aan beide uiteinden moet dat paar van bron en bestemming toestaan. Als de tunnel een beschermingsbereik met verkeersselectors onderhandelt, moet het nieuwe prefix daarbinnen liggen, anders wordt het pakket weggegooid voordat een routetabel wordt geraadpleegd.

Adresoverlap is de andere valkuil. Gescheiden, expliciet eigendom van bereiken houdt dit eenvoudig; overlappende bereiken betekenen vertaling of een herontwerp, en geen van beide is een uitwisselbare variant van hetzelfde recept.

Test met een bron in het nieuwe netwerk en een bestemming in het applicatiesubnet, en herhaal dan in de andere richting. Een eenrichtingstest bewijst één richting.

Wanneer de proxy werkelijk de betere grens is

Een proxy verdient zijn plaats wanneer de eis een smalle service-interface is, wanneer de applicatie die architectuur al verwacht, of wanneer het netwerkpad het prefix niet kan dragen zonder een vertaling die u niet wilt. Het is niet de terugvaloptie voor een routetabelvermelding die niemand heeft gecontroleerd.

Beslis in deze volgorde: lokale doorsturing, aankondiging, tabelgrens, retourbeleid. Repareer de eerste die faalt, en vraag pas daarna of het gerouteerde pad überhaupt het juiste antwoord is.