Les partages réseau n’apparaissent pas sur un VPN ? La découverte s’arrête

Le partage s’ouvre lorsque vous saisissez son chemin, et l’explorateur réseau n’affiche rien du tout. Cette combinaison est courante par un tunnel et n’est généralement pas une panne. La découverte pose une question au segment local ; l’accessibilité pose une question à un seul hôte. Un tunnel routé transporte la seconde et non la première.

La découverte et l’accessibilité sont distinctes

Une liste de navigation est produite par des protocoles qui annoncent des services à un segment local et écoutent ces annonces. Ouvrir un partage par son nom est une connexion directe à un seul hôte. La première nécessite un domaine de diffusion ou de multidiffusion ; la seconde nécessite une route et un port.

Par un tunnel, la seconde peut fonctionner parfaitement tandis que la première renvoie une fenêtre vide. Prendre la fenêtre vide pour la panne vous envoie chercher un tunnel cassé qui fait son travail.

Pourquoi la liste de navigation reste vide

Windows a retiré le service Computer Browser et désactivé SMB version 1 par défaut, ce qui a supprimé la machinerie derrière l’ancien Voisinage réseau. Des remplacements comme WS-Discovery, SSDP et le DNS de multidiffusion ciblent des groupes de diffusion ou de multidiffusion qui n’existent que sur un lien local. Un tunnel point à point n’a pas un tel lien, et les routeurs ne transmettent pas ces groupes par défaut. Chaque hôte peut être joignable et la liste peut rester vide.

Certains programmes ajoutent leur propre assistant de découverte. Quand cet assistant fonctionne, c’est une fonctionnalité du programme, pas une propriété du tunnel.

Utilisez des noms explicites, puis confirmez l’accès

Un chemin UNC, un lecteur mappé ou une connexion Finder vers une adresse SMB fonctionne par le tunnel dès que le nom se résout et que le port est ouvert. La résolution peut venir du DNS, d’un suffixe de recherche fourni par le VPN ou d’une entrée hosts gérée centralement. Dans un domaine, une requête d’annuaire peut lister des objets ordinateur, et cette liste est généralement le substitut le plus proche d’une vue de navigation sur un réseau routé. Un scan de ports de préfixes connus n’est acceptable que sur des réseaux que vous exploitez ou que vous êtes explicitement autorisé à tester.

Un hôte qui répond ne promet pas que le partage s’ouvrira. Un NAS peut avoir une liste d’autorisation limitée à son propre sous-réseau, qui rejette les adresses du pool VPN. La règle de pare-feu d’un serveur de fichiers peut ne nommer que le sous-réseau local. Le compte que vous fournissez pour le partage peut être un compte local qui n’a jamais été créé sur ce serveur, et se connecter par le VPN ne le crée pas.

Certains programmes d’entreprise bloquent délibérément le trafic local et celui des machines virtuelles tant que le tunnel est actif. Cet accès manquant relève d’une stratégie, et la correction revient à l’administrateur, pas à la table de routage du programme.

Un ordre de diagnostic qu’il vaut la peine de répéter

Parcourez les couches dans l’ordre : atteindre l’adresse, résoudre le nom, ouvrir le port 445, s’authentifier, puis lire les autorisations du partage. Chaque réponse est distincte, et sauter une étape produit une conclusion fausse et confiante. Ce n’est qu’une fois toutes franchies que la découverte vaut la peine d’être étudiée.

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

Laissez une note avec le nom du serveur, le chemin du partage, l’adresse à laquelle il s’est résolu et le compte qui a fonctionné. Si la liste de navigation se remplit plus tard après un redémarrage de service, traitez cela comme une bizarrerie de découverte et non comme la preuve que la route précédente était fausse. La note est ce qui permet à la personne suivante de sauter la fenêtre vide.