DNS en AWS Client VPN: use el resolver de la VPC, no la subred

El endpoint está en 10.0.8.0/24, así que el resolver debe ser 10.0.8.2. Ese es el razonamiento que más oigo, y es erróneo dos veces. Route 53 Resolver responde en el rango IPv4 principal de la VPC más dos, que para una VPC de 10.0.0.0/16 es 10.0.0.2, sin importar qué subred use el endpoint. El segundo error es más silencioso: poner la dirección correcta en el endpoint no significa que el sistema operativo del cliente le pregunte algo alguna vez. Ambos errores producen el mismo síntoma: la resolución de nombres funciona en algunos clientes y falla en otros.

El mito empieza en la asociación de la subred

La asociación trata de dónde viven las interfaces de red elásticas para las conexiones de clientes, no de qué dirección de resolver existe. Las subredes del endpoint dan a los clientes una dirección dentro de la VPC, y ninguna lleva su propio resolver.

Cuando separa esas dos ideas, la aritmética deja de ser misteriosa y la resolución de problemas pasa al cliente, que es donde acaban realmente la mayoría de estos casos.

Calcule la dirección desde el rango principal de la VPC

Tome el CIDR IPv4 principal de la VPC y sume dos a la dirección de red. 10.0.0.0/16 da 10.0.0.2, 172.31.0.0/16 da 172.31.0.2, y una VPC con un rango secundario mantiene el resolver en el principal. Una subred de 10.0.8.0/24 dentro de esa VPC no lo mueve. Anote la dirección junto al ID de la VPC antes de tocar el endpoint, porque el número es una propiedad de la VPC y no de la conexión.

La VPC también responde en la dirección link-local 169.254.169.253. Esa dirección es alcanzable desde dentro de la VPC, pero no es un destino enrutado de uso general para un portátil al otro extremo de un túnel.

Así que hay dos direcciones de resolver válidas, y ninguna de ellas es la subred más dos.

Qué hace y qué no hace el ajuste del endpoint

El endpoint de Client VPN tiene campos de servidor DNS, y donde la consola ofrece una opción de resolver de la VPC rellena la misma idea. Configurarlos cambia lo que el servicio entrega a los clientes durante el establecimiento de la conexión. No cambia lo que hace un cliente OpenVPN no gestionado con ese valor, porque el cliente aún debe aplicarlo al sistema operativo. De esa brecha viene «funciona en mi Mac pero no en la máquina Linux».

En Linux, la integración del resolver es propiedad del gestor de conexiones y no del usuario. Editar /etc/resolv.conf a mano demuestra que la dirección funciona para una sesión y luego desaparece al reconectar, por eso tantos casos arreglados vuelven a la mañana siguiente.

Revise el resolver activo en el cliente después de conectar, no la página de configuración del endpoint.

El tunneling dividido puede anular un resolver correcto

Con tunneling dividido solo se usan las rutas enviadas al túnel. Si la dirección del resolver no está cubierta por una ruta, la consulta sale por la interfaz local y la responde su router doméstico. La dirección del endpoint sigue siendo correcta y la búsqueda sigue fallando. Añada la ruta para el resolver y vuelva a probar.

Los rangos locales solapados producen el mismo resultado de forma más desagradable: la consulta recibe respuesta, pero del servidor equivocado.

No abra grupos de seguridad para la dirección de Amazon DNS

El instinto cuando las consultas agotan el tiempo es añadir una regla que permita UDP 53 hacia la dirección del resolver. AWS documenta que los grupos de seguridad y las ACL de red no filtran el tráfico de Amazon DNS como filtran el tráfico hacia una instancia DNS propia. Abrir esas reglas no cambia nada para el resolver de la VPC y amplía el perímetro sin motivo. Un resolver que usted mismo opera es otro caso y sí necesita sus propias reglas.

Si ambos aparecen en su diseño, compruebe a cuál apunta realmente el cliente antes de editar cualquier regla.

Verifique la ruta y luego mida otra cosa

Resuelva un nombre público, resuelva un nombre privado registrado en una zona alojada privada asociada a la VPC y lea el resolver activo del cliente entre ambos. Esa secuencia separa «la dirección del resolver es incorrecta» de «la zona no está asociada» y de «el cliente ignoró el ajuste». Cada uno tiene una solución distinta y ninguno es un problema de rendimiento.

Una búsqueda correcta no dice nada sobre la velocidad sostenida de transferencia, así que mantenga esas dos conversaciones separadas al informar.