Engadir unha subrede local a unha VPN de AWS: VGW fronte a Transit Gateway

Unha VPN Site-to-Site existente transporta 10.60.0.0/16, unha nova rede de servizo aparece detrás da mesma pasarela local como 10.70.0.0/16, e alguén pregunta se fai falta un proxy. Normalmente non: unha ruta enrutada pode transportar o prefixo, pero só se cadran tres cousas, e cales tres depende da arquitectura de AWS que xa executa. Unha pasarela privada virtual ten un límite de táboa de rutas; un transit gateway engade un segundo. Acertar o anuncio e equivocar a táboa produce unha sesión que parece saudable e non entrega nada.

Publique un prefixo que a pasarela poida entregar de verdade

A pasarela local necesita unha ruta cara á nova rede antes de que calquera anuncio teña sentido. Anunciar 10.70.0.0/16 por BGP dille a AWS onde enviar os paquetes dese rango; non crea a ruta de reenvío local que fai que o rango sexa alcanzable no outro extremo. Confirme que a pasarela ten unha ruta para o prefixo que apunta ao dispositivo que o mantén, e que o dispositivo está configurado para responder por esas direccións. A política de exportación e os límites de prefixos aceptados son a seguinte restrición, porque un prefixo que a sesión filtra non chega nunca a AWS.

Manteña os agregados e as rutas máis específicas deliberados. As rutas solapadas que chegan de dúas direccións son unha decisión de deseño, non un detalle que se descobre despois.

Ruta un: o límite da pasarela privada virtual

Cunha pasarela privada virtual, a documentación de enrutamento de AWS VPN describe dous modos de distribución, rutas estáticas e anuncios BGP, e ambos dependen da táboa de rutas de subrede que a aplicación usa realmente. A propagación é cómoda cando controla todo o rango, e unha ruta explícita é máis doada de razoar cando quere o destino xunto ao obxectivo. En calquera caso, a comprobación é a mesma: a táboa da subrede concreta da aplicación contén unha ruta funcional cara ao obxectivo da VPN para o prefixo novo, e gaña fronte a algo máis específico?

Unha sesión BGP saudable demostra que a canle existe. Non di nada sobre se unha táboa de subrede determinada consumiu a ruta.

Ruta dous: o transit gateway engade unha táboa

Un transit gateway divide esa única pregunta en dúas. A subrede da VPC ten que enviar o destino á conexión do transit gateway, e despois a táboa de rutas do transit gateway ten que seleccionar a conexión da VPN para ese mesmo prefixo. As decisións de asociación e propagación determinan que redes conectadas reciben a ruta, así que un prefixo pode anunciarse correctamente desde a VPN e aínda así non chegar nunca á VPC cuxa táboa nunca se asociou coa táboa de rutas correcta.

O fallo habitual é unha ruta que existe nunha táboa e non na outra, con cada equipo convencido de que o seu lado é correcto. Cando compara as dúas arquitecturas, este límite extra é toda a diferenza: máis sitios onde mirar e un control máis preciso de quen recibe a ruta.

A propagación de rutas tampouco concede o prefixo a cada conexión. Distribúeo ás táboas configuradas para recibilo.

A ruta de retorno é unha decisión de política propia

O tráfico que chega é só a metade do intercambio. A nova rede local necesita unha ruta de volta cara aos prefixos de orixe de AWS a través da pasarela correcta, e a política de seguridade dos dous extremos ten que permitir ese par de orixe e destino. Se o túnel negocia un ámbito de protección con selectores de tráfico, o prefixo novo ten que estar dentro, ou o paquete descártase antes de consultar calquera táboa de rutas.

O solapamento de enderezos é a outra trampa. Os rangos disxuntos e con propiedade explícita manteñen isto simple; os rangos solapados implican tradución ou un redeseño, e ningún dos dous é unha variante intercambiable da mesma receita.

Probe cunha orixe na nova rede e un destino na subrede da aplicación, e repita na outra dirección. Unha proba unidireccional só demostra unha dirección.

Cando o proxy é de verdade o mellor límite

Un proxy gaña o seu sitio cando o requisito é unha interface de servizo estreita, cando a aplicación xa espera esa arquitectura ou cando non se pode facer que a ruta de rede transporte o prefixo sen unha tradución que non quere. Non é a solución de reserva para unha entrada de táboa de rutas que ninguén comprobou.

Decida nesta orde: reenvío local, anuncio, límite de táboa, política de retorno. Arranxe a primeira que falle e só entón pregunte se a ruta enrutada é sequera a resposta correcta.