Anuncios BGP del VGW frente a la tabla de rutas de la VPC: qué cambia qué

Un prefijo ausente en la tabla de rutas de una subred de la VPC y un prefijo ausente en el router del cliente son dos fallos distintos, y solo uno de ellos se repara dentro de las tablas de rutas de AWS. La puerta de enlace privada virtual anuncia los bloques CIDR asociados a su VPC; la tabla de rutas de la subred decide adónde envía una carga de trabajo la respuesta. Tratar el segundo como una forma de cambiar el primero es el giro equivocado más habitual en este diagnóstico. Ejecute las comprobaciones siguientes en orden y mantenga las dos direcciones separadas.

Nombre el adjunto antes de leer cualquier tabla

Una VPN de sitio a sitio termina en una puerta de enlace privada virtual o en una puerta de enlace de tránsito, y los ID de recursos deciden qué modelo de enrutamiento se aplica. Léalos primero: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. La respuesta le dice si la siguiente tabla que debe inspeccionar es una tabla de rutas de VPC o una tabla de rutas de la puerta de enlace de tránsito.

Si la VPN está asociada a una puerta de enlace de tránsito, deje de tratar la tabla de rutas de la VPC como el plano de control. Allí la tabla de la VPC apunta al adjunto de la puerta de enlace, y la asociación y la propagación ocurren en la tabla de rutas de la puerta de enlace de tránsito. Mezclar ambas vistas produce conclusiones seguras sobre el objeto equivocado.

La dirección de AWS a la oficina es un anuncio

Para un adjunto de VGW, la puerta de enlace anuncia los bloques CIDR asociados a su VPC a la puerta de enlace del cliente por BGP. Añadir una ruta de subred individual, o apuntar una ruta a una VPC emparejada o a un dispositivo, no añade otro CIDR asociado ni aparece en ese anuncio. Si a la oficina le falta un prefijo, compare la lista de rutas recibidas con las asociaciones de VPC antes de editar cualquier tabla de rutas.

La regla simple tiene excepciones, así que manténgala dentro de su alcance. Una disposición VPN CloudHub puede volver a anunciar prefijos de sitio entre puertas de enlace de cliente, y una puerta de enlace de tránsito sigue sus propias reglas de propagación. La afirmación de que un VGW solo anuncia su propia VPC es un valor predeterminado útil, no una ley que cubra todas las topologías que encontrará.

La dirección de la oficina a AWS es propagación más selección

En la dirección inversa, el VGW aprende el prefijo de la oficina, pero eso por sí solo no mueve una carga de trabajo. La tabla de rutas de la subred debe tener la propagación habilitada para el adjunto o llevar una ruta estática al mismo destino. Cuando ambas existen para un prefijo, gana la ruta estática, y la coincidencia de prefijo más largo se ejecuta antes que cualquiera de las dos.

Lea el origen en lugar de suponerlo: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Una entrada con origen EnableVgwRoutePropagation vino de BGP; una entrada con origen CreateRoute la escribió una persona y seguirá ganando hasta que alguien la elimine.

Un runbook que mantiene separadas las dos direcciones

Anote cuatro hechos en el lado de AWS antes de cambiar nada: el tipo de adjunto, los CIDR asociados de la VPC, el origen de la ruta de subred para el prefijo en cuestión y el estado del túnel y de BGP. La misma llamada describe devuelve VgwTelemetry con un recuento de rutas aceptadas por túnel, lo que le dice si AWS aceptó alguna ruta. Después compare eso con lo que el dispositivo del cliente instaló realmente. Un prefijo presente en BGP pero ausente de la tabla de reenvío es un problema de importación local o de mejor ruta, no un problema de la tabla de rutas de AWS.

Si a la tabla de la subred le falta por completo el prefijo, habilite la propagación o añada una ruta estática, y luego vuelva a leer la misma consulta tras el intervalo de propagación en lugar de suponer que el cambio fue inmediato. Si el prefijo existe y el tráfico sigue fallando, deje el plano de control en paz y pase a la ruta de datos.

Qué no cambiar mientras esté allí

No active ni desactive la propagación en tablas de rutas no relacionadas para arreglar un prefijo ausente, y no añada una ruta predeterminada para tapar un único CIDR ausente. Ambos cambios amplían el alcance del impacto y dificultan el siguiente diagnóstico. Limite la edición a la tabla que sirve a la subred de carga de trabajo en cuestión.

La ruta de datos es independiente de todo esto. Los grupos de seguridad tienen estado, las ACL de red no, y un cortafuegos de host o una ruta de retorno asimétrica pueden descartar tráfico que el enrutamiento entregó correctamente. Un agregado anunciado tampoco autoriza cada servicio dentro de él, así que restrinja el acceso en el límite de la política en lugar de confiar en que una dirección aparezca por casualidad en un anuncio BGP.

Guarde el antes y el después de cada consulta de tabla de rutas en el registro de cambios. Si el cambio empeora las cosas, restaure las rutas anteriores y confirme con la misma consulta, porque una reversión que no puede verificar solo es una conjetura.