Partage SMB en échec uniquement via le VPN : signature ou chevauchement de sous-réseau ?
Un partage qui fonctionne sur le LAN peut échouer uniquement via le tunnel. Distinguez un refus de signature, un sous-réseau qui se chevauche et une session SMB obsolète.
Un lecteur mappé qui fonctionne au bureau et expire à la maison ne vous apprend presque rien en soi. Le tunnel transporte clairement des paquets, sinon rien n’atteindrait le serveur. Ce qui a échoué se situe sur l’une de trois couches : le nom a été résolu vers la mauvaise adresse, le client a refusé de signer la session, ou une ancienne session a survécu à la connexion qui la portait. Chacune a une réparation différente, et deux des trois sont côté client.
Trois pannes portent le même message
La lettre de lecteur ne dit pas quelle couche a cédé, et le texte d’erreur est généralement assez générique pour convenir aux trois. Séparez-les avec deux questions rapides : le serveur répond-il à son adresse IP, et le port 445 accepte-t-il une connexion ?
Ces réponses donnent une table de décision plutôt qu’une supposition. L’IP fonctionne et le nom non : c’est la résolution. Les deux fonctionnent et l’ouverture de session est refusée : c’est la signature. Les deux fonctionnent et une lecture de fichier se bloque après une coupure du tunnel : c’est une session obsolète.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
Traitez-les dans cet ordre, car un nom qui pointe vers le mauvais hôte rend chaque test ultérieur inutile.
Résolvez le nom avant de toucher au partage
Si le serveur répond à son adresse et que le nom du partage expire, le tunnel fait son travail et le client cherche au mauvais endroit. En accès distant, deux causes expliquent l’essentiel.
La première est un chevauchement d’adresses. Quand le bureau utilise 192.168.70.0/24 et que la box domestique distribue la même plage, un nom d’hôte qui se résout en 192.168.70.20 peut désigner un appareil local au lieu du serveur derrière le tunnel. Windows peut alors envoyer la requête en local, refuser la route, ou résoudre vers une imprimante qui possède justement cette adresse. La réparation consiste à renuméroter un côté, pas à ajouter une autre route.
La seconde est la portée DNS. Un adaptateur VPN sans serveur DNS interne, ou avec un serveur inaccessible à travers le tunnel, laisse les noms courts partir vers un résolveur public. Lisez les entrées DNS de l’adaptateur et interrogez directement le nom interne avant de toucher au partage :
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15Si cette requête renvoie l’adresse attendue, la résolution est réglée et le problème se situe plus haut dans la pile.
Lisez l’exigence de signature des deux côtés
Un serveur joignable qui refuse toute ouverture de session est la signature d’un décalage de stratégie plutôt que d’une panne réseau. Windows peut exiger la signature SMB côté client, et un serveur ou NAS qui ne signe pas ne peut pas terminer la session, quelle que soit la santé du tunnel.
Vous pouvez lire le réglage client sans parcourir l’éditeur de stratégie :
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionLa valeur correspondante côté serveur se trouve dans la configuration SMB du serveur, et les deux doivent concorder. Dans un cas signalé, le client avait l’exigence activée par stratégie locale alors que le serveur ne signait pas du tout ; la désactiver puis exécuter gpupdate /force a rétabli le partage immédiatement. C’est une étape de diagnostic pour confirmer la cause, pas un correctif permanent.
Préférez activer la signature aux deux extrémités lorsque le serveur la prend en charge. La modification d’un paramètre de sécurité pour faire fonctionner un partage doit être consignée avec sa valeur précédente et la raison, afin que personne n’ait à la redécouvrir lors du prochain audit.
Videz la session obsolète avant de régler les minuteries
Un partage qui ne se bloque qu’après une coupure et une reconnexion du VPN conserve généralement une session que le serveur a déjà abandonnée. Le serveur ferme les sessions SMB inactives selon la minuterie Autodisconnect sous LanmanServer\Parameters, qui vaut 15 minutes par défaut, tandis que le client a son propre SessTimeout sous LanmanWorkstation\Parameters. Une coupure plus longue que ces valeurs laisse chaque extrémité avec une idée différente de la session.
Reproduisez-la dans un ordre fixe pour que le résultat ait un sens : connectez le tunnel, ouvrez le partage, coupez le tunnel pendant deux minutes, rétablissez-le, puis essayez de lire un fichier. Si le montage se rétablit seul, ne touchez pas aux minuteries. S’il se bloque jusqu’au remontage, reconnectez le partage une fois le tunnel actif au lieu de le monter avant qu’il existe, et vérifiez si l’assistant de montage réessaie.
Augmenter les délais est une dernière étape raisonnable pour un lien instable, mais elle traite le symptôme. Un client qui attend plus longtemps une session que le serveur a oubliée attend toujours.
Terminez en lisant un fichier via le montage, puis en coupant et rétablissant le tunnel une fois de plus. Ce test d’acceptation couvre les trois couches d’un coup, et c’est le seul test qui corresponde à ce que fait réellement l’utilisateur.