Afegiu una subxarxa local a una VPN d’AWS: VGW enfront de Transit Gateway

Una VPN Site-to-Site existent transporta 10.60.0.0/16, una nova xarxa de servei apareix darrere de la mateixa passarel·la local com a 10.70.0.0/16, i algú pregunta si cal un proxy. Normalment no: un camí enrutat pot transportar el prefix, però només si tres coses encaixen, i quines tres depèn de l’arquitectura d’AWS que ja executeu. Una passarel·la privada virtual té una frontera de taula d’encaminament; un transit gateway n’afegeix una segona. Encertar l’anunci i equivocar la taula produeix una sessió que sembla saludable i no lliura res.

Publiqueu un prefix que la passarel·la pugui lliurar de debò

La passarel·la local necessita una ruta cap a la nova xarxa abans que cap anunci tingui sentit. Anunciar 10.70.0.0/16 per BGP diu a AWS on enviar els paquets d’aquest rang; no crea el camí de reenviament local que fa que el rang sigui abastable a l’altre extrem. Confirmeu que la passarel·la té una ruta per al prefix que apunta al dispositiu que el té, i que el dispositiu està configurat per respondre d’aquestes adreces. La política d’exportació i els límits de prefix acceptats són la restricció següent, perquè un prefix que la sessió filtra no arriba mai a AWS.

Mantingueu els agregats i les rutes més específiques deliberats. Els camins solapats que arriben de dues direccions són una decisió de disseny, no un detall que es descobreixi més tard.

Camí u: la frontera de la passarel·la privada virtual

Amb una passarel·la privada virtual, la documentació d’encaminament de l’AWS VPN descriu dos modes de distribució, rutes estàtiques i anuncis BGP, i tots dos depenen de la taula d’encaminament de subxarxa que l’aplicació fa servir realment. La propagació és còmoda quan controleu tot el rang, i una ruta explícita és més fàcil de raonar quan voleu la destinació llistada al costat de l’objectiu. En qualsevol cas, la comprovació és la mateixa: la taula de la subxarxa concreta de l’aplicació conté un camí funcional cap a l’objectiu de la VPN per al prefix nou, i guanya contra qualsevol cosa més específica?

Una sessió BGP saludable demostra que el canal existeix. No diu res sobre si una taula de subxarxa determinada ha consumit la ruta.

Camí dos: el transit gateway afegeix una taula

Un transit gateway divideix aquesta única pregunta en dues. La subxarxa de la VPC ha d’enviar la destinació a l’adjunció del transit gateway, i després la taula d’encaminament del transit gateway ha de seleccionar l’adjunció de la VPN per a aquest mateix prefix. Les decisions d’associació i propagació determinen quines xarxes adjuntes reben la ruta, de manera que un prefix pot estar anunciat correctament per la VPN i tot i així no arribar mai a la VPC la taula de la qual no es va associar mai a la taula d’encaminament correcta.

La fallada habitual és una ruta que existeix en una taula i no en l’altra, amb cada equip convençut que el seu costat és correcte. Quan compareu les dues arquitectures, aquesta frontera extra és tota la diferència: més llocs on mirar i un control més precís de qui rep la ruta.

La propagació de rutes tampoc no concedeix el prefix a cada adjunció. El distribueix a les taules configurades per rebre’l.

El camí de retorn és una decisió de política pròpia

El trànsit que arriba és només la meitat de l’intercanvi. La nova xarxa local necessita una ruta de tornada cap als prefixos d’origen d’AWS a través de la passarel·la correcta, i la política de seguretat dels dos extrems ha de permetre aquest parell d’origen i destinació. Si el túnel negocia un abast de protecció amb selectors de trànsit, el prefix nou ha de ser dins seu, o el paquet es descarta abans que es consulti cap taula d’encaminament.

El solapament d’adreces és l’altra trampa. Els rangs disjunts i amb propietat explícita ho mantenen simple; els rangs solapats volen dir traducció o un redisseny, i cap dels dos no és una variant intercanviable de la mateixa recepta.

Proveu amb un origen a la xarxa nova i una destinació a la subxarxa de l’aplicació, i repetiu-ho en l’altre sentit. Una prova unidireccional només demostra una direcció.

Quan el proxy és de debò la frontera millor

Un proxy guanya el seu lloc quan el requisit és una interfície de servei estreta, quan l’aplicació ja espera aquesta arquitectura o quan el camí de xarxa no es pot fer portar el prefix sense una traducció que no voleu. No és la solució de recanvi per a una entrada de taula d’encaminament que ningú no ha comprovat.

Decidiu en aquest ordre: reenviament local, anunci, frontera de taula, política de retorn. Arregleu la primera que falli i només després pregunteu si el camí enrutat és del tot la resposta correcta.