El servidor de nombres de la VPN acaba siempre por debajo del de la LAN, y editar /etc/resolv.conf lo arregla durante unos minutos. Ese archivo se genera, así que la solución nunca sobrevive. En resolvconf de Debian la entrada de ordenación es /etc/resolvconf/interface-order, y ordena nombres de registro en lugar de direcciones DNS. Confirme qué pila de resolución manda realmente antes de tocar cualquiera de los dos archivos.

Confirme que resolvconf es dueño de la salida

Empiece preguntando qué escribió el archivo actual y qué volverá a escribirlo. El paquete resolvconf se describe como un marco para la configuración dinámica del resolutor, y un equipo que ejecute systemd-resolved o un resolutor gestionado por NetworkManager puede parecer igual desde fuera mientras usa una política completamente distinta.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

Si la ruta resuelta no lleva al directorio de ejecución de resolvconf, deténgase aquí: este manual pertenece a otra pila.

Solo después de esa comprobación vale la pena listar los registros que resolvconf mantiene ahora.

Lea los registros antes de escribir patrones

interface-order coincide con los nombres de los registros del proveedor, no con direcciones ni con nombres de interfaz del núcleo. Enumere lo que está registrado para que sus patrones se refieran a entradas que existen.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

Un nombre de registro suele llevar un sufijo que identifica a su proveedor, así que un registro de túnel y un registro DHCP pueden compartir un prefijo de interfaz y aun así ordenarse distinto. Copie los nombres exactos del listado del directorio. No deduzca un nombre a partir del nombre de la interfaz, porque la integración del cliente decide qué registra. Un nombre que invente nunca coincidirá, y el registro caerá en el patrón que lo atrapa todo sin ningún mensaje de error.

Escriba el orden como patrones de primera coincidencia

El archivo es una lista de patrones glob de shell, uno por línea. Un registro toma la posición del primer patrón con el que coincide, así que un patrón amplio por encima de uno concreto hace inalcanzable la línea concreta.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Ponga el patrón concreto del túnel por encima del patrón que lo atrapa todo y por encima del patrón de la interfaz física.

Mantenga las demás líneas que el archivo ya tenía. Sustituir toda la política por un ejemplo es como los proveedores no relacionados se mueven en silencio; cambie una línea, regenere y compare. Los patrones no pueden contener espacios, barras inclinadas ni un punto o una tilde iniciales, y las líneas vacías y los comentarios con almohadilla se ignoran.

Regenere y verifique el resultado

El orden se aplica cuando los scripts de actualización reconstruyen el archivo. Active la ruta de actualización admitida en lugar de editar la salida generada, y después lea lo que el resolutor recibió realmente.

resolvconf -u
cat /etc/resolv.conf

Verifique dos consultas, no una: un nombre privado que debería resolverse por el túnel y un nombre de control público. Si el nombre privado sigue fallando mientras el orden parece correcto, el problema es el enrutamiento del espacio de nombres y no la prioridad de los registros, y ninguna reordenación lo arreglará. Compare cada respuesta con el servidor que la devolvió, no solo con el éxito. Un nombre privado respondido por el resolutor equivocado sigue siendo un fallo, y para el usuario parece una caída del DNS.

Retire el registro obsoleto en lugar de degradarlo

Un registro VPN obsoleto que reaparece tras desconectar es un error de ciclo de vida en la integración del cliente. Moverlo al final oculta el síntoma y deja un resolutor muerto en la lista.

Retírelo a través del componente que lo registra y después confirme que el directorio de registros ya no lo lista.

Anote el nombre del proveedor, el patrón que cambió y las dos consultas que ejecutó. La siguiente persona necesita más esos nombres que la historia.

Artículos relacionados