Samba en una adreça VPN: per què desapareix l’escoltador

El recurs compartit funciona tot el matí, el túnel es reconnecta al migdia i la mateixa ruta UNC ara expira mentre el ping al servidor encara respon. No ha canviat res a la definició del recurs i la VPN està activa. El que ha canviat és l’adreça local a què Samba estava lligat, que ja no existeix després de recrear la interfície. Aquest mode de fallada és un problema del cicle de vida de l’escoltador, no un problema de permisos.

El recurs funciona fins que el túnel es reinicia

Lligar un servei a una adreça vincula el seu sòcol a la vida d’aquesta adreça. Quan la interfície del túnel es destrueix i es reconstrueix, l’adreça antiga desapareix i el sòcol que hi estava lligat se’n va amb ella. El servei continua executant-se, però res no escolta allà on s’encaminen els clients.

El ping encara pot tenir èxit si l’adreça nova respon a ICMP, i per això la connectivitat sembla correcta mentre el recurs és mort. Aquest únic èxit enganyós és el que envia la gent al tallafoc.

La connectivitat no és una adreça de lligam

Aquí es barregen tres decisions. La ruta decideix si arriba un paquet del client. El sòcol que escolta decideix si alguna cosa l’accepta a l’adreça local. La configuració del recurs i els permisos del sistema de fitxers decideixen què passa després. Només la segona es trenca quan es recrea la interfície.

Una adreça del pool de la VPN tampoc no és automàticament una adreça de lligam local. Pertany a un client, no al servidor de fitxers. El ping és una prova dolenta per a un servei de fitxers.

Mantingueu aquests propietaris separats també a la documentació. Un canvi futur al pool de la VPN no hauria d’exigir editar Samba, i un canvi de permisos del recurs no hauria d’exigir reiniciar el túnel.

Lligueu-lo més aviat a una adreça estable

El disseny més estable manté Samba en una adreça permanent i deixa que la VPN hi porti els clients. L’adreça del servidor no canvia quan el túnel oscil·la, així que l’escoltador no ha de seguir mai una interfície. L’admissió aleshores la fan complir el camí de la VPN i el tallafoc de l’amfitrió, que estan fets per a aquesta feina.

Si us hi heu de lligar, enteneu el contracte de la versió instal·lada. Els paràmetres interfaces i bind interfaces only no són el mateix, i la documentació del lligam adverteix sobre interfícies intermitents. La gestió dinàmica de l’escoltador existeix en algunes plataformes, però és una capacitat que cal verificar, no donar per feta. Llegiu la taula abans i després d’una oscil·lació i compareu les dues sortides.

ss -ltnp | grep ':445'

Proveu la reconnexió, no el llum verd

Verifiqueu l’escoltador després d’una reconnexió, no només després d’engegar el servei. Recreteu el túnel, després llegiu la taula d’escolta i confirmeu que el sòcol existeix a l’adreça on s’encaminen els clients. Un indicador de túnel verd i una comprovació de configuració superada no proven cap de les dues coses.

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

A continuació executeu una operació permesa i un camí denegat des d’un client, i repetiu-ho després d’una segona reconnexió. Si el recurs només funciona fins a la primera oscil·lació, el lligam encara està lligat a la vida de la interfície i el disseny no s’ha corregit. Canvieu el lligam o l’adreça del servei, i el símptoma deixa de tornar.