Qué enlace responde: dominios de enrutamiento para el DNS de una VPN de túnel dividido

Mantenga la navegación normal en el enlace local mientras los nombres de la empresa se resuelven mediante el servidor DNS que proporciona el túnel. Desactivar la ruta predeterminada de la VPN le da la primera mitad y deja la segunda sin construir. Lo que sigue es el ajuste que falta, la puntuación que cambia su significado y el único comando que muestra qué enlace respondió realmente. Se presuponen NetworkManager y systemd-resolved en todo el texto, porque esa pareja es donde suele empezar la confusión.

Paso uno: separe la ruta del resolutor

ipv4.never-default responde una pregunta de enrutamiento e impide que NetworkManager instale esta conexión como la ruta de todo el tráfico IPv4. Un dominio de enrutamiento DNS responde otra pregunta: qué servidores de nombres de qué enlace reciben una consulta para un sufijo coincidente. Ninguno implica al otro, y un perfil puede llevar uno durante años mientras le falta el otro. Solo ruta significa que el túnel transporta las subredes de la empresa y su resolutor responde los nombres de la empresa, mientras que todo lo demás queda intacto.

Configure solo la propiedad de ruta y los nombres internos fallan, normalmente con un tiempo de espera que suena a túnel roto. Configure solo el dominio y habrá añadido en silencio un sufijo de búsqueda a cada nombre corto de la máquina. Ambos errores envían el ticket al servidor VPN, que rara vez es la parte equivocada.

Paso dos: añada un dominio solo de enrutamiento al perfil

Supongamos que la conexión se llama corp-vpn, el sufijo de la empresa es internal.example y el resolutor del túnel ya es accesible. Lea primero los valores actuales, porque los comandos de abajo cambian propiedades que ya pueden tener entradas.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Sustituya por su propio nombre de conexión y sufijo, porque los valores de arriba son ilustrativos. El signo más importa más de lo que parece: con él el valor se añade a la lista existente, mientras que sin él la propiedad se reemplaza y dominios no relacionados desaparecen de un perfil que ayer funcionaba. La tilde cambia el comportamiento, no el estilo, y el párrafo de abajo cubre qué selecciona. Mantenga la lectura antes de la escritura, para que la forma de reemplazo nunca le sorprenda.

Una tilde inicial marca un dominio solo de enrutamiento, así que las consultas coincidentes van a los servidores de este enlace y el sufijo no se añade a los nombres cortos. Quite la tilde y la misma cadena también se convierte en sufijo de búsqueda, que es un resultado distinto que la gente rara vez pretende. Ambos ajustes de arriba son IPv4, así que un perfil de pila doble necesita ipv6.never-default y el mismo dominio de enrutamiento en ipv6.dns-search, o el lado IPv6 sigue usando la ruta predeterminada y los nombres internos fallan allí.

Paso tres: pregunte a resolvectl qué enlace respondió

Ejecute resolvectl status y lea los servidores DNS y los dominios de cada enlace, luego ejecute resolvectl query host.internal.example contra un nombre interno real que tenga permiso para consultar. El segundo comando es la única prueba directa de que el dominio de enrutamiento hace su trabajo, porque nombra el enlace que respondió. Un listado de estado por sí solo prueba la configuración; la consulta prueba la resolución.

systemd-resolved elige el dominio de enrutamiento que mejor coincide, así que un dominio más específico en otro enlace aún puede ganar la carrera. Si la consulta vuelve de un enlace que no esperaba, lea las listas de dominios antes de tocar el servidor DNS de la VPN. Un dominio raíz de ~. coincide con todo, y si ya está presente su dominio específico sigue ganando para sus propios nombres mientras el enlace responde mucho más de lo que pidió. Elimine o estreche esa entrada raíz cuando la intención era solo nombres de la empresa.

Si el enlace de la VPN no enumera ningún servidor DNS, el cliente nunca registró uno. Un dominio de enrutamiento sin servidor detrás falla de forma distinta a un dominio ausente, así que arregle primero el registro.

Paso cuatro: cuando el nombre resuelve pero el servicio no

Una respuesta correcta solo prueba que la resolución funcionó, y la aplicación todavía necesita una ruta hacia la dirección que recibió. Esa ruta tiene que sobrevivir a la ruta predeterminada dividida que acaba de configurar, así que compruébela antes de culpar de nuevo al DNS. Luego compruebe la accesibilidad en el puerto del servicio, porque un recurso compartido o un servicio de directorio falla en la resolución, el enrutamiento o la autenticación y produce mensajes muy similares en cada caso. Mantenga esas tres capas separadas al informar del resultado, o la siguiente persona vuelve a comprobar un DNS que ya era correcto.

El cambio de Samba que circula junto a esta pregunta aborda la capa de acceso, no la elección de DNS. Aplicarlo a un fallo de resolución de nombres es como un problema pequeño adquiere un segundo.

Paso cinco: no sustituya el resolutor para arreglar un dominio ausente

El consejo que sobrescribe el archivo del resolutor o instala otro gestor de resolutor resuelve un problema distinto. Son cambios de integración del sistema con sus propios modos de fallo, y ninguno añade un dominio de enrutamiento que nunca se configuró. Determine qué componente posee la resolución de nombres en la máquina antes de sustituirlo, porque en un escritorio con NetworkManager y systemd-resolved esa propiedad ya está definida. Luchar contra ella es como una configuración que funciona se convierte en algo que nadie puede reproducir.

Orden de trabajo: confirme que el túnel proporciona un resolutor, añada el dominio solo de enrutamiento, reconecte mediante los controles del perfil, verifique el enlace que responde y luego pruebe el servicio en su puerto. Esa secuencia deja un resultado que puede entregar a la siguiente persona sin una segunda entrevista.