Samba sur une adresse VPN : pourquoi l’écouteur disparaît

Le partage fonctionne toute la matinée, le tunnel se reconnecte à midi, et le même chemin UNC expire désormais alors que le ping vers le serveur répond encore. Rien n’a changé dans la définition du partage et le VPN est actif. Ce qui a changé, c’est l’adresse locale à laquelle Samba était lié, qui n’existe plus après la recréation de l’interface. Ce mode de défaillance est un problème de cycle de vie de l’écouteur, pas un problème de permissions.

Le partage fonctionne jusqu’au redémarrage du tunnel

Lier un service à une adresse attache son socket à la durée de vie de cette adresse. Quand l’interface du tunnel est détruite puis reconstruite, l’ancienne adresse disparaît et le socket qui y était lié disparaît avec elle. Le service continue de tourner, mais plus rien n’écoute là où les clients sont routés.

Le ping peut encore réussir si la nouvelle adresse répond à ICMP, et c’est pourquoi la connectivité semble bonne alors que le partage est mort. Ce seul succès trompeur est ce qui envoie les gens vers le pare-feu.

La connectivité n’est pas une adresse de liaison

Trois décisions se mélangent ici. La route décide si un paquet client arrive. Le socket en écoute décide si quelque chose l’accepte à l’adresse locale. La configuration du partage et les permissions du système de fichiers décident de ce qui suit. Seule la deuxième casse quand l’interface est recréée.

Une adresse du pool VPN n’est pas non plus automatiquement une adresse de liaison locale. Elle appartient à un client, pas au serveur de fichiers. Le ping est un mauvais test pour un service de fichiers.

Gardez ces propriétaires séparés aussi dans la documentation. Un futur changement du pool VPN ne devrait pas exiger de modifier Samba, et un changement de permissions du partage ne devrait pas exiger un redémarrage du tunnel.

Liez plutôt à une adresse stable

La conception plus stable garde Samba sur une adresse permanente et laisse le VPN y amener les clients. L’adresse du serveur ne change pas quand un tunnel vacille, donc l’écouteur n’a jamais à suivre une interface. L’admission est alors appliquée par le chemin VPN et le pare-feu de l’hôte, qui sont faits pour ce travail.

Si vous devez absolument lier au tunnel, comprenez le contrat de la version installée. Les paramètres interfaces et bind interfaces only ne sont pas la même chose, et la documentation de liaison avertit sur les interfaces intermittentes. La gestion dynamique de l’écouteur existe sur certaines plateformes, mais c’est une capacité à vérifier, pas à supposer. Lisez la table avant et après un vacillement et comparez les deux sorties.

ss -ltnp | grep ':445'

Testez la reconnexion, pas le voyant vert

Vérifiez l’écouteur après une reconnexion, pas seulement après un démarrage de service. Recréez le tunnel, puis lisez la table d’écoute et confirmez que le socket existe sur l’adresse où les clients sont routés. Un voyant de tunnel vert et une vérification de configuration réussie ne prouvent ni l’un ni l’autre.

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

Exécutez ensuite une opération autorisée et un chemin refusé depuis un client, et répétez après une seconde reconnexion. Si le partage ne fonctionne que jusqu’au premier vacillement, la liaison est encore liée à la durée de vie de l’interface et la conception n’est pas corrigée. Changez la liaison ou l’adresse du service, et le symptôme cesse de revenir.