La VPN termina en una instancia de EC2, usted puede llegar a la dirección de túnel de esa instancia, y el tráfico que debía pasar por ella hacia otro host privado desaparece. Son dos pruebas distintas, y mezclarlas hace perder horas. La primera pregunta si puede llegar a la instancia; la segunda pide que reenvíe tráfico para un destino que no es el suyo, lo que necesita reenvío de Linux, una política de cortafuegos, una ruta en el lado remoto y un permiso a nivel de AWS que no tiene nada que ver con el sistema operativo invitado. Nada en la consola llama la atención sobre esa diferencia. El síntoma parece una falla de enrutamiento, y normalmente no lo es.

Separe las dos pruebas antes de cambiar nada

Llegar a la puerta de enlace demuestra el túnel, la ruta hacia su dirección y el grupo de seguridad que permite el intercambio. El reenvío para otro host no demuestra nada de eso: usa una dirección de origen distinta, un destino distinto y una instancia en un papel para el que no se construyó necesariamente. Escriba las dos pruebas por separado y anote cuál falla, porque la corrección de cada una vive en una consola distinta. Una instancia de puerta de enlace creada solo para terminar túneles no tiene motivo para reenviar nada más, y sus valores predeterminados lo reflejan. Por eso la segunda prueba necesita su propia configuración en lugar de un pequeño ajuste de la primera.

Un ping que funciona hacia la puerta de enlace y un ping que falla hacia el host que está más allá no es un problema intermitente. Es el comportamiento esperado de una instancia a la que no se le ha dicho que puede reenviar.

Escriba el camino antes de tocar un ajuste

Anote el prefijo del cliente, la instancia o interfaz de red de reenvío, la subred de destino y la ruta de respuesta. Una entrada de la tabla de rutas de la VPC que apunta a una instancia no configura el sistema operativo de la instancia para reenviar, y un núcleo invitado con el reenvío habilitado no crea una ruta de la VPC. Ambos extremos de esa relación deben existir, y se editan en lugares distintos por personas con accesos distintos.

Después revise el ajuste de comprobación de origen/destino en el componente de reenvío real, no en cada instancia de la VPC. AWS documenta por qué una instancia que reenvía tráfico para otros necesita esa comprobación desactivada, y también por qué el ajuste es una decisión por instancia y no un valor predeterminado de toda la VPC.

Cuatro fronteras, y la comprobación es solo una de ellas

Trate el camino como cuatro preguntas y respóndalas en orden. La primera respuesta que falla es donde está el trabajo, y ninguna de las otras la compensará.

BoundaryQuestion it answers
VPC route tablesDo the destinations and replies select the intended gateway?
Forwarding instanceDo the AWS check and the guest OS both permit forwarding?
Access policyDo security groups, ACLs and host rules allow the exchange?
DestinationCan the service accept that source and return a reply?

El orden importa porque comprobarlo es barato: las rutas se ven en una página, la comprobación es un solo atributo, y la opinión del destino suele ser lo último que alguien pregunta.

La traducción cambia qué origen ve el destino

Un diseño enrutado conserva la dirección de origen del cliente, así que el destino necesita una ruta de retorno al prefijo del cliente. Un diseño traducido presenta en cambio la dirección de la puerta de enlace, lo que elimina ese requisito y lo sustituye por una tabla de estados en la puerta de enlace. Decida según la arquitectura que pretende, en lugar de añadir traducción porque un ejemplo no relacionado la usó y pareció funcionar.

Si traduce, limite la regla al prefijo del cliente y al destino previsto. Si conserva, confirme que el lado remoto realmente conoce la ruta en lugar de suponer que aprenderá una.

Pruebe desde el cliente original y luego conserve el cambio

Una solicitud generada en la puerta de enlace puede tener éxito mientras una solicitud reenviada falla, porque es un origen distinto y un caso de reenvío distinto. Tras una corrección dirigida, repita la prueba exacta de cliente a recurso que falló, desde el mismo cliente, y confirme que la respuesta vuelve y no solo que la solicitud llegó.

Por último, ponga el ajuste en la configuración gestionada de la puerta de enlace para que una instancia de reemplazo lo reciba. Una prueba correcta que depende de una excepción manual es una prueba que caduca en la próxima reconstrucción, y la persona que la descubrió no estará allí para recordar por qué.

Artículos relacionados