El montaje CIFS falla por VPN por el orden de nsswitch

El túnel está arriba. El servidor de archivos responde a un ping por dirección. Luego mount.cifs con el nombre de host se queda ahí un rato e informa de que el host no es accesible, y usted empieza a rehacer un perfil de VPN que nunca fue el problema. En Linux, glibc resuelve el nombre antes de que exista ningún paquete SMB, y el orden de ese resolutor puede terminar la consulta antes de que se pregunte a DNS. Este es el recorrido que hago, empezando por el comando que falló y no por el cliente.

Lea el fallo en el lugar correcto

Dos herramientas usan caminos distintos hacia el mismo nombre, y compararlas cuesta un comando. getent recorre la pila de servicios de nombres configurada; host y dig consultan DNS directamente e ignoran esa pila. Si la consulta directa devuelve una dirección y getent no devuelve nada, el servidor DNS es accesible y lo que falla es su configuración del resolutor.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

El tercer comando es el que decide: fuerza la fuente DNS y salta el resto de la pila. Cuando ese funciona y el getent simple no, ha demostrado que la culpa es del orden, no del túnel ni del servidor.

La línea hosts es una secuencia que se detiene pronto

El resolutor de glibc lee /etc/nsswitch.conf y recorre la entrada hosts: de izquierda a derecha. Muchas distribuciones traen una línea en la que la consulta multicast va primero con una acción de retorno temprano enganchada. La acción no es decoración: cuando mDNS responde “not found”, [NOTFOUND=return] termina toda la consulta, así que el nombre corporativo nunca se envía al resolutor que ha empujado la VPN. Nada lo registra, porque no se envió ninguna consulta que el resolutor pudiera rechazar. Por eso el montaje parece colgarse y luego informa de un host inaccesible.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

Ponga DNS antes de la acción de retorno temprano en lugar de borrar mDNS, y cámbielo mediante gestión de configuración. Una edición manual sobrevive hasta la siguiente compilación de la imagen, y entonces la misma incidencia llega desde otra máquina que no recuerda la corrección.

Un resolutor no es un dominio de búsqueda

La resolución también necesita que el nombre se pruebe. Un nombre sin calificar como fileserver solo se convierte en fileserver.corp.example cuando se adjunta un dominio de búsqueda a la interfaz que lleva la consulta. Una VPN que empuja un servidor DNS sin lista de búsqueda produce una división muy concreta: el nombre totalmente cualificado se resuelve y todos los nombres cortos fallan.

Pruebe las dos formas antes de editar el perfil, porque los dos fallos apuntan en direcciones distintas. En un host con systemd-resolved el enlace del túnel tiene sus propios servidores y dominios de enrutamiento, así que lea el enlace y no el archivo global.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Si la consulta se atribuye a un enlace que no lleva el túnel, falta el dominio de enrutamiento aunque la dirección DNS esté presente. Es un problema de política en la configuración de resolved, no un problema de enrutamiento en el túnel.

Los contenedores llevan su propia copia de la respuesta

Un contenedor construido a partir de una imagen genérica suele traer un resolv.conf fijo. Los cambios de resolutor hechos en el host no llegan hasta él, ni tampoco el dominio de búsqueda, así que un trabajo de compilación que monta un recurso por el túnel falla mientras el mismo comando funciona fuera del contenedor. Dé al contenedor sus propios ajustes de DNS y de búsqueda en el archivo compose o en los argumentos de ejecución, no solo en el perfil del host.

Compruebe dentro del contenedor antes de culpar a la imagen. Dos comandos reproducen todo el diagnóstico en unos segundos, y el segundo demuestra qué resolutor respondió realmente.

Solo entonces mire el recurso y el filtro

Una vez que el nombre se resuelve, los fallos restantes son de red ordinarios. SMB necesita TCP 445 hacia el servidor, y navegar por una lista de grupo de trabajo depende de servicios de nombres que la VPN probablemente no reenvía. Asigne por nombre de host en lugar de esperar a que se llene una lista, y deje que el cliente le diga a qué etapa llegó. Una conexión rechazada y un silencio por tiempo de espera también merecen separarse, porque la primera suele significar que algo respondió y el segundo que no respondió nada.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Una dirección resuelta con el puerto 445 rechazado o agotado es un problema de cortafuegos o de escucha en el otro lado. Un nombre sin resolver es el problema del resolutor. Y un montaje que se autentica pero devuelve errores de permisos no es ninguna de las dos cosas, así que no reabra la cuestión de red cuando la sesión ya está establecida.

Mantenga la conclusión tan estrecha como la evidencia. Cuando la dirección funciona y el nombre no, el túnel hace su trabajo y la corrección pertenece al orden del resolutor, al dominio de búsqueda o a la configuración propia del contenedor.