El recurso compartido local de Samba desapareció tras aplicar DNS con OpenVPN

Samba pierde los recursos compartidos locales en el momento en que OpenVPN se conecta, y el túnel casi nunca es la causa. El montaje está bien, el NAS funciona, y el resolutor que instaló el túnel responde a preguntas sobre un nombre que nunca ha visto. Samba pregunta a ese resolutor pronto en su orden de búsqueda, cree la respuesta y se conecta a una dirección donde nada escucha. Arreglar el recurso significa arreglar la respuesta, no el montaje.

Cinco comprobaciones, en el orden que elimina más posibilidades por paso.

Quién responde por el nombre corto

Pregunte al sistema operativo, no al gestor de archivos. resolvectl status muestra los servidores DNS asociados a cada enlace e indica cuál es la ruta predeterminada, y una consulta del nombre corto informa del servidor que respondió. Ejecútelo una vez para el nombre del NAS y otra para un nombre que sepa que existe en el dominio de la oficina. Si las dos respuestas vienen de servidores distintos, ha encontrado la división.

Compruebe si la respuesta fue una respuesta negativa o una dirección. Una respuesta negativa significa que Samba debería haber pasado a otro mecanismo, y el fallo está en otro sitio. Una dirección significa que Samba se conectó a un lugar real y no obtuvo nada.

Por qué Samba cree una respuesta errónea

Samba resuelve nombres mediante una secuencia fija establecida por name resolve order. En la mayoría de las distribuciones el valor predeterminado incluye host, que significa DNS, y se ejecuta antes de los mecanismos solo de red local como la difusión NetBIOS. Por eso un túnel que impone un resolutor obtiene el primer rechazo en cada nombre de recurso, incluidos los nombres de una sola etiqueta que nunca debían salir del edificio.

Normalmente un nombre desconocido devuelve una respuesta negativa y el siguiente mecanismo recibe su turno. Algunos resolutores, sobre todo los de ISP de consumo y los públicos, responden a nombres desconocidos con una página de búsqueda o una dirección publicitaria. Esa respuesta parece un éxito para la biblioteca del resolutor, así que Samba deja de buscar y marca una dirección que no tiene nada que ver con su red.

El resultado es un recurso que desaparece sin un diálogo de error. Nada de esa secuencia es un fallo de enrutamiento VPN, por eso hacer ping al NAS sigue funcionando mientras que navegar a él no.

Dos reparaciones con distinto alcance

La reparación estrecha conserva el resolutor impuesto y cambia aquello sobre lo que Samba puede preguntarle. Añada dos líneas a la configuración de Samba que el demonio lee realmente y reinicie el servicio:

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

Sin host en esa lista, DNS queda fuera del camino para las búsquedas de recursos, y los nombres de una sola etiqueta se quedan en el segmento local. Los nombres de la oficina siguen resolviéndose con normalidad para cualquier otro programa, porque esto solo cambia Samba. El coste es que Samba ya no puede usar DNS en absoluto, así que un recurso direccionado con un nombre de oficina completamente cualificado se convierte en un problema.

La reparación amplia elimina la causa: deje de imponer un resolutor que responde nombres que no posee, o imponga una política de DNS dividido para que solo los sufijos de la oficina lleguen al resolutor de la oficina. Esa es la mejor respuesta a largo plazo en una red gestionada porque también protege al navegador y al gestor de paquetes, pero requiere acceso administrativo en el lado del servidor y un cliente que obedezca la configuración impuesta.

Elija una a propósito. Un cambio de resolutor altera la resolución de nombres de todas las aplicaciones a la vez, lo cual es un registro de cambio, no una edición para una llamada de soporte.

El sufijo puede explicarlo todo

Si el cliente también impone un sufijo de búsqueda, un nombre local corto se reescribe al dominio de la oficina antes de consultarse. Entonces el resolutor no miente en absoluto: se le hizo una pregunta justa sobre un nombre de oficina y dio una respuesta correcta. Lea el nombre consultado en la salida del resolutor para distinguir esto del caso de la dirección publicitaria, porque los dos fallos se ven idénticos en el gestor de archivos.

La solución aquí es usar el nombre local completamente cualificado o añadir una regla de DNS dividido que posea el sufijo local. Ninguna de las dos requiere tocar Samba.

Demuéstrelo tras una reconexión

Pruebe tres nombres en una sesión: el recurso local por nombre corto, un host de la oficina por nombre y un sitio web corriente. Si el primero funciona y el segundo se rompe, la reparación ha movido el fallo en lugar de eliminarlo. Si se rompe el tercero, el cambio de resolutor fue más lejos de lo previsto y toda búsqueda es ahora sospechosa.

Luego desconecte y vuelva a conectar el túnel y repita los tres. Las opciones impuestas se vuelven a aplicar en cada conexión, así que una reparación que solo existía en tiempo de ejecución puede desaparecer sin que cambie ningún archivo de configuración. Anote el resolutor que posee cada sufijo y el orden de búsqueda vigente, y apunte la fecha, porque la siguiente actualización del cliente es el sospechoso obvio cuando esto vuelva.

Si el recurso sigue fallando tras las cinco comprobaciones, capture la consulta exacta y la respuesta exacta antes de cambiar nada más. Ese par de líneas distingue un fallo del resolutor de un nombre que realmente no existe, y es la nota de traspaso más rápida que puede escribir.