Samba nun enderezo VPN: por que desaparece o oínte
O recurso compartido funciona ata que o túnel se reinicia, e despois expira mentres o ping segue respondendo. Un oínte ligado a un enderezo desaparecido explica todo o patrón.
O recurso compartido funciona toda a mañá, o túnel reconéctase ao mediodía e a mesma ruta UNC agora expira mentres o ping ao servidor segue respondendo. Nada cambiou na definición do recurso e a VPN está activa. O que cambiou é o enderezo local ao que Samba estaba ligado, que xa non existe despois de recrear a interface. Ese modo de fallo é un problema do ciclo de vida do oínte, non un problema de permisos.
O recurso funciona ata que o túnel se reinicia
Ligar un servizo a un enderezo ata o seu socket á vida dese enderezo. Cando a interface do túnel se destrúe e se reconstrúe, o enderezo antigo desaparece e o socket ligado a el vai con ela. O servizo segue executándose, pero nada escoita onde se encamiñan os clientes.
O ping aínda pode ter éxito se o novo enderezo responde a ICMP, e por iso a conectividade parece correcta mentres o recurso está morto. Ese único éxito enganoso é o que envía a xente ao cortafogos.
A conectividade non é un enderezo de ligazón
Aquí mestúranse tres decisións. A ruta decide se chega un paquete do cliente. O socket que escoita decide se algo o acepta no enderezo local. A configuración do recurso e os permisos do sistema de ficheiros deciden que pasa despois. Só a segunda se rompe cando se recrea a interface.
Un enderezo do grupo de VPN tampouco é automaticamente un enderezo de ligazón local. Pertence a un cliente, non ao servidor de ficheiros. O ping é unha mala proba para un servizo de ficheiros.
Manteña eses propietarios separados tamén na documentación. Un cambio futuro no grupo de VPN non debería esixir editar Samba, e un cambio de permisos do recurso non debería esixir reiniciar o túnel.
Ligue mellor a un enderezo estable
O deseño máis estable mantén Samba nun enderezo permanente e deixa que a VPN leve os clientes ata el. O enderezo do servidor non cambia cando o túnel oscila, así que o oínte nunca ten que seguir unha interface. A admisión aplícana entón a ruta de VPN e o cortafogos do host, que están feitos para esa tarefa.
Se debe ligar ao túnel, entenda o contrato da versión instalada. Os parámetros interfaces e bind interfaces only non son o mesmo, e a documentación de ligazón advirte sobre interfaces intermitentes. A xestión dinámica do oínte existe nalgunhas plataformas, pero é unha capacidade que hai que verificar, non dar por feita. Lea a táboa antes e despois dunha oscilación e compare as dúas saídas.
ss -ltnp | grep ':445'Probe a reconexión, non a luz verde
Verifique o oínte despois dunha reconexión, non só despois de arrancar o servizo. Recree o túnel, despois lea a táboa de escoita e confirme que o socket existe no enderezo ao que se encamiñan os clientes. Un indicador de túnel verde e unha comprobación de configuración superada non demostran ningunha das dúas cousas.
smbclient -L //files.corp.example -U aliceDespois execute unha operación permitida e unha ruta denegada desde un cliente, e repítao tras unha segunda reconexión. Se o recurso só funciona ata a primeira oscilación, a ligazón segue atada á vida da interface e o deseño non está corrixido. Cambie a ligazón ou o enderezo do servizo, e o síntoma deixa de volver.