¿Necesitas DNS dinámico para un servidor VPN doméstico?

El DNS dinámico arregla el nombre, no el camino de entrada. Tres comprobaciones deciden si un nombre de host basta para un servidor VPN doméstico o si la ruta de entrada está rota.

La mayoría de fallos de VPN doméstica que me consultan no son fallos de DNS, y aun así compran primero una suscripción de DNS dinámico. Antes de configurar nada, decide si el nombre de host es la parte que está realmente rota. Un actualizador reescribe un registro cuando la dirección que te dio tu ISP se mueve; no puede abrir un puerto, atravesar el NAT del operador ni hacer que una sesión de WireGuard activa note que su extremo cambió. Tres condiciones deciden si el DNS dinámico es toda la solución o solo una línea de ella.

Condición uno: tu dirección se mueve de verdad

Las direcciones residenciales se mueven por motivos anodinos: el módem resincroniza tras un corte de luz, el ISP reequilibra un grupo, un nuevo arrendamiento llega tras una avería larga. También se mueven poco en algunas líneas, y he visto la misma dirección sobrevivir un año; los planes de empresa suelen incluir una fija. Si nada ha cambiado en doce meses, un solo registro A que editas a mano es un demonio menos que mantener vivo.

Mídelo en vez de suponerlo. Lee la dirección WAN en la página de estado del router y compárala con lo que ve el mundo exterior. Ejecuta esto desde una máquina de la LAN:

curl -fsS https://api.ipify.org; echo

Si los dos valores difieren, algo está traduciendo delante de tu router y ninguna actualización de nombre lo arreglará. Una dirección dentro de 100.64.0.0/10 es el rango compartido para NAT de nivel de operador, y esa es la razón habitual de que un nombre actualizado correctamente siga agotando el tiempo desde fuera.

Condición dos: los clientes vuelven a resolver el nombre

El TTL corto es la parte que la gente se salta. Los resolutores recursivos respetan el TTL del registro, pero las pilas de cliente cachean por separado, y un túnel ya levantado no vuelve a resolver nada. Pon el registro en 60-300 segundos mientras depuras; eso acorta la ventana en la que se sirve una respuesta antigua y no migra una sesión conectada.

OpenVPN vuelve a resolver la línea remote vpn.example.net 1194 cada vez que se reconecta, y resolv-retry infinite lo mantiene reintentando en lugar de salir cuando falla la consulta. En el servidor, float permite que una sesión establecida siga a un par cuya dirección de origen cambió. WireGuard es más directo: wg-quick up resuelve el Endpoint al aplicar la configuración, y el cliente lo resuelve otra vez cuando reconstruye el túnel, así que un handshake que aún funciona contra la dirección antigua sigue funcionando hasta que se detiene.

Esa diferencia marca el plan. Si los clientes conectan a demanda, un cambio de dirección cuesta una reconexión. Si mantienen una sesión abierta durante días, espera que el túnel muera en el siguiente handshake, y haz que el cliente reintente en vez de suponer que se mantiene.

Condición tres: el camino de entrada sigue abierto

El DNS dinámico cambia solo hacia dónde apunta el nombre y nada más. El desvío de puerto en el router, la regla de cortafuegos en el host VPN y el permiso del ISP para los paquetes entrantes deben existir antes de que el registro importe. Fíjate en qué apunta el desvío: si está anclado a una dirección WAN en vez de a la interfaz, un cambio de dirección rompe el desvío en silencio y el registro se lleva la culpa.

Pruébalo desde fuera. Un teléfono con datos móviles y el Wi-Fi apagado es la prueba honesta más barata; un portátil en la misma LAN no lo es. Cuando el nombre resuelve a tu dirección pública y el router no tiene bucle NAT, una prueba interior falla mientras el registro es del todo correcto, y eso manda a la mayoría a editar un registro que nunca estuvo mal.

Qué ejecutar cuando se cumplen las tres

ddclient es el actualizador que menos sorprende para un host pequeño. Una configuración mínima publica la dirección que ve el proveedor, lo que evita el error del doble NAT:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Ejecútalo desde un temporizador de systemd cada pocos minutos en lugar de un bucle de shell, y registra la respuesta del proveedor en vez de suponer éxito. Trata la credencial como una clave, porque decide adónde se envía cada cliente: usa un token de actualización limitado en lugar de una contraseña de cuenta, mantén el archivo en modo 0600 y envía las actualizaciones por HTTPS.

Verifica antes de comprometerte

Una consulta te dice qué ve el resto del mundo e imprime el TTL que tienes que esperar tras un cambio:

dig +noall +answer vpn.example.net @1.1.1.1

Compara esa dirección con la dirección WAN del router. Si coinciden, el nombre hace su trabajo y lo que aún falla es accesibilidad entrante, una clave o un cliente que no ha vuelto a resolver. Si difieren, el actualizador publica la interfaz equivocada, a menudo porque se ejecutaba en el host VPN detrás del router en lugar de en el router mismo.

Mantén una vuelta atrás de un minuto: anota la última dirección que funcionó y el TTL anterior, para poder publicar ambas a mano mientras el proveedor tiene una mala tarde.

Cuando la respuesta es no

Si falla la condición uno o la tres, cambia la decisión y no la configuración. Detrás del NAT del operador, tus opciones prácticas son pedir una dirección pública al ISP, mover el punto de entrada a un VPS pequeño con dirección estable, o usar una capa superpuesta que mantenga su propio encuentro. Si la dirección es fija, sáltate el actualizador: un registro A, un registro AAAA si usas IPv6, el mismo desvío de puerto.

Si la dirección cambia mientras los clientes siguen conectados, el arreglo honesto vive en el cliente: lógica de reconexión e intervalo de reintento, no un actualizador más rápido. Añadir un segundo proveedor solo oculta el intervalo.

Antes de seguir, confirma cuatro cosas en orden:

  • La dirección que publica el actualizador coincide con la dirección WAN del router.
  • El TTL del registro es lo bastante corto para que un cambio aparezca en minutos.
  • El desvío de puerto está atado a la interfaz, no a una dirección fija.
  • Un cliente real se ha reconectado y ha pasado tráfico desde el último cambio.

Si las cuatro se cumplen, deja la configuración tranquila; tu siguiente fallo es una clave o una regla de cortafuegos y no un problema de nombres. Si alguna falla, arregla esa fila antes de añadir otra pieza móvil. RFC 2136 describe el mecanismo de actualización en sí, si quieres ver qué pone el demonio en el cable.

Artículos relacionados