O recurso compartido local de Samba desapareceu tras aplicar DNS con OpenVPN

Samba perde os recursos compartidos locais no momento en que OpenVPN se conecta, e o túnel case nunca é a causa. A montaxe está ben, o NAS funciona, e o resolutor que instalou o túnel responde a preguntas sobre un nome que nunca viu. Samba pregunta a ese resolutor pronto na súa orde de busca, cre a resposta e conéctase a un enderezo onde nada escoita. Arranxar o recurso significa arranxar a resposta, non a montaxe.

Cinco comprobacións, na orde que elimina máis posibilidades por paso.

Quen responde polo nome curto

Pregunte ao sistema operativo, non ao xestor de ficheiros. resolvectl status mostra os servidores DNS asociados a cada ligazón e indica cal é a ruta predeterminada, e unha consulta do nome curto informa do servidor que respondeu. Execúteo unha vez para o nome do NAS e outra para un nome que saiba que existe no dominio da oficina. Se as dúas respostas proveñen de servidores distintos, atopou a división.

Comprobe se a resposta foi unha resposta negativa ou un enderezo. Unha resposta negativa significa que Samba debería pasar a outro mecanismo, e o fallo está noutro sitio. Un enderezo significa que Samba se conectou a un lugar real e non obtivo nada.

Por que Samba cre unha resposta errónea

Samba resolve nomes mediante unha secuencia fixa establecida por name resolve order. Na maioría das distribucións o valor predeterminado inclúe host, que significa DNS, e execútase antes dos mecanismos só de rede local como a difusión NetBIOS. Por iso un túnel que impón un resolutor obtén o primeiro rexeitamento en cada nome de recurso, incluídos os nomes dunha soa etiqueta que nunca debían saír do edificio.

Normalmente un nome descoñecido devolve unha resposta negativa e o seguinte mecanismo recibe a súa quenda. Algúns resolutores, sobre todo os de ISP de consumo e os públicos, responden a nomes descoñecidos cunha páxina de busca ou un enderezo publicitario. Esa resposta parece un éxito para a biblioteca do resolutor, así que Samba deixa de buscar e marca un enderezo que non ten nada que ver coa súa rede.

O resultado é un recurso que desaparece sen un diálogo de erro. Nada desa secuencia é un fallo de encamiñamento VPN, por iso facer ping ao NAS segue funcionando mentres que navegar a el non.

Dúas reparacións con distinto alcance

A reparación estreita conserva o resolutor imposto e cambia aquilo sobre o que Samba pode preguntarlle. Engada dúas liñas á configuración de Samba que o demonio le realmente e reinicie o servizo:

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

Sen host nesa lista, DNS queda fóra do camiño para as buscas de recursos, e os nomes dunha soa etiqueta quedan no segmento local. Os nomes da oficina seguen resolvéndose con normalidade para calquera outro programa, porque isto só cambia Samba. O custo é que Samba xa non pode usar DNS en absoluto, así que un recurso direccionado cun nome de oficina completamente cualificado convértese nun problema.

A reparación ampla elimina a causa: deixe de impor un resolutor que responde nomes que non posúe, ou impoña unha política de DNS dividido para que só os sufixos da oficina cheguen ao resolutor da oficina. Esa é a mellor resposta a longo prazo nunha rede xestionada porque tamén protexe o navegador e o xestor de paquetes, pero require acceso administrativo no lado do servidor e un cliente que obedez a configuración imposta.

Escolla unha a propósito. Un cambio de resolutor altera a resolución de nomes de todas as aplicacións á vez, o cal é un rexistro de cambio, non unha edición para unha chamada de soporte.

O sufixo pode explicalo todo

Se o cliente tamén impón un sufixo de busca, un nome local curto reescríbese no dominio da oficina antes de consultarse. Entón o resolutor non mente en absoluto: fíxoselle unha pregunta xusta sobre un nome de oficina e deu unha resposta correcta. Lea o nome consultado na saída do resolutor para distinguir isto do caso do enderezo publicitario, porque os dous fallos vense idénticos no xestor de ficheiros.

A solución aquí é usar o nome local completamente cualificado ou engadir unha regra de DNS dividido que posúa o sufixo local. Ningunha das dúas require tocar Samba.

Demostreino tras unha reconexión

Probe tres nomes nunha sesión: o recurso local por nome curto, un host da oficina por nome e un sitio web corrente. Se o primeiro funciona e o segundo rompe, a reparación moveu o fallo en lugar de eliminalo. Se rompe o terceiro, o cambio de resolutor foi máis lonxe do previsto e toda busca é agora sospeitosa.

Logo desconecte e volva conectar o túnel e repita os tres. As opcións impostas vólvense aplicar en cada conexión, así que unha reparación que só existía en tempo de execución pode desaparecer sen que cambie ningún ficheiro de configuración. Anote o resolutor que posúe cada sufixo e a orde de busca vixente, e apunte a data, porque a seguinte actualización do cliente é o sospeitoso obvio cando isto volva.

Se o recurso segue fallando tras as cinco comprobacións, capture a consulta exacta e a resposta exacta antes de cambiar nada máis. Ese par de liñas distingue un fallo do resolutor dun nome que realmente non existe, e é a nota de traspaso máis rápida que pode escribir.