Cómo leer el enrutamiento DNS de la VPN por enlace desde resolvectl

Ejecute resolvectl status y obtendrá un muro de bloques por enlace, cada uno con sus propios servidores y su propia línea de dominios. La línea que decide el enrutamiento es la lista de dominios, no la dirección del servidor de nombres, porque el stub local reenvía cada consulta al enlace que reclama el nombre. Lea esas reclamaciones antes de leer la respuesta, luego consulte el nombre y compruebe qué enlace lo produjo. Una respuesta incorrecta del enlace correcto es un problema distinto de una respuesta correcta del enlace incorrecto.

Qué le dice cada bloque por enlace

Cada bloque enumera los servidores que el resolutor usará para esa interfaz, la lista de dominios y si el enlace es la ruta predeterminada. La lista de dominios es un conjunto de reclamaciones, y el resolutor aplica la coincidencia del sufijo más largo: una consulta para host.corp.example la reclama un enlace que lleva corp.example antes que uno que solo lleva la ruta predeterminada. Dos enlaces que reclaman el mismo sufijo dejan el resultado a la prioridad y el orden, por eso los duplicados merecen atención primero. La línea del servidor actual muestra cuál de los servidores enumerados se usa en ese momento.

Una dirección stub como 127.0.0.53 en /etc/resolv.conf solo dice que el stub está delante. No nombra el origen que respondió, por eso un diagnóstico basado solo en resolv.conf se atasca.

Lea correctamente los tres tipos de entrada de dominio

La tilde cambia el comportamiento de búsqueda, no el enrutamiento. Una entrada sin tilde es a la vez dominio de enrutamiento y dominio de búsqueda, así que los nombres por debajo se envían a ese enlace y a los nombres de una sola etiqueta se les añade el sufijo. Una entrada con tilde enruta el mismo sufijo pero lo mantiene fuera de la lista de búsqueda. Por eso quitar una tilde cambia qué nombres simples se resuelven, y por eso una tilde ausente es un problema de búsqueda y no un fallo de DNS dividido.

La entrada de ruta predeterminada reclama todo lo que ningún otro enlace cubre. Un perfil de túnel completo normalmente la quiere y un perfil dividido normalmente no, porque entonces los nombres públicos viajan al resolutor privado y pueden fallar allí. Lea la tabla según la intención del perfil en lugar de copiar indicadores entre perfiles. Cuando dos enlaces reclaman el mismo sufijo, resuelva la cuestión de prioridad antes de editar cualquier otra cosa.

Consulte un nombre y vea qué enlace respondió

La suborden query imprime la dirección, el protocolo y el enlace o ámbito que produjo la respuesta. Pruebe un nombre que debería reclamar el sufijo privado y un nombre público corriente, luego compare las fuentes informadas. Si el nombre privado responde desde el enlace inalámbrico, falta la reclamación o el túnel está caído; si un nombre público en un perfil dividido responde desde el túnel, la ruta predeterminada es demasiado amplia. Esos dos fallos se ven idénticos en un navegador y opuestos en esta salida.

resolvectl status
resolvectl query host.corp.example

Vigile también el protocolo informado, porque una respuesta en caché o del archivo de hosts puede llegar sin consultar ningún origen. Una respuesta de la caché demuestra que el nombre se resolvió en algún momento, no que la política actual lo enrute correctamente.

Mantenga el enrutamiento de nombres aparte del enrutamiento de paquetes

Una decisión del resolutor no crea un camino. El servidor elegido todavía necesita una ruta hacia su dirección, y la dirección devuelta todavía necesita una ruta hacia la red privada, así que una política DNS correcta puede coexistir con una conexión que nunca se abre. Cuando un nombre se resuelve y la aplicación falla, inspeccione la dirección y la ruta en lugar de volver a cambiar el DNS. La resolución de nombres y la accesibilidad son dos preguntas con dos propietarios distintos.

Las aplicaciones pueden saltarse por completo el resolutor del sistema mediante su propia configuración de DNS seguro o un resolutor integrado. El resultado de resolvectl describe la ruta del sistema, y un navegador que lo ignore discrepará de cada prueba que haga. Compruebe esa configuración antes de concluir que la política está rota.

Anote la dirección a la que se resolvió el nombre junto al enlace. Un nombre correcto que apunta a la dirección equivocada es un problema de registro, no de enrutamiento.

Vuelva a comprobar después de que cambie el enlace

Una reconexión o un cambio de red inalámbrica reconstruye el estado del enlace, y un gestor de red puede reinstalar sus dominios y servidores sobre todo lo puesto a mano. Consulte después los mismos dos nombres y compare con la línea base registrada. Si una edición manual ha desaparecido, la corrección pertenece al perfil de conexión y no a una orden de shell. Anotar antes y después es lo que hace eso visible.

Comparta solo los nombres y el contexto de servidores que el informe necesita, porque los sufijos internos revelan la topología. La documentación de systemd-resolved sobre enrutamiento de dominios cubre la regla de la coincidencia más larga y el comportamiento de la tilde, y leerla una vez evita la mayoría de los errores de la tabla anterior: enrutamiento de consultas de systemd-resolved.