El nombre de host de la LAN falla por VPN: ¿sufijo, mDNS o zona?

Junto al dispositivo, la impresora responde a un nombre corto y el servidor de archivos responde a un apodo. A través del túnel, ambos nombres caducan mientras sus direcciones siguen funcionando. La ruta hace su trabajo; la ruta de nombres que hacía funcionar esos nombres cortos nunca cruzó el túnel. Tres mecanismos producen ese comportamiento y cada uno necesita una corrección distinta.

Empiece por identificar de qué mecanismo depende el nombre.

Tres tipos de nombre que se comportan de forma distinta

Un nombre de una sola etiqueta como fileserver suele depender de un sufijo de búsqueda DNS que añade el resolutor. Ese sufijo a menudo llega con la concesión DHCP local, así que un cliente remoto que obtiene direccionamiento de la VPN no tiene motivo para conocerlo. Añadir una ruta no entrega el sufijo. El nombre corto simplemente deja de existir como nombre, aunque la dirección que hay detrás sea accesible.

Un nombre que termina en .local normalmente se resuelve mediante DNS multicast en el enlace local, como describe la RFC 6762. El multicast no atraviesa un túnel enrutado salvo que algo lo puentee o lo proxie a propósito, así que el nombre deja de resolverse en el momento en que sale del segmento.

Un nombre de empresa totalmente cualificado pertenece a una zona interna servida por los resolutores de la organización. Ese funciona en remoto cuando la VPN empuja esos resolutores y el cliente está configurado para usarlos. Y localhost es de uso especial según la RFC 6761: se refiere a la máquina que tiene delante, nunca a un servicio remoto.

Lea el resolutor antes de cambiar la ruta

Pregunte qué servidor de nombres respondió y qué sufijo se añadió. La misma consulta a través de resolutores distintos da respuestas distintas, y esa diferencia es la evidencia que necesita.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Si la consulta totalmente cualificada se resuelve pero la corta no, el fallo está en el sufijo, no en el servidor. Si ninguna se resuelve y la dirección funciona, el cliente no está usando el resolutor interno en absoluto. Compare la lista de resolutores con lo que la VPN debería empujar, porque un cliente que conserva su resolutor local para cada consulta nunca verá la zona interna.

Lleve el nombre correcto al cliente

Pida al administrador el nombre de acceso remoto documentado, completo, y úselo en el perfil en lugar de adivinar sufijos. Si el despliegue admite DNS dividido, configure el dominio interno para que lo resuelvan los servidores internos mientras todo lo demás conserva el resolutor local. Empuje el dominio de búsqueda a través de la configuración de la VPN donde el cliente lo admita.

Verifique el resultado en el cliente en lugar de en la puerta de enlace. Un ajuste aplicado en el servidor que nunca llega al cliente no cambia nada.

Mantenga intacta la identidad del certificado

Una prueba basada en la dirección que ignora el error del certificado solo demuestra que el socket se abrió. El certificado del servicio se emite para un nombre, y el cliente seguirá rechazando la discrepancia con razón. Si el certificado solo enumera el nombre interno, use ese nombre y arregle la resolución, u obtenga un certificado que cubra la dirección que pretende usar.

Anote el nombre, el resolutor y el sufijo que produjeron una conexión correcta. Ese registro ahorra a la siguiente persona repetir la solución provisional basada en la dirección que oculta el problema real.