Lecteur mappé via un VPN de site : DNS, SMB et le chemin UNC

La page Réseau de l'Explorateur affiche les appareils qui se sont annoncés sur le segment local, et un tunnel routé ne transporte aucune de ces annonces. C'est pourquoi un serveur peut être parfaitement joignable alors que la fenêtre devant l'utilisateur reste vide. Un chemin UNC nommé ne dépend pas du tout de la découverte, et la solution consiste à faire résoudre le nom et à faire répondre le port. La fenêtre vide est le symptôme d'une mauvaise couche, pas d'un partage cassé.

Découvrir n'est pas la même chose que joindre

Windows découvre les machines proches via des protocoles conçus pour un domaine de diffusion, puis présente ce qu'il a trouvé sous forme de liste de confort. Rien dans cette liste n'est nécessaire pour accéder aux fichiers par SMB. Un client qui connaît le nom du serveur et atteint TCP 445 ouvrira le partage, que la machine apparaisse ou non un jour dans Réseau.

Les deux couches échouent indépendamment, et c'est pourquoi « je ne le vois pas » et « je n'arrive pas à l'ouvrir » méritent des tests différents. Regarder la liste renseigne sur la découverte ; ouvrir le chemin renseigne sur le service.

Nommez le serveur avant de mapper le partage

Publiez le serveur de fichiers dans le DNS avec l'adresse qu'il possède de l'autre côté, et pointez le site client vers un résolveur capable de répondre pour cette zone. Un nom pleinement qualifié évite de dépendre d'une liste locale de suffixes de recherche, ce qui est la raison habituelle pour laquelle un nom court fonctionne sur un site et échoue sur un autre.

Si l'environnement utilise Active Directory, la résolution de noms fait aussi partie de l'authentification : le client doit joindre un contrôleur de domaine pour Kerberos, et une horloge trop décalée fera échouer l'échange de tickets. C'est un problème différent de la joignabilité SMB et cela ressemble à une erreur d'identifiants. Testez le contrôleur de domaine avant de retaper le mot de passe.

Router et filtrer dans les deux sens

Un tunnel de site à site a besoin du préfixe distant dans la table de routage locale et du préfixe local dans la distante, et le pare-feu de chaque côté doit autoriser le trafic qui arrive. Une configuration unidirectionnelle produit une connexion qui s'ouvre et ne répond jamais, ce que les utilisateurs décrivent comme un partage lent. Vérifiez d'abord les compteurs du tunnel lui-même. Si les paquets sortent et que rien ne revient, cherchez la route de retour ou le filtre distant.

Avec WireGuard, les IP autorisées du pair et les routes du système d'exploitation doivent concorder avec cette conception. Le tunnel transporte des paquets ; il ne fournit pas d'enregistrements DNS ni d'autorisations de partage d'un côté comme de l'autre.

Basez la règle de pare-feu sur le réseau source réel qui se connectera, et consignez l'exception. Si la conception traduit des adresses quelque part sur le chemin, la règle doit utiliser la source traduite, et l'adresse d'origine du client n'est plus visible dans les journaux.

Authentifiez-vous, puis mappez le lecteur

Descendez les couches avec des commandes plutôt qu'avec la fenêtre de l'Explorateur :

Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no

La deuxième commande prouve le chemin TCP, pas le droit de lire quoi que ce soit. La troisième est celle où l'authentification et l'autorisation s'exercent, et un échec à ce stade doit vous renvoyer vers les autorisations du partage et du système de fichiers, pas vers le routeur.

Conservez la signature SMB et la politique d'authentification existante. Réactiver SMB1 ou relayer les diffusions de découverte à travers le tunnel n'est pas nécessaire pour un chemin explicite, et TCP 445 doit rester sur le chemin privé plutôt que sur un renvoi exposé à Internet. Donnez aux utilisateurs un raccourci géré ou un lecteur mappé vers le nom approuvé, et la page Réseau vide cesse d'avoir de l'importance.