DNS del endpoint de AWS Client VPN: por qué falla fijar la IP resuelta

La semana pasada dig +short le dio una dirección para el nombre del endpoint de su perfil de AWS Client VPN, y el túnel se conectó. Esta semana el mismo perfil se queda en 'Connecting' en su portátil mientras la copia intacta de un colega sigue funcionando. No se bloqueó nada y el certificado no caducó. Alguien sustituyó el nombre de host del endpoint por esa dirección resuelta, y el servicio ya no responde allí. El nombre exportado es la parte diseñada para sobrevivir a ese cambio.

El nombre de su perfil puede no ser el nombre que se consulta

Los perfiles exportados de Client VPN suelen incluir remote-random-hostname. Con esa opción activada, el cliente crea una etiqueta desechable, la une al nombre del endpoint con un punto y resuelve el nombre combinado. Un registro comodín en la zona del endpoint responde a cualquier etiqueta, por eso un prefijo inventado también se resuelve y por eso el truco pasa desapercibido cuando intenta reproducir la consulta a mano.

Así que cuando pega el nombre del endpoint en un terminal y obtiene una respuesta, ha resuelto un nombre distinto del que usa el cliente al conectarse. Esa discrepancia no es un defecto que corregir en el perfil. La etiqueta se regenera a propósito: la opción impide que las cachés retengan una respuesta obsoleta y nunca identifica su máquina ni su sesión.

Me he encontrado con el caso de compatibilidad en el que un cliente ignora la opción por completo. AWS documenta la solución: conserve el nombre real del endpoint y anteponga una cadena aleatoria más un punto, tratándolo como un patrón de nombres y no como un valor que pegar. Aplicarlo a un cliente antiguo es razonable; codificar la cadena con prefijo como endpoint no lo es.

Por qué una respuesta guardada no puede seguir siendo correcta

AWS gestiona las direcciones del endpoint de Client VPN y cambian con el tiempo, lo que la documentación de buenas prácticas dice sin rodeos. Una respuesta capturada es una instantánea de una resolución. Un perfil que la codifica se convierte en un perfil apuntado a un host dado de baja en cuanto el servicio se mueve, y el fallo rara vez parece DNS: obtiene un tiempo de espera de conexión o un handshake atascado, así que la gente persigue rutas y certificados.

La misma respuesta en /etc/hosts hereda la misma caducidad con un problema añadido. Una entrada hosts sobrevive a reinicios, reexportaciones y arreglos de 'reinstala el cliente', así que el fallo vuelve cada vez que la dirección se mueve. He visto una pasar semanas inofensiva y luego dejar fuera de juego a todas las máquinas que la llevaban mientras las instalaciones nuevas se conectaban con normalidad. Esa división, un grupo fallando y otro bien en la misma cuenta, es la pista más barata que va a obtener.

Delimite bien el alcance de la aleatorización. Ocurre por intento de conexión. Un túnel establecido no vuelve a resolver su endpoint, no cambia de servidor a mitad de sesión y las peticiones individuales de las aplicaciones no eligen cada una un host VPN nuevo. Solo el siguiente intento vuelve a resolver, por eso una sesión que funciona toda la tarde no dice nada sobre mañana por la mañana.

Qué comprueba el servicio cuando sube el túnel

Client VPN exige que la dirección a la que está conectado coincida con una dirección resuelta para el nombre DNS del endpoint. Ese único requisito explica varios fallos que parecen no relacionados: un registro DNS personalizado que apunta a otro sitio, un frontend personalizado que reenvía a la dirección real del endpoint y un perfil reescrito a una dirección cruda. AWS documenta la combinación de registro personalizado y reenvío como un fallo con clientes recientes de AWS. La comprobación es estrecha; no es una sentencia de que todo alias esté prohibido.

Tampoco es una regla general sobre protocolos VPN. Un remote numérico es perfectamente válido en un despliegue normal de OpenVPN, y muchos funcionan así. La restricción viene del arreglo gestionado, no del protocolo que hay debajo.

Lo que convierte relajar la verificación del certificado en el reflejo equivocado. Si un perfil falla tras un cambio de dirección, desactivar la verificación del servidor traslada el error en lugar de arreglar la resolución o el requisito de coincidencia de dirección, y deja un cliente que se fiará de cualquier cosa. Mantenga el CA exportado, la verificación del servidor y los ajustes de autenticación mutua exactamente como llegaron.

Listas de permitidos, salida y DNS privado son tres problemas separados

Una regla de firewall que debe permitir un destino antes de que un portátil se conecte tiene que ver con el receptor exterior. Dé al propietario de la red el nombre del endpoint, el transporte y el puerto configurado, y luego pregunte si su control puede seguir el comportamiento DNS del servicio. Una regla que retiene una dirección capturada es una instantánea con una caducidad no escrita. Si el control solo acepta destinos inmutables, resuelva ese hueco antes del despliegue en lugar de codificar una respuesta en silencio.

Un socio que necesita una dirección de origen fija para peticiones posteriores a la subida del túnel tiene otro requisito: la salida. Lo que observa un sitio web depende de la ruta de la aplicación y de la política de túnel dividido, no de la dirección a la que se conectó el cliente. El tráfico de túnel dividido puede no tocar AWS en absoluto.

El DNS privado dentro del túnel es una tercera capa. El resolutor que se entrega a los clientes responde nombres internos tras la conexión; no puede resolver el endpoint público antes de que exista el túnel. El fallo de resolución del endpoint y el fallo de resolución de una aplicación interna ocurren en fases distintas, y mezclarlos le lleva al registro equivocado.

La familia de direcciones pertenece a la misma lista. Una respuesta IPv4 no dice nada sobre la ruta permitida de un endpoint IPv6 o de doble pila, así que una instantánea tomada en una familia no es evidencia para la otra.

Compruebe una conexión sin fijar nada

Empiece por el perfil tal como se exportó y lea qué pide realmente:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Luego compare tres cosas: el nombre del endpoint que guarda el perfil, la dirección que el cliente informa para un intento nuevo y a qué resuelve el nombre ahora mismo. Un nombre que resuelve solo demuestra que el registro responde; el transporte y la autenticación son aparte, y el endpoint no tiene que responder a un ping. El registro propio del cliente es la única fuente para el elemento central, así que captúrelo durante el intento y no después.

Una dirección que responde hoy es evidencia sobre hoy; el nombre es lo que el servicio mantiene válido. Anote la observación, envíela a quien posea el endpoint y deje el perfil apuntando al nombre.

Dos hábitos que abandonar: desactivar las comprobaciones de certificado para pasar un handshake atascado, y apilar etiquetas delante del nombre del endpoint esperando que una pegue. Una etiqueta resuelve por el registro comodín o el problema está en otro sitio. Si un perfil bien configurado sigue fallando, envíe la consulta exacta y el evento de conexión, no un nombre de host más largo.

Antes de cerrarlo: el perfil sigue llevando el nombre exportado del endpoint, ningún archivo hosts fija la dirección, el remote del registro del cliente coincide con una resolución actual y la regla de firewall nombra el endpoint en lugar de una dirección. Ese es también el estado que hay que entregar a la siguiente persona.