Le partage Samba local a disparu après l’application de DNS par OpenVPN

Samba perd les partages locaux à l’instant où OpenVPN se connecte, et le tunnel n’est presque jamais la cause. Le montage est correct, le NAS est allumé, et le résolveur installé par le tunnel répond à des questions sur un nom qu’il n’a jamais vu. Samba interroge ce résolveur tôt dans son ordre de recherche, croit la réponse et se connecte à une adresse où rien n’écoute. Réparer le partage, c’est réparer la réponse, pas le montage.

Cinq vérifications, dans l’ordre qui élimine le plus de possibilités à chaque étape.

Qui répond pour le nom court

Interrogez le système d’exploitation, pas le gestionnaire de fichiers. resolvectl status affiche les serveurs DNS associés à chaque liaison et indique laquelle est la route par défaut, et une requête sur le nom court rapporte le serveur qui a répondu. Lancez-le une fois pour le nom du NAS et une fois pour un nom dont vous savez qu’il existe dans le domaine du bureau. Si les deux réponses viennent de serveurs différents, vous avez trouvé la scission.

Vérifiez si la réponse était une réponse négative ou une adresse. Une réponse négative signifie que Samba aurait dû passer à un autre mécanisme, et la panne est ailleurs. Une adresse signifie que Samba s’est connecté à un endroit réel et n’a rien obtenu en retour.

Pourquoi Samba croit une réponse erronée

Samba résout les noms par une séquence fixe définie par name resolve order. Sur la plupart des distributions, la valeur par défaut inclut host, c’est-à-dire DNS, et elle s’exécute avant les mécanismes réservés au réseau local comme la diffusion NetBIOS. Un tunnel qui impose un résolveur obtient donc le premier refus sur chaque nom de partage, y compris les noms à une seule étiquette qui n’auraient jamais dû quitter le bâtiment.

Normalement, un nom inconnu renvoie une réponse négative et le mécanisme suivant prend le relais. Certains résolveurs, surtout ceux des fournisseurs d’accès grand public et les publics, répondent aux noms inconnus par une page de recherche ou une adresse publicitaire. Cette réponse ressemble à un succès pour la bibliothèque du résolveur, donc Samba arrête de chercher et compose une adresse qui n’a rien à voir avec votre réseau.

Le résultat est un partage qui disparaît sans boîte de dialogue d’erreur. Rien dans cette séquence n’est une panne de routage VPN, c’est pourquoi le ping vers le NAS fonctionne encore alors que la navigation vers celui-ci ne fonctionne pas.

Deux réparations de portée différente

La réparation étroite conserve le résolveur imposé et change ce que Samba a le droit de lui demander. Ajoutez deux lignes à la configuration Samba que le démon lit réellement, puis redémarrez le service :

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

Sans host dans cette liste, DNS sort du chemin pour les recherches de partages, et les noms à une seule étiquette restent sur le segment local. Les noms du bureau se résolvent toujours normalement pour tout autre programme, car cela ne change que Samba. Le coût est que Samba ne peut plus du tout utiliser DNS, donc un partage adressé par un nom de bureau pleinement qualifié devient un problème.

La réparation large supprime la cause : cessez d’imposer un résolveur qui répond à des noms qu’il ne possède pas, ou imposez une politique de DNS scindé pour que seuls les suffixes du bureau atteignent le résolveur du bureau. C’est la meilleure réponse à long terme sur un réseau géré, car elle protège aussi le navigateur et le gestionnaire de paquets, mais elle exige un accès administratif côté serveur et un client qui obéit aux paramètres imposés.

Choisissez-en une délibérément. Un changement de résolveur modifie la résolution de noms pour toutes les applications à la fois, ce qui est un enregistrement de changement, pas une modification pour un appel au support.

Le suffixe peut tout expliquer

Si le client impose aussi un suffixe de recherche, un nom local court est réécrit dans le domaine du bureau avant d’être interrogé. Alors le résolveur ne ment pas du tout : on lui a posé une question juste sur un nom du bureau et il a donné une réponse correcte. Lisez le nom interrogé dans la sortie du résolveur pour distinguer ce cas de celui de l’adresse publicitaire, car les deux pannes se ressemblent à l’identique dans le gestionnaire de fichiers.

La solution ici est soit d’utiliser le nom local pleinement qualifié, soit d’ajouter une règle de DNS scindé qui possède le suffixe local. Ni l’une ni l’autre n’exige de toucher à Samba.

Prouvez-le après une reconnexion

Testez trois noms dans une seule session : le partage local par nom court, un hôte du bureau par nom et un site web ordinaire. Si le premier fonctionne et que le deuxième casse, la réparation a déplacé la panne au lieu de la supprimer. Si le troisième casse, le changement de résolveur est allé plus loin que prévu et chaque recherche est désormais suspecte.

Ensuite, déconnectez et reconnectez le tunnel et répétez les trois. Les options imposées sont réappliquées à chaque connexion, donc une réparation qui n’existait qu’à l’exécution peut disparaître sans qu’aucun fichier de configuration ne change. Notez le résolveur qui possède chaque suffixe et l’ordre de recherche en vigueur, et notez la date, car la prochaine mise à jour du client est le suspect évident quand cela revient.

Si le partage échoue encore après les cinq vérifications, capturez la requête exacte et la réponse exacte avant de changer quoi que ce soit d’autre. Cette paire de lignes distingue une panne du résolveur d’un nom qui n’existe vraiment pas, et c’est la note de passation la plus rapide que vous puissiez écrire.