Una Elastic IP de EC2 no es la dirección VPN privada de la instancia

La instancia tiene una dirección privada, la Elastic IP está asociada a ella y se añade una ruta para ese /32 público a la VPN con la esperanza de que ambos se conviertan en lo mismo. No lo hacen. Una Elastic IP es una traducción realizada fuera del invitado, por la puerta de enlace de internet, sobre el tráfico que toma la ruta de internet. El sistema operativo del invitado nunca ve esa dirección configurada en una interfaz. Añadirla a una interfaz de túnel no reproduce la traducción aguas arriba y crea una segunda identidad, en conflicto, para la misma máquina.

Dos direcciones, una instancia

La interfaz de red de la instancia tiene una dirección privada dentro de la VPC, y esa es la dirección que conoce el invitado. La Elastic IP está asociada a la misma interfaz, pero vive en el lado público de la asignación.

Todo lo que llega a la instancia por internet llega traducido a la dirección privada. Todo lo que la instancia envía a internet sale con la Elastic IP como origen, de nuevo por esa traducción.

Dentro del invitado existe una dirección. Fuera existen dos. Esa asimetría explica la mayor parte de la confusión en este terreno. El invitado no puede configurar lo que traduce la puerta de enlace. Solo puede responder en la dirección que realmente tiene.

Qué hace realmente la puerta de enlace de internet

La documentación de AWS sobre la puerta de enlace de internet describe el arreglo: la instancia conoce su dirección IPv4 privada y la puerta de enlace proporciona la traducción correspondiente a IPv4 pública o Elastic IP para el tráfico de la ruta de internet.

Eso es traducción de direcciones de red, no un alias. La asignación la mantiene la puerta de enlace, está ligada a la asociación y solo se aplica a los paquetes que la atraviesan. Quite la asociación y la identidad pública desaparece sin que el invitado note nada.

Por eso un paquete VPN privado dirigido al /32 público no se reinterpreta como un paquete privado hacia la dirección local del invitado. El paquete sigue la ruta con la que coincide, que lo envía a la puerta de enlace de internet, y el comportamiento de la puerta de enlace depende de que la ruta esté permitida en ambos sentidos.

Por qué falla el truco de la interfaz de túnel

Asignar la Elastic IP a una interfaz de túnel pide al invitado que trate una dirección pública como local. Ahora dos cosas reclaman la misma dirección: la traducción de la puerta de enlace en la ruta de internet y la interfaz local dentro del túnel. El tráfico de retorno no tiene una respuesta coherente sobre cuál se aplica.

Incluso cuando parece funcionar, el diseño ha ocultado la verdadera pregunta. Los clientes o llegan a la dirección privada por el túnel o llegan al punto final público por internet, y las dos rutas tienen grupos de seguridad distintos, registro distinto y modos de fallo distintos.

La dirección nunca fue el problema. La selección de ruta sí.

Tres objetivos, tres diseños

Si el objetivo es un punto final VPN público, la Elastic IP es la herramienta correcta: los pares remotos se conectan a ella por internet y el transporte cifrado termina en la instancia. El tráfico interno de la aplicación usa después la dirección privada.

Si el objetivo es el acceso privado a la aplicación, el destino es la dirección privada o un nombre DNS privado que resuelva a ella, y la ruta VPN, el grupo de seguridad y la ruta de retorno deben coincidir todos. La Elastic IP no aparece en ese diseño en absoluto.

Si el objetivo es una identidad de salida pública estable para los usuarios de VPN, eso es un diseño NAT en el lado de salida, no una dirección en el túnel del cliente. Tres objetivos que suenan parecidos producen tres diagramas distintos, y solo uno implica poner una Elastic IP en un lugar nuevo.

Verifique la ruta que eligió

Para el acceso privado, confirme que la ruta VPN cubre el prefijo privado, que la tabla de rutas de la VPC devuelve el tráfico al túnel, que el grupo de seguridad permite el origen del cliente y que el cortafuegos propio del cliente permite la respuesta. Luego pruebe una petición real en lugar de un ping.

Para el acceso público, confirme la salida a internet del cliente, el enrutamiento de la entrada pública y su política de seguridad. Que un cliente VPN pueda llegar a un punto final público por el túnel depende de las reglas de salida y del cortafuegos del túnel, no de la asociación de la Elastic IP.

Si un nombre de host público tiene que funcionar desde ambos lados, use un diseño DNS que responda con la dirección privada para los clientes VPN y la dirección pública para todos los demás, y mantenga el certificado válido para el nombre en lugar de para la dirección. Orden de trabajo: nombre el objetivo, elija la dirección que le pertenece y luego verifique rutas, política y una petición.