A sua montagem CIFS falha sobre VPN por causa da ordem no nsswitch

O túnel está ativo. O servidor de ficheiros responde ao ping por endereço. Depois o mount.cifs com o nome do anfitrião fica ali parado algum tempo e reporta que o anfitrião está inacessível, e você começa a reconstruir um perfil de VPN que nunca foi o problema. No Linux o nome é resolvido pela glibc antes de existir qualquer pacote SMB, e a ordem nesse resolvedor pode terminar a pesquisa antes de o DNS ser alguma vez questionado. Este é o caminho que sigo, começando pelo comando que falhou e não pelo cliente.

Leia a falha no lugar certo

Duas ferramentas percorrem caminhos diferentes até ao mesmo nome, e compará-las custa um comando. O getent percorre a pilha de serviços de nomes configurada; o host e o dig consultam o DNS diretamente e ignoram essa pilha. Se a consulta direta devolver um endereço e o getent não devolver nada, o servidor DNS está acessível e é a sua configuração de resolvedor que falha.

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

O terceiro comando é o decisivo: força a fonte DNS e salta o resto da pilha. Quando ele funciona e o getent simples não, provou que a culpa é da ordem, não do túnel e não do servidor.

A linha hosts é uma sequência que para cedo

O resolvedor glibc lê o /etc/nsswitch.conf e percorre a entrada hosts: da esquerda para a direita. Muitas distribuições trazem uma linha em que a pesquisa multicast vem primeiro com uma ação de retorno precoce anexada. A ação não é decoração: quando o mDNS responde “not found”, o [NOTFOUND=return] termina toda a pesquisa, por isso o nome da empresa nunca é enviado ao resolvedor que a VPN impôs. Nada o registra, porque nunca foi enviada uma consulta que o resolvedor pudesse rejeitar. É por isso que a montagem parece pendurar-se e depois reporta um anfitrião inacessível.

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

Mova o DNS para antes da ação de retorno precoce em vez de apagar o mDNS, e altere isso através da gestão de configuração. Uma edição manual sobrevive até à próxima construção da imagem, e depois o mesmo ticket chega de outra máquina que não se lembra da correção.

Um resolvedor não é um domínio de pesquisa

A resolução também precisa que o nome seja tentado. Um nome não qualificado como fileserver só se torna fileserver.corp.example quando um domínio de pesquisa está ligado à interface que transporta a consulta. Uma VPN que impõe um servidor DNS sem lista de pesquisa produz uma divisão muito específica: o nome totalmente qualificado resolve-se e todos os nomes curtos falham.

Teste as duas formas antes de editar o perfil, porque as duas falhas apontam em direções diferentes. Num anfitrião com systemd-resolved a ligação do túnel tem os seus próprios servidores e domínios de encaminhamento, por isso leia a ligação e não o ficheiro global.

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

Se a consulta for atribuída a uma ligação que não transporta o túnel, falta o domínio de encaminhamento mesmo que o endereço DNS esteja presente. Isso é um problema de política na configuração do resolved, não um problema de encaminhamento no túnel.

Os contentores transportam a sua própria cópia da resposta

Um contentor construído a partir de uma imagem genérica traz normalmente um resolv.conf fixo. As alterações de resolvedor feitas no anfitrião não chegam até ele, nem o domínio de pesquisa, por isso uma tarefa de build que monta uma partilha sobre o túnel falha enquanto o mesmo comando funciona fora do contentor. Dê ao contentor as suas próprias definições de DNS e pesquisa no ficheiro compose ou nos argumentos run, e não apenas no perfil do anfitrião.

Verifique dentro do contentor antes de culpar a imagem. Dois comandos reproduzem todo o diagnóstico em poucos segundos, e o segundo prova qual resolvedor respondeu de facto.

Só então olhe para a partilha e para o filtro

Assim que o nome resolve, as falhas restantes são problemas de rede comuns. O SMB precisa de TCP 445 até ao servidor, e navegar numa lista de grupo de trabalho depende de serviços de nomes que o túnel provavelmente não encaminha. Mapeie por nome de anfitrião em vez de esperar que uma lista se preencha, e deixe o cliente dizer até que fase chegou. Uma ligação recusada e um timeout silencioso também merecem ser separados, porque o primeiro significa normalmente que algo respondeu e o segundo que nada o fez.

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

Um endereço resolvido com a porta 445 recusada ou expirada é um problema de firewall ou de listener do outro lado. Um nome não resolvido é o problema do resolvedor. E uma montagem que autentica mas devolve erros de permissão não é nem uma coisa nem outra, por isso não reabra a questão de rede quando a sessão já está estabelecida.

Mantenha a conclusão tão estreita como a evidência. Quando o endereço funciona e o nome não, o túnel está a fazer o seu trabalho e a correção pertence à ordem do resolvedor, ao domínio de pesquisa ou à configuração do próprio contentor.