wg-quick rompe el DNS al conectar: lea el error de configuración

El túnel sube, el saludo se completa y la resolución de nombres se detiene. Nada de la configuración de pares ha cambiado, porque la línea DNS nunca formó parte de esa configuración. Pertenece al ayudante de configuración, lo que significa que el fallo vive en las herramientas del resolutor del host y no en las claves de WireGuard.

Lea el primer mensaje que imprimió el ayudante, no el último, y la diferencia entre una utilidad ausente y un servidor inalcanzable se vuelve obvia.

La línea DNS es una función del ayudante

Los campos básicos de configuración describen pares, claves y direcciones permitidas. La resolución se añade encima por el script que levanta la interfaz, y cada implementación lo hace de forma distinta. Un cliente de escritorio puede gestionar el DNS con su propio servicio, un script de distribución puede llamar a una de varias utilidades de resolutor, y un contenedor puede no hacer ninguna de las dos cosas. El archivo de configuración no puede decirle cuál de esos caminos está en juego.

Por eso un archivo de configuración puede ser válido para el protocolo y aun así fallar durante la configuración: el fallo pertenece a un gancho que el protocolo nunca ve.

Escribir un campo extendido en una configuración básica y esperar que la herramienta del protocolo lo acepte produce la misma confusión desde la dirección opuesta. Los dos analizadores leen archivos distintos.

Saber cuál de los dos se ejecuta es el primer paso de diagnóstico, y normalmente se ve en el comando que escribió, no en el archivo de configuración.

Lea el primer error que imprime el ayudante

Levante la interfaz en primer plano y lea la salida en orden. Una utilidad de resolutor ausente, un gancho fallido y un servidor inalcanzable detienen el mismo comando en puntos distintos, y cada uno tiene una reparación diferente.

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

El primer comando informa del progreso de la configuración, el segundo muestra qué servidores reclama ahora la interfaz, y el tercero muestra si la dirección del resolutor es realmente alcanzable a través del túnel. Un resolutor configurado pero no enrutable produce tiempos de espera en lugar de errores de configuración, por eso las dos comprobaciones van juntas. Leer solo la salida de estado produce una conclusión segura y equivocada.

Si la configuración terminó y la resolución de nombres sigue fallando, compare el resolutor que instaló el ayudante con el que la red usaba antes. Un resolutor privado necesita una ruta a través del túnel, y una configuración que lo lista sin cubrir su prefijo deja cada consulta esperando.

Qué resolutor tiene realmente el host

Los hosts Linux modernos suelen ejecutar un resolutor stub local, así que la dirección que instala el ayudante la consume ese stub y no las aplicaciones directamente. Editar a mano un archivo generado puede parecer que funciona hasta la siguiente reconexión, cuando el ayudante lo reescribe.

Use la integración admitida para la distribución y deje que un solo componente sea dueño del estado del resolutor. Dos dueños producen la misma carrera que dos dueños de una dirección de interfaz, y el síntoma es un host que resuelve bien durante unos minutos después de cada cambio.

Los nombres internos merecen su propia comprobación. Un resolutor público puede restaurar la navegación general mientras hace fallar todos los nombres corporativos, que es lo contrario de aquello para lo que servía el túnel. Consulte el nombre interno en el servidor previsto antes de concluir que el DNS está arreglado.

La limpieza importa tanto como la configuración

Baje la interfaz e inspeccione de nuevo el estado del resolutor. Un ayudante que restaura la configuración anterior deja el host utilizable; uno que deja sus propios servidores atrás crea el siguiente fallo, a menudo horas después, cuando el túnel hace tiempo que no está.

El estado obsoleto es fácil de ver cuando uno lo busca. Una lista de resolutores puede apuntar a una dirección en una interfaz que ya no existe, y un dominio de búsqueda puede sobrevivir a una red que dejó esta mañana. Cualquiera de los dos hace que la próxima conexión se comporte de forma impredecible, y ninguno aparece en la salida de estado del propio túnel. La comprobación tarda diez segundos y ahorra una hora a la siguiente persona.

Mantenga el diagnóstico separado de la reparación. Si falla todo destino, no solo las consultas de nombres, las rutas y el reenvío son los sospechosos y la línea DNS es una distracción. El manual de wg-quick documenta qué campos maneja y cuáles pertenecen al protocolo, y esa frontera es toda la respuesta a la mayoría de estos informes.