O teu montaxe CIFS falla por VPN pola orde de nsswitch

O túnel está arriba. O servidor de ficheiros responde a un ping por enderezo. Despois mount.cifs co nome de host queda alí un intre e informa de que o host non é accesible, e ti comezas a refacer un perfil de VPN que nunca foi o problema. En Linux, glibc resolve o nome antes de que exista ningún paquete SMB, e a orde nese resolutor pode rematar a consulta antes de que se pregunte a DNS. Este é o percorrido que fago, comezando polo comando que fallou e non polo cliente.

Le o fallo no lugar correcto

Dúas ferramentas usan camiños distintos cara ao mesmo nome, e comparalas custa un comando. getent percorre a pila de servizos de nomes configurada; host e dig consultan DNS directamente e ignoran esa pila. Se a consulta directa devolve un enderezo e getent non devolve nada, o servidor DNS é accesible e o que falla é a túa configuración do resolutor.

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

O terceiro comando é o que decide: forza a fonte DNS e salta o resto da pila. Cando ese funciona e o getent simple non, demostraches que a culpa é da orde, non do túnel nin do servidor.

A liña hosts é unha secuencia que se detén cedo

O resolutor de glibc le /etc/nsswitch.conf e percorre a entrada hosts: de esquerda a dereita. Moitas distribucións traen unha liña na que a consulta multicast vai primeiro cunha acción de retorno temperán enganchada. A acción non é decoración: cando mDNS responde “not found”, [NOTFOUND=return] remata toda a consulta, así que o nome corporativo nunca se envía ao resolutor que empuxou a VPN. Nada o rexistra, porque non se enviou ningunha consulta que o resolutor puidese rexeitar. Por iso o montaxe parece colgarse e despois informa dun 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

Pon DNS antes da acción de retorno temperán en lugar de borrar mDNS, e cambiaa mediante xestión de configuración. Unha edición manual sobrevive ata a seguinte compilación da imaxe, e entón o mesmo ticket chega desde outra máquina que non lembra a corrección.

Un resolutor non é un dominio de busca

A resolución tamén necesita que o nome se probe. Un nome sen cualificar como fileserver só se converte en fileserver.corp.example cando se engade un dominio de busca á interface que leva a consulta. Unha VPN que empuxa un servidor DNS sen lista de busca produce unha división moi concreta: o nome totalmente cualificado resólvese e todos os nomes curtos fallan.

Proba as dúas formas antes de editar o perfil, porque os dous fallos apuntan en direccións distintas. Nun host con systemd-resolved a ligazón do túnel ten os seus propios servidores e dominios de encamiñamento, así que le a ligazón e non o ficheiro global.

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

Se a consulta se atribúe a unha ligazón que non leva o túnel, falta o dominio de encamiñamento aínda que o enderezo DNS estea presente. É un problema de política na configuración de resolved, non un problema de encamiñamento no túnel.

Os contedores levan a súa propia copia da resposta

Un contedor construído a partir dunha imaxe xenérica adoita traer un resolv.conf fixo. Os cambios de resolutor feitos no host non chegan a el, nin tampouco o dominio de busca, así que un traballo de compilación que monta un recurso pola VPN falla mentres o mesmo comando funciona fóra do contedor. Dálle ao contedor os seus propios axustes de DNS e de busca no ficheiro compose ou nos argumentos de execución, non só no perfil do host.

Comproba dentro do contedor antes de culpar a imaxe. Dous comandos reproducen todo o diagnóstico en poucos segundos, e o segundo demostra que resolutor respondeu realmente.

Só entón mira o recurso e o filtro

Unha vez que o nome se resolve, os fallos restantes son de rede ordinarios. SMB necesita TCP 445 cara ao servidor, e navegar por unha lista de grupo de traballo depende de servizos de nomes que a VPN probablemente non reenvía. Asigna por nome de host en lugar de agardar a que se encha unha lista, e deixa que o cliente che diga a que etapa chegou. Unha conexión rexeitada e un silencio por tempo de espera tamén merecen separarse, porque a primeira adoita significar que algo respondeu e o segundo que non respondeu 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

Un enderezo resolto co porto 445 rexeitado ou esgotado é un problema de cortalumes ou de escoita no outro lado. Un nome sen resolver é o problema do resolutor. E un montaxe que se autentica pero devolve erros de permisos non é ningunha das dúas cousas, así que non volvas abrir a cuestión de rede cando a sesión xa está establecida.

Mantén a conclusión tan estreita como a evidencia. Cando o enderezo funciona e o nome non, o túnel fai o seu traballo e a corrección pertence á orde do resolutor, ao dominio de busca ou á configuración propia do contedor.