Partages SMB sur VPN sans coupures : résoudre « Le chemin réseau est introuvable » définitivement

Comment SMB échoue réellement sur VPN (les modes de panne qui comptent)

SMB n’est pas un protocole « envoyer des paquets au serveur et prier ». Il maintient des sessions, l’état d’authentification, des crédits (contrôle de flux),
et parfois des handles durables et des leases. C’est idéal sur un LAN où le RTT est faible, la perte de paquets rare et les chemins stables.
Sur VPN, vous avez un RTT plus long, plus de jitter, et plusieurs endroits où le chemin peut disparaître brièvement sans que personne ne l’admette.

Mode de panne 1 : trous noirs MTU et fragmentation qui « marchent presque »

Les VPN changent les contraintes de taille des paquets. Si PMTUD est bloqué ou si ICMP est filtré, un chemin peut silencieusement supprimer les paquets plus grands.
SMB fonctionnera pour les listings de répertoires et les lectures petites, puis mourra lors de grosses écritures, opérations de signature, ou opérations riches en métadonnées.
« Le chemin réseau est introuvable » est souvent la traduction Windows de « la session TCP est morte et la reconnexion a échoué ».

Mode de panne 2 : timers NAT et firewall qui tuent le TCP de longue durée

SMB utilise TCP. Votre VPN utilise probablement UDP (WireGuard, nombreuses configs OpenVPN) ou ESP encapsulé en UDP (IPsec NAT‑T).
Entre les deux : des NAT, des firewalls à état, des NAT de fournisseur, du matériel Wi‑Fi d’hôtel conçu avec mauvaise volonté.
Si un timer d’inactivité expire, le mapping disparaît. Le paquet SMB suivant tombe dans un trou noir, le client réessaie, puis reset, puis reconnecte.

Mode de panne 3 : basculements de route et ambiguïté du split‑tunnel

Si vous utilisez le split‑tunnel, vous faites confiance que la route vers le serveur de fichiers reste toujours dans le tunnel.
C’est un grand exercice de confiance quand le DNS change, quand le serveur de fichiers a plusieurs IPs, quand des referrals DFS pointent ailleurs,
ou quand un client se déplace entre Wi‑Fi et Ethernet.

Mode de panne 4 : fonctionnalités de sécurité SMB augmentent la sensibilité à la latence

Le signing SMB et le chiffrement SMB sont de bonnes choses. Ils ajoutent aussi de la charge et peuvent amplifier les effets de latence — particulièrement sur les petits modèles d’E/S.
Ajoutez un antivirus, des verrous/leases opportunistes et une charge bavarde (les fichiers Office sont de petits paquets de douleur), et
vous avez construit une tour protocolaire où chaque vacillement devient une déconnexion.

Mode de panne 5 : la résolution de noms casse, pas le serveur

« Le chemin réseau est introuvable » est souvent un problème de nom. Le serveur est up, joignable par IP, et sert joyeusement.
Mais le client résout fileserver vers une adresse publique, ou une ancienne adresse, ou vers IPv6 à un instant et IPv4 au suivant.
La reconnexion SMB utilise des noms, des SPN, et parfois des espaces de noms DFS. Un resolver instable peut ressembler à un réseau instable.

Mode de panne 6 : pression côté serveur provoque des reset de session

N’ignorez pas le serveur. Si votre hôte Samba est saturé CPU sur le chiffrement/signature, ou si le serveur Windows étouffe sur la latence du stockage,
le client observe des timeouts et des resets. Le VPN est blâmé parce qu’il est visible. Le stockage est blâmé parce que c’est la tradition.
C’est généralement un mélange.

Règle d’ingénierie de fiabilité : vous ne pouvez pas régler ce que vous ne mesurez pas. C’est la partie où on arrête de deviner et où l’on commence à collecter des preuves.

Faits et contexte : pourquoi ce problème revient sans cesse

• SMB vient avec l’héritage de l’ère “CIFS”. Les dialectes SMB anciens étaient extrêmement bavards sur les liens à haute latence ; beaucoup de mythes « SMB lent sur WAN » viennent de là.
• SMB 2.0 (Windows Vista/Server 2008) fut une réécriture majeure. Il a réduit le nombre de commandes et amélioré le pipelining, rendant le comportement WAN moins catastrophique.
• SMB 3.x a introduit chiffrement, multichannel et handles durables. Idéal pour les datacenters ; sur VPN, le multichannel peut surprendre si plusieurs interfaces existent.
• Les espaces de noms DFS peuvent rediriger les clients en vol. Un utilisateur mappe \\corp\share, mais les referrals peuvent l’envoyer vers une cible différente avec une joignabilité différente via le VPN.
• Les échecs PMTUD sont plus vieux que votre système de tickets. « Ça marche pour les petits paquets, échoue pour les gros » est un classique quand ICMP est filtré ou mal moulé.
• Les timers NAT sont des choix politiques, pas de la physique. Certains appareils gardent les mappings UDP pendant quelques secondes, d’autres pendant des minutes ; les clients en déplacement subissent régulièrement le pire cas.
• Les timeouts SMB peuvent être plus longs que la patience de votre VPN. La couche applicative peut attendre alors que la couche réseau a déjà perdu l’état, rendant les échecs aléatoires.
• Windows tente fort de reconnecter les lecteurs mappés. C’est utile jusqu’à ce que ça ne le soit plus : vous obtenez des « chemin introuvable » intermittents, des gels d’Explorateur et des invites d’identifiants fantômes.
• Les paramètres de sécurité se sont durcis avec le temps. Désactiver le signing/chiffrement pour « améliorer les performances » marche parfois — jusqu’à ce que cela devienne le prochain point d’audit.

Une idée paraphrasée souvent attribuée à James Hamilton (Amazon) : Mesurez d’abord ; sinon vous débattez d’opinions. Cet état d’esprit vous fait gagner des jours ici.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Quand quelqu’un dit « le lecteur VPN est tombé encore », vous avez deux tâches : rétablir le service rapidement, et empêcher la prochaine coupure.
Voici l’ordre qui trouve rapidement le goulot d’étranglement au lieu d’offrir un spectacle.

Premier : prouver si c’est le nom, la route ou le transport

1. Nom : le nom d’hôte du partage résout‑il vers l(es) IP attendu(s) lorsque vous êtes sur le VPN ?
2. Route : la route vers cette IP passe‑t‑elle réellement à l’intérieur du tunnel (et est‑elle stable) ?
3. Transport : pouvez‑vous maintenir une session TCP propre sur le port 445 sans retransmissions ni resets ?

Deuxième : chasser MTU/MSS et trous noirs

1. Testez le MTU de chemin avec DF activé.
2. Recherchez fragmentation, retransmissions et patterns « TCP previous segment not captured » dans les captures.
3. Si vous voyez « ça marche pour les petites opérations, échoue sur une grosse copie », supposez le MTU jusqu’à preuve du contraire.

Troisième : vérifier les timers NAT/firewall et les keepalives VPN

1. Est‑ce que ça coupe après N minutes d’inactivité ? Ce n’est pas une coïncidence ; c’est un timer.
2. Est‑ce que ça coupe quand les utilisateurs se déplacent ou sortent de veille ? C’est une perte d’état.
3. Corrigez avec des keepalives et des timeouts raisonnables avant de toucher aux clés de registre SMB.

Quatrième : valider la santé du serveur (CPU, latence disque, service SMB)

1. Sur Samba : saturation CPU, coût du chiffrement, et latence disque apparaissent comme des timeouts client.
2. Sur serveurs Windows : journaux d’événements, statistiques SMB serveur et latence stockage importent plus que les impressions.

Blague #1 : Le VPN est comme un tunnel de dessin animé — solide jusqu’à ce que vous regardiez en bas et réalisiez que vous avez un problème de MTU.

Tâches pratiques avec commandes : prouver la cause racine

Voici des commandes réelles que vous pouvez exécuter. Chacune inclut ce que la sortie signifie et la décision à prendre ensuite.
Utilisez‑les comme une checklist, pas comme un buffet.

Tâche 1 : Confirmer la résolution DNS du serveur de fichiers (client Linux)

cr0x@server:~$ getent ahosts fileserver.corp.local
10.60.12.25      STREAM fileserver.corp.local
10.60.12.25      DGRAM  fileserver.corp.local
10.60.12.25      RAW    fileserver.corp.local

Signification : Vous avez un seul enregistrement A (IPv4) et il est dans la plage VPN. Bien.
Si vous voyez une IP publique, ou un sous‑réseau inattendu, vous avez trouvé une défaillance de DNS split.
Décision : Corriger le DNS (résolveurs fournis par le VPN, NRPT sur Windows, DNS à horizon partagé). Ne touchez pas encore à SMB.

Tâche 2 : Confirmer le DNS sur Windows (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName fileserver.corp.local | Select-Object -First 5"
Name                           Type TTL  Section IPAddress
----                           ---- ---  ------- ---------
fileserver.corp.local          A    60   Answer  10.60.12.25

Signification : Windows résout comme prévu.
Si la réponse bascule entre des IPs pendant une session (surtout IPv6 vs IPv4), les reconnexions SMB peuvent partir en vrille.
Décision : Stabiliser les réponses DNS pour les clients VPN, ou épingler un nom stable utilisé uniquement pour les services fichiers.

Tâche 3 : Vérifier que la route passe par l’interface VPN (Linux)

cr0x@server:~$ ip route get 10.60.12.25
10.60.12.25 dev wg0 src 10.60.0.14 uid 1000
    cache

Signification : Le trafic utilise wg0. S’il sort par wlan0 ou eth0, les règles split‑tunnel sont erronées.
Décision : Corriger le routage/policy routing, ou ajuster AllowedIPs (WireGuard) / routes poussées (OpenVPN).

Tâche 4 : Vérifier la route sur Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix 10.60.12.0/24 | Sort-Object RouteMetric | Select-Object -First 3"
ifIndex DestinationPrefix NextHop     RouteMetric PolicyStore
------- ----------------- -------     ----------- -----------
31      10.60.12.0/24     0.0.0.0     5           ActiveStore

Signification : La route existe et est préférée (métrique basse). Si la route VPN a une métrique supérieure à la route par défaut,
vous obtenez « parfois ça marche » selon l’état des interfaces.
Décision : Corriger les métriques d’interface, ou définir des routes explicites pour les cibles SMB.

Tâche 5 : Tester la joignabilité TCP du port SMB 445 (Linux)

cr0x@server:~$ nc -vz -w 3 10.60.12.25 445
Connection to 10.60.12.25 445 port [tcp/microsoft-ds] succeeded!

Signification : Le port 445 est joignable via TCP. S’il time‑out, vous avez des problèmes de firewall/routage/VPN.
S’il se connecte mais SMB échoue encore, le problème est de couche supérieure (auth, dialecte, signing, timeouts).
Décision : Si bloqué, arrêtez‑vous et corrigez les contrôles d’accès et le routage. Ne réglez pas SMB pour compenser un port bloqué.

Tâche 6 : Tester depuis Windows avec Test-NetConnection

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.60.12.25 -Port 445"
ComputerName     : 10.60.12.25
RemoteAddress    : 10.60.12.25
RemotePort       : 445
InterfaceAlias   : CorpVPN
TcpTestSucceeded : True

Signification : Windows confirme : TCP est ouvert sur l’interface VPN.
Décision : Passez aux diagnostics MTU et de session SMB si les utilisateurs voient encore des coupures.

Tâche 7 : Énumérer le dialecte SMB et les capacités (Linux smbclient)

cr0x@server:~$ smbclient -L //10.60.12.25 -U 'CORP\alice' -m SMB3
Password for [CORP\alice]:
        Sharename       Type      Comment
        ---------       ----      -------
        projects        Disk      Projects share
        IPC$            IPC       IPC Service (Samba 4.19.5)
SMB1 disabled -- no workgroup available

Signification : Vous avez négocié SMB3 et SMB1 est désactivé (bon). Si le serveur n’autorise que SMB1, corrigez cela avant toute autre action.
Décision : Si SMB3 fonctionne par IP mais pas par nom, retour aux problèmes DNS/SPN/DFS.

Tâche 8 : Inspecter les sessions SMB actives sur le client Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,ContinuouslyAvailable"
ServerName ShareName Dialect NumOpens ContinuouslyAvailable
---------- --------- ------- -------- ---------------------
10.60.12.25 projects 3.1.1   12       False

Signification : Le dialecte est SMB 3.1.1. Si le dialecte est inférieur à l’attendu, performances et résilience peuvent se dégrader.
Décision : Si vous voyez des reconnexions répétées ou NumOpens qui se réinitialise, corrélez avec les logs VPN et la perte de paquets.

Tâche 9 : Trouver les coupures et reconnexions dans les logs SMB client Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Connectivity' -MaxEvents 5 | Format-Table TimeCreated,Id,LevelDisplayName -Auto"
TimeCreated            Id LevelDisplayName
-----------            -- ----------------
12/28/2025 10:14:22  308 Warning
12/28/2025 10:13:57  310 Warning
12/28/2025 10:13:41  320 Error

Signification : Warnings/erreurs dans la connectivité SMBClient s’alignent souvent avec des flaps de chemin.
Décision : Si cela corrèle avec des roaming Wi‑Fi ou une renégociation VPN, résolvez d’abord le problème d’état réseau.

Tâche 10 : Capturer retransmissions et resets pendant une copie (Linux tcpdump)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.60.12.25 and port 445 -vv
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:15:01.112233 IP 10.60.0.14.51422 > 10.60.12.25.445: Flags [P.], seq 129:1189, ack 774, win 501, length 1060
10:15:01.342190 IP 10.60.0.14.51422 > 10.60.12.25.445: Flags [P.], seq 129:1189, ack 774, win 501, length 1060 (retransmission)
10:15:02.001005 IP 10.60.12.25.445 > 10.60.0.14.51422: Flags [R], seq 774, win 0, length 0

Signification : Retransmissions suivies d’un RST sentent la perte de paquets, des problèmes MTU, ou un middlebox tuant l’état inactif.
Décision : Si les retransmissions augmentent sous charge, priorisez MTU/MSS et l’investigation perte/jitter. Si RST apparaît après inactivité, priorisez timers NAT/keepalive.

Tâche 11 : Mesurer le MTU de chemin avec DF activé (Linux ping)

cr0x@server:~$ ping -c 3 -M do -s 1360 10.60.12.25
PING 10.60.12.25 (10.60.12.25) 1360(1388) bytes of data.
1368 bytes from 10.60.12.25: icmp_seq=1 ttl=63 time=38.1 ms
1368 bytes from 10.60.12.25: icmp_seq=2 ttl=63 time=37.5 ms
1368 bytes from 10.60.12.25: icmp_seq=3 ttl=63 time=37.9 ms

--- 10.60.12.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 37.5/37.8/38.1/0.2 ms

Signification : Payload 1360 octets avec DF passe. Augmentez jusqu’à échec pour trouver votre plafond.
Si vous recevez « Frag needed », PMTUD fonctionne ; si ça time‑out simplement, quelque chose noie l’ICMP.
Décision : Si le MTU est inférieur à ce que vous supposiez, clamp MSS ou réduisez le MTU du tunnel.

Tâche 12 : Vérifier le MTU de l’interface et du device VPN (Linux)

cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Signification : MTU par défaut WireGuard ≈ 1420. Si vous encapsulez encore (WG sur UDP sur quelque chose de bizarre),
1420 peut encore être trop élevé.
Décision : Si les tests path MTU montrent des échecs au‑dessus de ~1360, définissez le MTU de wg0 plus bas (ex. 1380/1360) ou clamez MSS au bord.

Tâche 13 : Clamper le MSS TCP sur Linux (firewall edge) et confirmer les compteurs

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -L FORWARD -v -n | head
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in  out  source      destination
   14   840 TCPMSS     tcp  --  *   wg0  0.0.0.0/0   0.0.0.0/0   tcp flags:0x02/0x02 TCPMSS clamp to PMTU

Signification : Des paquets atteignent la règle (compteur pkts augmente). C’est ce que vous souhaitez.
Décision : Si le clamping stabilise SMB, conservez‑le et documentez‑le. Sinon, passez à perte/jitter/timers NAT.

Tâche 14 : Vérifier le timing du handshake WireGuard (côté serveur)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 0aBc...redacted
  listening port: 51820

peer: 7XyZ...redacted
  endpoint: 203.0.113.44:54321
  allowed ips: 10.60.0.14/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.82 GiB received, 2.10 GiB sent

Signification : Si « latest handshake » est ancien pendant une session active, quelque chose casse la joignabilité UDP.
Décision : Définir PersistentKeepalive sur les clients derrière NAT ; ajuster les timeouts des firewalls.

Tâche 15 : Confirmer que le serveur SMB écoute et n’est pas bloqué (serveur Samba Linux)

cr0x@server:~$ sudo ss -ltnp | grep ':445 '
LISTEN 0      128          0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1214,fd=45))

Signification : smbd écoute. S’il manque, le problème est la santé du service serveur ou les règles de bind.
Décision : Si à l’écoute, vérifiez les logs smbd et la pression sur les ressources système.

Tâche 16 : Vérifier l’état de Samba et les processus bloqués

cr0x@server:~$ sudo systemctl status smbd --no-pager
● smbd.service - Samba SMB Daemon
     Loaded: loaded (/lib/systemd/system/smbd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-12-28 09:12:06 UTC; 1h 3min ago
       Docs: man:smbd(8)
   Main PID: 1214 (smbd)
     Status: "smbd: ready to serve connections..."
      Tasks: 5 (limit: 18972)
     Memory: 92.5M
        CPU: 3min 12s

Signification : Le service est sain. S’il redémarre, crashe, ou loggue des échecs d’auth, c’est votre vrai souci.
Décision : Si le démon est stable, focalisez‑vous sur le chemin réseau, MTU et comportement client.

Tâche 17 : Mesurer la latence disque sur le serveur (Linux)

cr0x@server:~$ iostat -x 1 3
Linux 6.8.0 (nas01)  12/28/2025  _x86_64_ (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.31    0.00    2.14    7.55    0.00   86.00

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1          85.0    40.0  6120.0  3200.0   2.10   0.22  2.8

Signification : await est bas ; le disque n’est pas le goulot.
Si await est de l’ordre de dizaines/centaines de ms sous charge, les clients peuvent timeout et reconnecter.
Décision : Si la latence stockage est mauvaise, corrigez le stockage (profondeur de file d’attente, contention, disques défaillants, pool saturé) avant de blâmer le VPN.

Tâche 18 : Vérifier le comportement Kerberos vs NTLM (client Windows)

cr0x@server:~$ powershell -NoProfile -Command "klist"
Current LogonId is 0:0x3e7

Cached Tickets: (3)
#0>     Client: alice @ CORP.LOCAL
        Server: krbtgt/CORP.LOCAL @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a10000 -> forwardable renewable initial pre_authent name_canonicalize

Signification : Des tickets Kerberos existent. Si l’accès au partage échoue uniquement par nom mais marche par IP, SPN et Kerberos peuvent être impliqués.
Décision : Confirmer les SPN corrects pour le nom du serveur de fichiers, et s’assurer que le DNS VPN pointe vers les contrôleurs de domaine.

Réglages réseau qui arrêtent les coupures (MTU, MSS, NAT, mobilité)

Choisir un MTU ennuyeux et l’appliquer

L’encapsulation VPN réduit le MTU effectif. Ensuite quelqu’un empile VPN‑sur‑VPN, ou ajoute PPPoE, ou vous passez par un hotspot cellulaire.
Si vous ne contrôlez pas le MTU, vous finirez par envoyer des paquets trop grands qui seront silencieusement supprimés.

Mon parti pris : si vous ne pouvez pas garantir que PMTUD fonctionne de bout en bout, clampérez le MSS au bord du VPN. Ce n’est pas glamour, mais cela évite la classe de tickets « grosse écriture tue la session ».
Sur WireGuard, réduire le MTU de l’interface est aussi efficace, mais le clamping aide quand les clients varient largement.

Arrêtez de bloquer l’ICMP comme en 2004

L’ICMP « fragmentation needed » fait partie du bon fonctionnement d’Internet. Le bloquer vous force à deviner le MTU et à espérer.
Si la sécurité insiste, vous pouvez toujours clamperez le MSS — mais comprenez que vous choisissez une dette opérationnelle.

Traitez le NAT comme s’il vous en voulait (parce que c’est le cas)

Si le VPN est basé sur UDP, définissez des keepalives pour les clients derrière un NAT. PersistentKeepalive de WireGuard existe pour ça.
OpenVPN a aussi des options keepalive. IPsec NAT‑T a souvent besoin d’un réglage DPD.

Les symptômes qui hurlent « timeout NAT » : coupure après une période d’inactivité prévisible, récupération immédiate après reconnexion, et échecs principalement sur des « réseaux invités » ou mobiles.

Mobilité et veille : traitez‑les comme des déconnexions, pas des hoquets

Les portables dorment. Le Wi‑Fi roam. Les adresses IP changent. Les sessions SMB n’aiment aucun de ces cas.
Si les utilisateurs sont mobiles, visez :

• Un VPN qui se reconnecte rapidement et renouvelle correctement les clés
• Keepalive ajustés pour le NAT
• DNS et routes stables après reconnexion
• Fonctionnalités SMB comme les durable handles quand disponibles (dépend du serveur)

Évitez le split‑tunneling pour les partages de fichiers sauf si vous êtes disciplinés

Le split‑tunnel est une décision politique déguisée en décision réseau. Ça peut aller, mais seulement si :
la plage IP cible SMB est explicite et stable, les referrals DFS sont contrôlés, et le DNS est à horizon partagé.
Sinon, vous obtenez la pire classe d’incident : intermittent, spécifique à l’utilisateur, et impossible à reproduire depuis votre bureau.

Blague #2 : Le split‑tunneling, c’est comme commander « mi‑épicé » au resto — chacun l’interprète différemment, et vous le regretterez plus tard.

Réglages SMB/Samba qui calment les crises

Ne “optimisez” pas en abaissant la sécurité du protocole

Désactiver le signing ou le chiffrement pour faire « marcher mieux SMB sur VPN » est souvent un piège. Vous pouvez réduire le coût CPU, certes.
Mais vous changez aussi le comportement en cas d’échec, créez des problèmes de conformité, et parfois aggravez les reconnexions en altérant les chemins d’authentification.
Réglez d’abord le réseau, puis décidez si la crypto est réellement votre goulot.

Préférez SMB 3.1.1, désactivez SMB1 partout

SMB1 est insecure et fragile. De plus, il se comporte mal sur les liaisons à haute latence. Si, en 2025, quelque chose a encore besoin de SMB1,
mettez‑le sur un segment réseau quarantiné et prévoyez sa suppression sérieusement.

Prudence avec SMB Multichannel sur VPN

SMB Multichannel peut ouvrir plusieurs connexions TCP sur plusieurs NIC. Sur VPN, des clients multi‑interface peuvent faire des choses étranges :
un canal passe par le tunnel, un autre tente de passer en direct, puis vous obtenez des blocages et des tempêtes de reconnexions.

Si le multichannel cause de l’instabilité, désactivez‑le sur clients ou serveurs de façon contrôlée.
Mais ne faites pas cela en premier. Prouvez que c’est le cas avec inspection de connexion SMB et captures.

Spécificités Samba : garder des logs utiles, pas bruyants

Sur Samba, activez un niveau de logs suffisant pour corréler déconnexions, échecs d’auth et négociation signing/chiffrement.
Mais ne lancez pas le debug niveau 10 en production pendant les heures ouvrées, sauf si vous aimez remplir les disques et rater la vraie panne.

Comprendre la charge : documents Office vs fichiers médias vs artefacts de build

La douleur SMB dépend de la charge. Une grosse copie séquentielle est sensible au MTU et au débit. Un dossier plein de petits fichiers est sensible à la latence.
Les documents Office sont gourmands en métadonnées et aiment les locks/leases. Les builds dev déclenchent des tempêtes d’ouvertures/fermetures.

Si les utilisateurs se plaignent « ouvrir un dossier prend 30 secondes » mais « copier un gros fichier va bien », c’est latence + opérations bavardes, pas bande passante brute.
Cela vous oriente vers RTT/jitter du VPN, délais DNS, et coût du signing SMB — pas le débit disque.

Trois mini‑histoires d’entreprise (comment les équipes se font vraiment piéger)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne a déployé un nouveau client VPN brillant. Le groupe pilote a rapporté du succès : les lecteurs mappés marchaient, la navigation était correcte,
et la file d’aide ne débordait pas. Le déploiement a touché toute l’entreprise un lundi.

Mardi, la finance a commencé à obtenir des erreurs « Le chemin réseau est introuvable » autour de midi. L’ingénierie non.
La première hypothèse était prévisible : « Le serveur de fichiers est surchargé. » L’équipe a ajouté du CPU à la VM et l’a déplacée sur un stockage plus rapide.
Rien n’a changé. Les erreurs continuaient, surtout pour la finance et les RH.

La deuxième hypothèse était plus subtile : « Si le VPN est connecté, le DNS est correct. » Ce n’était pas le cas.
Le VPN poussait une liste de serveurs DNS, mais Windows gardait les serveurs DNS du Wi‑Fi en priorité pour certains clients à cause des métriques d’interface.
Donc les utilisateurs résolvaient l’espace de noms DFS vers une cible injoignable via le split‑tunnel, de façon intermittente.

La correction n’était pas plus de compute. C’était le routage et le contrôle des noms : correction des métriques d’interface, enforcement du comportement split‑DNS,
et épinglage de la sélection de la cible DFS pour les clients VPN. L’« instabilité serveur » a disparu.
Le postmortem fut bref et douloureux : leur hypothèse que « connecté » signifie « correctement routé » était fausse.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une autre organisation avait une lenteur SMB chronique sur un VPN IPsec. Un ingénieur a décidé d’« optimiser » en augmentant le MTU du tunnel
et en désactivant le MSS clamping. L’idée : moins de paquets, meilleur débit. Ça a fonctionné en labo.

En production, des utilisateurs distants sur des FAI grand public ont commencé à perdre des sessions pendant de gros transferts.
Les petites opérations étaient correctes, ce qui faisait ressembler le problème à un bug applicatif. Les logs VPN étaient majoritairement propres.
Les logs SMB montraient des déconnexions et reconnexions sans erreur serveur évidente.

Une capture de paquets a finalement montré : de plus grands segments TCP étaient noyés quelque part entre le FAI et la passerelle IPsec.
Les messages ICMP « frag needed » ne revenaient pas (filtrés par un middlebox), donc PMTUD ne pouvait rien faire.
Le MTU plus élevé a augmenté la fréquence des paquets surdimensionnés, transformant un cas limite rare en problème quotidien.

Revenir à un MTU conservateur plus le MSS clamping a corrigé immédiatement. Les performances se sont améliorées aussi — non pas parce que le MTU était « plus rapide »,
mais parce que les retransmissions ont cessé. L’optimisation marchait dans un réseau propre. Le monde réel n’est pas un réseau propre.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise globale avec beaucoup de télétravailleurs avait une politique : chaque partage distant avait deux accès — SMB over VPN pour les workflows legacy,
et un service documentaire web pour le reste. Pas par amour de la complexité, mais parce qu’ils respectaient la fragilité des clients en mobilité.

Ils avaient aussi un runbook standard : vérifier la résolution DNS contre les résolveurs VPN, valider les métriques de route, exécuter un test MTU DF ping,
et inspecter les logs de connectivité SMB. Rien de fancy. Juste de la constance.

Un jour, les plaintes « chemin réseau introuvable » ont explosé après une mise à jour de firewall. Le runbook a trouvé le problème en minutes :
ICMP type 3 code 4 (fragmentation needed) était bloqué par une nouvelle politique. La découverte de MTU a cassé. Les grosses écritures SMB ont cassé.

Parce que l’organisation avait une règle MSS clamping standard au bord (oui, ennuyeux), l’impact fut limité à un sous‑ensemble d’utilisateurs dont le chemin contournait
ce bord. Ils ont corrigé la politique de firewall, étendu la couverture du clamping, et l’incident s’est terminé sans nuit blanche héroïque.
La victoire n’était pas un génie. C’était de la constance.

Erreurs fréquentes : symptôme → cause → solution

« Le chemin réseau est introuvable » n’apparaît qu’après la copie de gros fichiers

Cause racine : trou noir MTU / échec PMTUD ; paquets surdimensionnés supprimés ; TCP se fige puis reset.

Solution : Clamp MSS au bord du VPN ou réduire le MTU du tunnel ; autoriser ICMP fragmentation‑needed ; vérifier avec DF pings et captures.

Le lecteur mappé se reconnecte en boucle, surtout après des périodes d’inactivité

Cause racine : timer d’inactivité NAT/firewall supprimant le mapping UDP ou l’état TCP ; keepalive VPN trop espacés.

Solution : Configurer des keepalives VPN (PersistentKeepalive WireGuard ; keepalive OpenVPN) ; augmenter les timeouts d’état sur les firewalls edge quand possible.

Marche par IP, échoue par nom (ou chemin DFS)

Cause racine : échec split‑horizon DNS, ordre de suffixes erroné, ou referrals DFS pointant vers des cibles injoignables ; parfois SPN Kerberos incorrect.

Solution : Corriger le DNS pour les clients VPN, assurer la joignabilité des DC, valider les SPN, contrôler les referrals DFS pour les clients VPN.

Seuls certains utilisateurs échouent, et ça change selon l’emplacement

Cause racine : métriques de route, fuites split‑tunnel, client utilisant DNS local, ou particularités MTU de l’ISP.

Solution : Appliquer une configuration client cohérente (routes, DNS, métriques d’interface), et appliquer le MSS clamping à un point d’étranglement cohérent.

Ouvrir des dossiers est lent ; copier un fichier lourd passe

Cause racine : latence et opérations SMB bavardes ; parfois antivirus et coût du signing SMB.

Solution : Améliorer RTT/jitter (endpoints VPN meilleurs, POPs plus proches), revoir le coût CPU du signing/chiffrement SMB, envisager de déplacer les workflows très bavards hors SMB.

Coupures aléatoires lors du roaming Wi‑Fi ou veille/réveil du portable

Cause racine : reset du transport VPN ; changements d’IP ; routes obsolètes ; session SMB ne survit pas aux transitions réseau.

Solution : Utiliser un client VPN avec reconnexion rapide, keepalive ajustés, et envisager un VPN « always‑on » ; informer les utilisateurs que la veille équivaut à une déconnexion.

SMB fonctionne, mais les performances sont mauvaises après activation du chiffrement partout

Cause racine : goulot CPU sur client ou serveur pour le chiffrement/signing ; aggravé par la haute latence.

Solution : Mesurer le CPU, vérifier l’accélération AES‑NI/crypto, mettre à l’échelle les serveurs de fichiers, ou activer sélectivement le chiffrement selon les zones de risque (avec validation sécurité).

Tempêtes de déconnexions quand les clients ont plusieurs interfaces

Cause racine : SMB Multichannel tentant des chemins qui ne sont pas cohérents sur le VPN ; routage asymétrique.

Solution : Valider avec inspection de connexion SMB ; désactiver multichannel là où il cause l’instabilité ; garantir que tous les chemins SMB restent dans le tunnel.

Listes de contrôle / plan étape par étape

Étape par étape : stabiliser SMB sur VPN en production

1. Définir la cible : lister les serveurs de fichiers, espaces de noms DFS, sous‑réseaux, et si le split‑tunnel est permis.
   Si vous ne pouvez pas le lister, vous ne pouvez pas le router.
2. Rendre le DNS déterministe pour les clients VPN : résolveurs fournis par le VPN, suffixes corrects, et réponses cohérentes.
   Tester la résolution par nom et le chemin DFS.
3. Rendre le routage déterministe : routes explicites pour les sous‑réseaux SMB via le VPN ; vérifier les métriques pour que la route VPN gagne.
4. Corriger le MTU à la manière ennuyeuse : autoriser PMTUD (ICMP frag‑needed), ou clamperez le MSS TCP au bord du VPN. Valider avec DF pings.
5. Définir des keepalives pour les clients NAT : choisir un intervalle qui survit aux timeouts NAT typiques (souvent 20–30 secondes pour les réseaux récalcitrants).
6. Instrumenter avant de toucher SMB : collecter logs de connectivité SMB client, logs VPN, et captures pendant une reproduction.
7. Vérifier la santé côté serveur : CPU, mémoire, latence disque, et stabilité du service SMB. Corriger les vrais goulots.
8. Contrôler les referrals DFS : s’assurer que les clients VPN reçoivent des referrals vers des cibles joignables, idéalement dans la même zone réseau.
9. Évaluer les paramètres de sécurité SMB avec des données : conserver signing/chiffrement sauf si vous pouvez prouver un goulot CPU et avez une décision de risque approuvée.
10. Déployer les changements prudemment : groupe canari, critères de succès mesurables (taux de coupure, nombre de reconnexions, taux de réussite des copies), plan de rollback.

Checklist : quoi capturer pendant un incident réel

• IP client, nom de l’interface VPN, et endpoint du tunnel
• IPs résolues pour le nom du partage et l’espace de noms DFS au moment de la panne
• Snapshot de la table de routage (client) et routes/politiques poussées par le VPN
• Résultats des tests MTU (plus grand DF ping qui fonctionne)
• Capture de paquets autour de la panne (RST ? retransmissions ?)
• Événements Windows SMBClient Connectivity ou logs Samba autour de l’horodatage
• Métriques CPU serveur et latence disque pendant la fenêtre d’incident

FAQ

1) Pourquoi SMB a l’air correct un moment puis se coupe ?

Parce que beaucoup de pannes sont basées sur des timers (idles NAT/firewall) ou des événements (roaming Wi‑Fi, rekey VPN, veille portable).
SMB est stateful ; quand l’état sous‑jacent disparaît, l’opération suivante déclenche l’échec.

2) « Le chemin réseau est introuvable » est‑ce toujours un problème de DNS ?

Non. C’est souvent DNS, mais cela peut aussi être la sélection de route, des resets TCP, ou le port 445 bloqué.
Traitez‑le comme « nom/route/transport » jusqu’à preuve du contraire.

3) Devons‑nous utiliser SMB sur VPN du tout ?

Si vous devez supporter des workflows legacy, oui — mais gardez les attentes réalistes.
Pour les utilisateurs mobiles, envisagez de déplacer les workflows collaboratifs vers des services conçus pour la connectivité intermittente.
Conservez SMB pour ce qui en a vraiment besoin.

4) Quel MTU devrais‑je définir ?

Il n’y a pas de chiffre universellement correct. Mesurez votre path MTU (tests DF ping) et choisissez une valeur conservatrice.
Si vous ne pouvez pas garantir ICMP, clamperez le MSS et gardez le MTU du tunnel modeste.

5) Le chiffrement SMB provoque‑t‑il des déconnexions ?

Il peut contribuer indirectement : une charge CPU plus élevée augmente le temps de réponse ; sur des liaisons à haute latence, cela peut vous pousser dans les timeouts.
Mesurez le CPU sur client/serveur pendant les transferts avant de blâmer le chiffrement.

6) Pourquoi ça marche par IP mais pas par nom ?

L’accès par nom déclenche résolution DNS, vérifications SPN/Kerberos et comportement DFS. L’accès par IP contourne une partie de cela.
Cette différence est un cadeau diagnostique : concentrez‑vous sur le DNS et l’identité (Kerberos/SPN), pas la perte de paquets.

7) Devons‑nous désactiver SMB Multichannel sur VPN ?

Seulement si vous pouvez prouver que cela crée des chemins instables ou asymétriques.
Le multichannel est excellent sur des réseaux stables. Sur VPN avec multiples interfaces client, il peut être chaotique.
Validez avec inspection des connexions SMB d’abord.

8) Quel est le changement le plus rentable pour la stabilité ?

Si vous subissez des coupures aléatoires : keepalives et hygiène MTU/MSS au bord du VPN.
Ces deux mesures éliminent une grande part des tickets de « déconnexions mystères ».

9) Pourquoi l’ouverture de dossiers semble pire que la copie de fichiers ?

Parcourir un dossier déclenche beaucoup d’opérations SMB petites : métadonnées, ouvertures, fermetures, vérifications d’attributs.
Un RTT élevé et du jitter multiplient cette douleur. Les gros transferts séquentiels amortissent mieux la latence.

10) Peut‑on corriger ça uniquement avec des tweaks de registre Windows ?

Parfois vous pouvez masquer des symptômes. Mais si votre réseau perd l’état ou noie des paquets, les réglages de registre SMB ne font que retarder l’échec.
Corrigez le transport d’abord.

Conclusion : prochaines étapes à entreprendre cette semaine

SMB sur VPN peut être stable, mais seulement si vous le traitez comme une dépendance de production plutôt que comme une fonctionnalité de confort.
Les pannes récurrentes — trous noirs MTU, timeouts NAT, et dérive DNS/routing en split — ne sont pas mystérieuses. Elles sont simplement sous‑mesurées.

Prochaines étapes pratiques :

1. Exécuter le playbook de diagnostic rapide sur un client affecté et capturer des preuves (DNS, route, joignabilité TCP, tests MTU DF).
2. Implémenter le clamp MSS (ou un MTU de tunnel conservateur) au point d’étranglement VPN et valider avec un test de copie de gros fichier.
3. Activer et régler les keepalives VPN pour les clients derrière NAT ; confirmer que les coupures n’arrivent plus après inactivité.
4. Auditer les referrals DFS et les routes split‑tunnel pour que « le partage » signifie toujours la même cible joignable.
5. Établir un petit runbook et l’exiger dans les tickets : pas de logs, pas de conjectures.

Faites ces cinq actions, et « Le chemin réseau est introuvable » deviendra un événement rare et explicable plutôt qu’un rituel hebdomadaire.