A partilha local do Samba desapareceu depois de o OpenVPN impor DNS

O Samba perde as partilhas locais no momento em que OpenVPN se liga, e o túnel quase nunca é a causa. A montagem está bem, o NAS está ligado, e o resolver que o túnel instalou responde a perguntas sobre um nome que nunca viu. O Samba pergunta a esse resolver cedo na sua ordem de pesquisa, acredita na resposta e liga-se a um endereço onde nada está à escuta. Corrigir a partilha significa corrigir a resposta, não a montagem.

Cinco verificações, na ordem que elimina mais possibilidades por passo.

Quem responde pelo nome curto

Pergunte ao sistema operativo, não ao gestor de ficheiros. resolvectl status mostra os servidores DNS associados a cada ligação e marca qual é a rota predefinida, e uma consulta do nome curto indica o servidor que respondeu. Execute uma vez para o nome do NAS e outra para um nome que sabe existir no domínio do escritório. Se as duas respostas vierem de servidores diferentes, encontrou a divisão.

Verifique se a resposta foi uma resposta negativa ou um endereço. Uma resposta negativa significa que o Samba devia ter passado a outro mecanismo, e a falha está noutro lugar. Um endereço significa que o Samba se ligou a um local real e não recebeu nada.

Porque é que o Samba acredita numa resposta errada

O Samba resolve nomes através de uma sequência fixa definida por name resolve order. Na maioria das distribuições o valor predefinido inclui host, que significa DNS, e corre antes dos mecanismos apenas de rede local como a difusão NetBIOS. Por isso um túnel que impõe um resolver obtém o primeiro recusamento em cada nome de partilha, incluindo nomes de uma só etiqueta que nunca deviam sair do edifício.

Normalmente um nome desconhecido devolve uma resposta negativa e o mecanismo seguinte tem a sua vez. Alguns resolvers, sobretudo os de ISP de consumo e os públicos, respondem a nomes desconhecidos com uma página de pesquisa ou um endereço publicitário. Essa resposta parece um sucesso para a biblioteca do resolver, por isso o Samba deixa de procurar e marca um endereço que nada tem a ver com a sua rede.

O resultado é uma partilha que desaparece sem uma caixa de erro. Nada nessa sequência é uma falha de encaminhamento VPN, e é por isso que o ping ao NAS continua a funcionar enquanto navegar até ele não funciona.

Duas reparações com alcances diferentes

A reparação estreita mantém o resolver imposto e altera aquilo que o Samba lhe pode perguntar. Acrescente duas linhas à configuração do Samba que o daemon lê realmente e depois reinicie o serviço:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

Sem host nessa lista, o DNS fica fora do caminho para as pesquisas de partilhas, e os nomes de uma só etiqueta ficam no segmento local. Os nomes do escritório continuam a resolver normalmente para qualquer outro programa, porque isto só altera o Samba. O custo é que o Samba deixa de poder usar DNS de todo, pelo que uma partilha endereçada com um nome de escritório totalmente qualificado se torna um problema.

A reparação ampla elimina a causa: deixe de impor um resolver que responde a nomes que não possui, ou imponha uma política de DNS dividido para que só os sufixos do escritório cheguem ao resolver do escritório. Essa é a melhor resposta a longo prazo numa rede gerida porque também protege o navegador e o gestor de pacotes, mas exige acesso administrativo do lado do servidor e um cliente que obedeça às definições impostas.

Escolha uma deliberadamente. Uma alteração de resolver muda a resolução de nomes para todas as aplicações ao mesmo tempo, o que é um registo de alteração, não uma edição para uma chamada de suporte.

O sufixo pode explicar tudo

Se o cliente também impuser um sufixo de pesquisa, um nome local curto é reescrito no domínio do escritório antes de ser consultado. Então o resolver não mente nada: foi-lhe feita uma pergunta justa sobre um nome do escritório e deu uma resposta correta. Leia o nome consultado na saída do resolver para distinguir isto do caso do endereço publicitário, porque as duas falhas parecem idênticas no gestor de ficheiros.

A solução aqui é usar o nome local totalmente qualificado ou acrescentar uma regra de DNS dividido que possua o sufixo local. Nenhuma das duas exige tocar no Samba.

Comprove-o depois de uma religação

Teste três nomes numa sessão: a partilha local por nome curto, um anfitrião do escritório por nome e um sítio web comum. Se o primeiro funcionar e o segundo falhar, a reparação moveu a falha em vez de a eliminar. Se o terceiro falhar, a alteração do resolver foi mais longe do que o previsto e cada pesquisa é agora suspeita.

Depois desligue e volte a ligar o túnel e repita os três. As opções impostas são reaplicadas em cada ligação, por isso uma reparação que só existia em tempo de execução pode desaparecer sem que nenhum ficheiro de configuração mude. Registe o resolver que possui cada sufixo e a ordem de pesquisa em vigor, e anote a data, porque a próxima atualização do cliente é o suspeito óbvio quando isto voltar.

Se a partilha ainda falhar depois das cinco verificações, capture a consulta exata e a resposta exata antes de mudar mais alguma coisa. Esse par de linhas distingue uma falha do resolver de um nome que realmente não existe, e é a nota de passagem mais rápida que pode escrever.