Samba en una dirección VPN: por qué desaparece el oyente

El recurso compartido funciona toda la mañana, el túnel se reconecta al mediodía y la misma ruta UNC ahora expira mientras el ping al servidor sigue respondiendo. Nada ha cambiado en la definición del recurso y la VPN está activa. Lo que cambió es la dirección local a la que Samba estaba vinculado, que ya no existe después de recrear la interfaz. Ese modo de fallo es un problema del ciclo de vida del oyente, no un problema de permisos.

El recurso funciona hasta que el túnel se reinicia

Vincular un servicio a una dirección ata su socket a la vida de esa dirección. Cuando la interfaz del túnel se destruye y se reconstruye, la dirección antigua desaparece y el socket vinculado a ella se va con ella. El servicio sigue ejecutándose, pero nada escucha donde se enrutan los clientes.

El ping puede seguir teniendo éxito si la nueva dirección responde a ICMP, y por eso la conectividad parece correcta mientras el recurso está muerto. Ese único éxito engañoso es lo que envía a la gente al cortafuegos.

La conectividad no es una dirección de vinculación

Aquí se mezclan tres decisiones. La ruta decide si llega un paquete del cliente. El socket que escucha decide si algo lo acepta en la dirección local. La configuración del recurso y los permisos del sistema de archivos deciden qué pasa después. Solo la segunda se rompe cuando se recrea la interfaz.

Una dirección del grupo de VPN tampoco es automáticamente una dirección de vinculación local. Pertenece a un cliente, no al servidor de archivos. El ping es una mala prueba para un servicio de archivos.

Mantenga esos propietarios separados también en la documentación. Un cambio futuro en el grupo de VPN no debería exigir editar Samba, y un cambio de permisos del recurso no debería exigir reiniciar el túnel.

Vincule mejor a una dirección estable

El diseño más estable mantiene Samba en una dirección permanente y deja que la VPN lleve a los clientes hasta ella. La dirección del servidor no cambia cuando el túnel oscila, así que el oyente nunca tiene que seguir una interfaz. La admisión la aplican entonces la ruta de VPN y el cortafuegos del host, que están hechos para esa tarea.

Si debe vincularse al túnel, entienda el contrato de la versión instalada. Los parámetros interfaces y bind interfaces only no son lo mismo, y la documentación de vinculación advierte sobre interfaces intermitentes. La gestión dinámica del oyente existe en algunas plataformas, pero es una capacidad que hay que verificar, no dar por supuesta. Lea la tabla antes y después de una oscilación y compare las dos salidas.

ss -ltnp | grep ':445'

Pruebe la reconexión, no la luz verde

Verifique el oyente después de una reconexión, no solo después de arrancar el servicio. Recree el túnel, luego lea la tabla de escucha y confirme que el socket existe en la dirección a la que se enrutan los clientes. Un indicador de túnel verde y una comprobación de configuración superada no demuestran ninguna de las dos cosas.

smbclient -L //files.corp.example -U alice

Después ejecute una operación permitida y una ruta denegada desde un cliente, y repita tras una segunda reconexión. Si el recurso solo funciona hasta la primera oscilación, la vinculación sigue atada a la vida de la interfaz y el diseño no está corregido. Cambie la vinculación o la dirección del servicio, y el síntoma deja de volver.