Rien n’énerve plus un bureau distant envers « l’IT » qu’un lecteur réseau qui se déconnecte en plein enregistrement. Les utilisateurs se moquent que vous ayez un « SD‑WAN moderne » ou que le tableau de bord du pare‑feu soit vert. Ils veulent que Excel ne mette pas 45 secondes à s’ouvrir, qu’il ne gèle pas, puis ne propose pas d’enregistrer une copie de récupération nommée ~$Budget_FINAL_v7_REALFINAL.xlsx.
Le SMB entre sites peut être stable. Mais il faut le traiter comme un système distribué en production, pas comme « une lettre de lecteur sur un tunnel ». Le tunnel n’est que le début : MTU, DNS, routage, délais du pare‑feu, dialecte/fonctionnalités SMB et backend de stockage conspirent pour créer des déconnexions qui semblent aléatoires. Elles ne le sont pas. Elles sont juste sous‑instrumentées.
Ce qui casse réellement quand SMB traverse un VPN
SMB (le protocole de partage de fichiers Windows) est bavard. Le SMB3 moderne est bien meilleur que les jours sombres, mais il effectue encore beaucoup de petites requêtes/réponses : négociation, authentification, tree connect, create/open, verrouillage, lecture/écriture, requêtes de métadonnées, énumération de répertoires, opportunistic locks, durable handles, leases. Chacun de ces éléments est sensible à la latence, à la perte de paquets et aux réinitialisations d’état.
Quand vous déplacez SMB d’un LAN à un « LAN‑presque » (deux bureaux séparés par un tunnel), vos modes de défaillance se multiplient :
- La latence amplifie la bavardise. La navigation dans les répertoires et les séquences d’ouverture de fichiers deviennent des moments « pourquoi ça réfléchit ? ».
- La perte de paquets se transforme en déconnexions. Pas parce que SMB est fragile, mais parce que les éléments à état (tunnels VPN, tables NAT, sessions de pare‑feu) sont fragiles quand on perd ou réordonne des paquets.
- Les problèmes de Path MTU provoquent des blocages qui ressemblent à des gels d’applications. Trames jumbo et encapsulation VPN : duo classique pour « ça marche pour les petits fichiers, ça plante pour les gros ».
- Les délais d’expiration de session sont déclenchés par des fichiers ouverts mais inactifs. Les utilisateurs laissent des fichiers ouverts pendant des heures. SMB conserve une session. L’équipement tunnel peut ne pas le faire.
- Confusion DNS et authentification inter‑sites. Kerberos est exigeant sur l’heure, le DNS et les SPN. Quand il bascule en NTLM sur un lien latent, vous payez en délais et en invites utilisateurs.
- Les fonctions de sécurité peuvent coûter en débit. Le signing et le chiffrement SMB sont de bons outils. Ils sont aussi des multiplicateurs de CPU et de latence lorsqu’activés sans discernement.
L’erreur opérationnelle est de supposer que SMB est « juste TCP/445 ». Ce n’est pas le cas. C’est un protocole applicatif à état dont l’expérience utilisateur est dominée par la partie la plus lente de votre système. Souvent, cette partie n’est pas la bande passante VPN. C’est les IOPS du stockage, la table de sessions du pare‑feu ou un MTU mal dimensionné.
Il y a une phrase de Werner Vogels utile comme boussole : Tout échoue, tout le temps
(idée paraphrasée). SMB entre sites, c’est choisir quelles défaillances seront gracieuses et lesquelles deviendront « le partage est en panne ».
Faits intéressants et contexte historique
Un peu de contexte aide car SMB porte des décisions de conception sur des décennies. Quelques faits concrets qui montrent pourquoi « c’est instable » veut souvent dire « on l’utilise hors de sa zone de confort ».
- SMB est né dans les années 1980. Il était conçu pour de petits réseaux locaux où la latence était pratiquement « une non‑question ».
- CIFS n’était pas tant un nouveau protocole qu’un instantané marketing. « CIFS » renvoie souvent au comportement de l’ère SMB1 ; ce n’est pas ce que vous voulez sur un WAN aujourd’hui.
- SMB2 (ère Vista/Server 2008) a été une réécriture majeure. Il a réduit la bavardise et amélioré le pipelining, ce qui compte beaucoup sur VPN.
- SMB3 (Windows 8/Server 2012) a ajouté durable handles et multichannel. Les durable handles sont importants pour les interruptions transitoires ; multichannel peut aider sur des serveurs multi‑NIC, mais il peut aussi perturber les réseaux avec routage asymétrique.
- Le chiffrement SMB est arrivé avec SMB3. Il est par partage et par session et peut être négocié ; il peut vous protéger si « le VPN est coupé mais le partage reste exposé » — si votre routage est complexe — mais ce n’est pas gratuit.
- Les opportunistic locks (oplocks) et leases sont essentiels pour la performance SMB. Ils réduisent les allers‑retours en mettant en cache. Ils peuvent aussi créer des drames de fichiers verrouillés avec des applications mal conçues, surtout sur des liens intermittents.
- DFS Namespaces existe en grande partie parce que « un nom de serveur de fichiers est une vulnérabilité ». Il vous donne de l’indirection : les clients pointent vers un namespace, pas un serveur spécifique, permettant migration et ciblage multi‑site.
- Windows propose « Offline Files » (caching côté client) depuis longtemps. Peu utilisé car mal configuré, mais c’est l’une des réponses sensées pour « utilisateurs éditant des documents sur un WAN ».
Architectures qui fonctionnent (et celles qui semblent bon marché mais ne le sont pas)
Option A : Serveur de fichiers central + VPN site‑à‑site (par défaut)
C’est le plus courant : un serveur HQ central, les succursales se connectent en IPsec/OpenVPN/WireGuard, les utilisateurs mappent des lecteurs.
Quand ça marche : la latence est modérée (unités de ms à dizaines faibles), le VPN est stable, votre pare‑feu ne tue pas agressivement les sessions inactives, et votre stockage est assez rapide pour que « ouvrir un fichier » ne bloque pas sur le disque.
Quand ça échoue : latence élevée, perte de paquets, utilisateurs ouvrant d’énormes arbres de dossiers, CAD/Adobe/PST Outlook sur le partage, ou toute appli effectuant beaucoup d’appels de métadonnées. Aussi : tunnels qui clignotent ou réauthentifient trop souvent.
Option B : DFS Namespace + réplication DFS (pour profils et partages tolérant la consistance éventuelle)
Si vous avez deux bureaux qui ont besoin du même partage d’équipe et ne requièrent pas de sémantique d’unique rédacteur stricte, DFS‑N + DFS‑R peut réduire le trafic SMB inter‑sites en conservant des réplicas locaux. Les utilisateurs interagissent principalement avec leur serveur local.
Compromis : DFS‑R n’est pas un système de fichiers distribué transactionnel. Des conflits surviennent. Les gros fichiers répliquent lentement. Certains motifs (beaucoup de petits fichiers, renommages fréquents) peuvent être pénibles.
Option C : Serveur de fichiers en succursale avec mise en cache (version adulte de « garder les données locales »)
Installez un serveur (ou NAS) dans la succursale et utilisez un mécanisme conçu pour les WAN : BranchCache, cache tiers, ou une plateforme de collaboration où les sémantiques de partage ne sont pas requises.
Mon avis : si vous avez plus de ~20 utilisateurs dans une succursale travaillant activement sur des documents toute la journée, un cache/replica local est généralement moins coûteux que de brûler des heures d’ingénierie pour faire ressembler SMB à un LAN sur un WAN.
Option D : Arrêtez d’utiliser SMB comme outil de collaboration WAN
Oui, vraiment. SMB est excellent à l’intérieur d’un site. Entre sites, c’est souvent la mauvaise abstraction. Pour la collaboration inter‑bureaux sur des documents, envisagez une plateforme de synchronisation, un DMS, ou au moins « édition locale avec synchronisation ». Gardez SMB pour les profils, partages applicatifs et workflows on‑prem où il excelle.
Blague #1 : SMB sur un VPN instable, c’est comme une relation à distance : ça peut marcher, mais chaque paquet perdu devient un problème de confiance.
Mode opératoire de diagnostic rapide
Voici l’ordre de triage qui trouve le goulot d’étranglement le plus vite en environnements réels. Ne commencez pas par basculer des clés de registre SMB comme si vous jouiez à whack‑a‑mole.
Première étape : est‑ce le tunnel ou le serveur ?
- Vérifier la stabilité du tunnel : rekeys, clignotements, événements DPD/keepalive, perte de paquets.
- Vérifier l’état du serveur : CPU, latence disque, erreurs NIC, statistiques du serveur SMB.
- Vérifier les symptômes clients : est‑ce que tous les utilisateurs se déconnectent ou seulement certaines sous‑réseaux/clients ?
Deuxième : MTU et fragmentation
- Recherchez « petits fichiers OK, gros fichiers bloqués ». C’est MTU/MSS jusqu’à preuve du contraire.
- Confirmez la Path MTU de bout en bout à travers l’encapsulation VPN.
- Serrez le MSS aux bords du VPN si vous ne pouvez pas garantir PMTUD.
Troisième : DNS, AD et synchronisation temporelle
- Kerberos déteste la dérive horaire et les bizarreries DNS.
- Confirmez que les clients de la succursale résolvent le serveur de fichiers vers l’IP prévue, pas un enregistrement obsolète ou une adresse publique.
- Vérifiez l’atteignabilité des contrôleurs de domaine et le mapping site/sous‑réseau si vous êtes en AD.
Quatrième : délais d’expiration de session et tables d’état
- Les pare‑feu et dispositifs NAT tuent les sessions « inactives » alors que SMB les considère vivantes.
- Les appareils VPN qui réauthentifient agressivement peuvent casser des flux longue durée.
- Recherchez des motifs : déconnexion après exactement N minutes.
Cinquième : incompatibilité de fonctionnalités SMB
- Signing/chiffrement SMB + CPU faible = douleur.
- Multichannel sur VPN peut surprendre s’il existe plusieurs chemins ou si le NAT change.
- OpLocks/leases peuvent être une aubaine ou une source de verrous selon les applications.
Tâches pratiques : commandes, sorties et décisions
Voici des tâches réelles à lancer pendant un incident ou pendant un projet « stabiliser ». Chacune inclut la commande, une sortie d’exemple, ce que ça signifie et la décision suivante. Un mélange Linux (pour VPN/pare‑feu/NAS) et Windows (pour clients/serveurs SMB) est volontaire car votre environnement n’est jamais pur.
Task 1: Prove whether the tunnel is flapping (Linux, WireGuard example)
cr0x@server:~$ sudo wg show
interface: wg0
public key: zX2...abc=
listening port: 51820
peer: 8kF...def=
endpoint: 203.0.113.10:51820
allowed ips: 10.20.0.0/16
latest handshake: 18 seconds ago
transfer: 22.41 GiB received, 19.88 GiB sent
persistent keepalive: every 25 seconds
Ce que ça signifie : « latest handshake » montre la vivacité récente. Si ça passe à des minutes/heures pendant des plaintes utilisateurs, votre « problème SMB » est en réalité un problème de vivacité du tunnel.
Décision : Si le handshake est obsolète pendant les incidents, corrigez le routage/keepalive/atteignabilité des bords du tunnel avant de toucher SMB.
Task 2: Check IPsec rekey churn and DPD events (strongSwan example)
cr0x@server:~$ sudo journalctl -u strongswan --since "2 hours ago" | egrep -i "rekey|deleting|dpd|proposal" | tail -n 20
Dec 27 09:11:03 gw1 charon[1187]: 09[KNL] deleting IKE_SA vpn-to-branch[12] between 198.51.100.2...203.0.113.10
Dec 27 09:11:03 gw1 charon[1187]: 09[IKE] initiating IKE_SA vpn-to-branch[13] to 203.0.113.10
Dec 27 09:11:10 gw1 charon[1187]: 09[IKE] IKE_SA vpn-to-branch[13] established between 198.51.100.2...203.0.113.10
Dec 27 09:12:12 gw1 charon[1187]: 11[NET] sending DPD request
Dec 27 09:12:22 gw1 charon[1187]: 11[NET] DPD response received
Ce que ça signifie : Des cycles delete/initiate fréquents peuvent casser des flux TCP (bonjour SMB). DPD en soi est correct ; une renégociation constante ne l’est pas.
Décision : Si vous voyez des rekeys toutes les quelques minutes ou des suppressions inattendues, ajustez les durées, les réglages de réauth, les keepalives NAT et enquêtez sur la perte de paquets amont.
Task 3: Confirm routing symmetry (Linux)
cr0x@server:~$ ip route get 10.20.5.25
10.20.5.25 dev wg0 src 10.10.0.1 uid 0
cache
Ce que ça signifie : La passerelle enverra le trafic vers 10.20.5.25 via l’interface VPN. Si elle choisit une interface WAN à la place, les réponses sortiront par le mauvais chemin et SMB chutera « aléatoirement ».
Décision : Corrigez les tables de routage/policy routing pour que les retours vers les sous‑réseaux de succursale retournent par le tunnel.
Task 4: Find MTU on the path (Linux ping with DF)
cr0x@server:~$ ping -M do -s 1372 10.20.5.25 -c 3
PING 10.20.5.25 (10.20.5.25) 1372(1400) bytes of data.
1380 bytes from 10.20.5.25: icmp_seq=1 ttl=63 time=18.4 ms
1380 bytes from 10.20.5.25: icmp_seq=2 ttl=63 time=18.7 ms
1380 bytes from 10.20.5.25: icmp_seq=3 ttl=63 time=18.3 ms
--- 10.20.5.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
Ce que ça signifie : Des paquets de 1400 octets passent sans fragmentation. Si une taille plus grande renvoie « Frag needed », votre MTU effective est plus basse que prévu.
Décision : Définissez le MTU de l’interface VPN en conséquence et/ou clampiez le MSS TCP pour que SMB n’essaie pas des segments surdimensionnés.
Task 5: Check TCP MSS clamping (Linux iptables example)
cr0x@server:~$ sudo iptables -t mangle -S | grep -i tcp-mss
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Ce que ça signifie : Le clamp MSS est présent pour les paquets SYN TCP forwardés, ce qui aide à éviter les PMTU blackholes sur les VPNs.
Décision : S’il est absent et que vous avez des problèmes MTU, ajoutez‑le sur le bord VPN (ou définissez MSS explicitement selon votre encapsulation).
Task 6: Measure loss/jitter quickly (Linux, mtr)
cr0x@server:~$ mtr -rwzc 50 10.20.5.25
Start: 2025-12-27T09:20:02+0000
HOST: gw1 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.10.0.254 0.0% 50 0.4 0.5 0.3 1.2 0.2
2.|-- 10.255.0.2 0.0% 50 18.5 18.9 17.8 31.2 1.9
3.|-- 10.20.5.25 2.0% 50 19.0 19.4 18.2 33.4 2.4
Ce que ça signifie : 2% de perte vers l’hôte de la succursale suffit à rendre SMB hanté, surtout pour des charges riches en métadonnées.
Décision : Traitez la perte/jitter soutenue comme un incident réseau d’abord. L’ajustement SMB ne réparera pas la physique.
Task 7: Verify firewall isn’t killing idle flows (Linux conntrack)
cr0x@server:~$ sudo conntrack -L | grep -E "dport=445|sport=445" | head
tcp 6 431992 ESTABLISHED src=10.20.5.25 dst=10.10.1.50 sport=50322 dport=445 src=10.10.1.50 dst=10.20.5.25 sport=445 dport=50322 [ASSURED] mark=0 use=1
Ce que ça signifie : L’entrée d’état existe et montre une longue valeur de timeout (ici ~5 jours). Si votre timeout est court (minutes), vous verrez des déconnexions après des périodes d’inactivité.
Décision : Augmentez les timeouts TCP established sur le pare‑feu/dispositif VPN, ou assurez‑vous que des keepalives sont présents pour les sessions SMB longue durée.
Task 8: On Windows client, confirm SMB dialect and encryption/signing
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | ft ServerName,ShareName,Dialect,Encrypted,SigningRequired"
ServerName ShareName Dialect Encrypted SigningRequired
---------- --------- ------ --------- ---------------
FS-HQ Projects 3.1.1 False True
Ce que ça signifie : Le dialecte 3.1.1 est moderne. Le signing requis est activé ; le chiffrement est désactivé pour ce partage.
Décision : Si vous voyez Dialect 1.0 ou 2.0 de façon inattendue, corrigez la négociation legacy. Si le chiffrement est activé et que la performance est mauvaise, mesurez le CPU et envisagez un chiffrement sélectif.
Task 9: Check SMB client configuration (Windows)
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableSecuritySignature,RequireSecuritySignature,EnableMultiChannel,ConnectionCountPerRssNetworkInterface"
EnableSecuritySignature RequireSecuritySignature EnableMultiChannel ConnectionCountPerRssNetworkInterface
---------------------- ------------------------ ---------------- -------------------------------
True False True 4
Ce que ça signifie : Le client utilisera le signing si le serveur l’exige ; multichannel est activé.
Décision : Si le multichannel provoque des anomalies sur VPN (multiples chemins, NAT), envisagez de le désactiver pour tester sur clients ou serveurs, puis décidez en fonction des preuves.
Task 10: Check SMB server sessions and disconnect reasons (Windows Server)
cr0x@server:~$ powershell -NoProfile -Command "Get-SmbSession | Sort-Object -Descending NumOpens | Select -First 5 | ft ClientComputerName,NumOpens,SessionId,ClientUserName"
ClientComputerName NumOpens SessionId ClientUserName
------------------ -------- --------- --------------
BR-WS-014 27 1125899906842631 CONTOSO\alex
BR-WS-021 19 1125899906842630 CONTOSO\maria
BR-WS-008 12 1125899906842628 CONTOSO\sam
Ce que ça signifie : Des sessions actives existent ; vous pouvez corréler les plaintes de déconnexion avec des clients et comptes spécifiques.
Décision : Si seule une partie des clients est affectée, concentrez‑vous sur leur chemin (Wi‑Fi, VLAN, sécurité endpoint) plutôt que sur le serveur.
Task 11: Look for SMB server-side errors (Windows event log query)
cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName Microsoft-Windows-SMBServer/Operational -MaxEvents 8 | ft TimeCreated,Id,LevelDisplayName,Message -AutoSize"
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
12/27/2025 9:17:10 AM 310 Error The server failed to allocate from the system nonpaged pool because the pool was empty.
12/27/2025 9:16:58 AM 1006 Warning A connection was disconnected due to inactivity.
Ce que ça signifie : « Disconnected due to inactivity » pointe vers des décalages de timeout. Les problèmes de nonpaged pool indiquent une pression mémoire/bugs de drivers (moins fréquent aujourd’hui, mais ça arrive).
Décision : Pour les déconnexions pour inactivité, adressez les timeouts pare‑feu/VPN et les keepalives SMB. Pour les problèmes de pool mémoire, traitez‑les comme un incident de santé serveur.
Task 12: Test raw throughput vs small I/O behavior (Linux, smbclient)
cr0x@server:~$ smbclient //FS-HQ/Projects -U 'CONTOSO\alex' -c 'lcd /tmp; get bigfile.bin'
getting file \bigfile.bin of size 2147483648 as bigfile.bin (38.2 MBytes/sec) (average 38.2 MBytes/sec)
Ce que ça signifie : Un transfert séquentiel majeur est correct. Si les utilisateurs se plaignent encore d’« ouverture de dossiers » lente, votre goulot est probablement la latence des métadonnées, pas la bande passante.
Décision : Concentrez‑vous sur la latence, l’énumération des répertoires, l’anti‑virus et les allers‑retours SMB — pas « upgradez la ligne ».
Task 13: Measure SMB “create/open” latency using a simple loop (Windows client)
cr0x@server:~$ powershell -NoProfile -Command "$p='\\FS-HQ\Projects\latencytest'; 1..20 | % { $t=Measure-Command { Get-ChildItem $p | Out-Null }; '{0} ms' -f [int]$t.TotalMilliseconds }"
182 ms
190 ms
176 ms
415 ms
181 ms
179 ms
Ce que ça signifie : La plupart des mesures sont ~180–190ms, mais des pics à 400ms apparaissent. C’est du jitter. Les utilisateurs perçoivent les pics, pas les moyennes.
Décision : Enquêtez sur la perte/jitter, la saturation CPU du VPN et l’ordonnancement. Envisagez QoS et une capacité matérielle adéquate pour le tunnel.
Task 14: Confirm DNS resolves the file server consistently (Windows client)
cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS-HQ | ft Name,Type,IPAddress"
Name Type IPAddress
---- ---- ---------
FS-HQ A 10.10.1.50
Ce que ça signifie : Le client résout vers l’IP interne. Si ça résout vers une IP publique ou un autre site, votre chemin SMB peut faire un hairpin ou traverser la mauvaise politique de pare‑feu.
Décision : Corrigez le DNS split‑horizon et les définitions site/sous‑réseau AD pour que les clients de succursale utilisent la route prévue.
Task 15: Check time sync (Kerberos sanity) (Windows)
cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 12/27/2025 9:14:21 AM
Source: DC-HQ.contoso.local
Poll Interval: 10 (1024s)
Ce que ça signifie : Le client s’est synchronisé récemment sur une source de domaine. Si l’heure est décalée de minutes, Kerberos et l’établissement de session SMB peuvent échouer ou retomber de façon désagréable.
Décision : Réparez NTP/hiérarchie AD avant de blâmer SMB.
Task 16: See if the file server is storage-bound (Linux NAS example)
cr0x@server:~$ iostat -xz 1 5
avg-cpu: %user %nice %system %iowait %steal %idle
12.44 0.00 4.11 18.32 0.00 65.13
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %util await
nvme0n1 55.0 120.0 7200.0 15600.0 0.0 0.0 92.1 18.4
Ce que ça signifie : Un %util élevé et un await important indiquent que le disque est occupé et que les requêtes attendent ~18ms en moyenne. Cela amplifie la latence SMB, surtout pour les I/O métadonnées.
Décision : Si l’attente du stockage est élevée pendant les plaintes, corrigez le stockage (cache, média plus rapide, séparer les workloads, tuner ZFS/RAID, réduire la pression d’écritures synchrones) avant de toucher au VPN.
Ajustements SMB importants (et ce qu’il faut laisser tranquille)
Tuez SMB1. Ne négociez pas avec lui.
Si SMB1 est activé quelque part « pour compatibilité », il apparaîtra au pire moment : un vieux scanner, un appareil embarqué mystère, ou un poste de travail aux politiques antiques. SMB1 a des problèmes de sécurité connus et de mauvaises caractéristiques de performance. Plus important pour vos utilisateurs : il se comporte mal sous latence.
Règle décisionnelle : si un appareil ne parle que SMB1, isolez‑le ou remplacez‑le. Ne le laissez pas tirer votre environnement entier en 1996.
Signing SMB : exigez‑le là où il le faut, mesurez‑le là où il faut
Le signing fournit l’intégrité (empêche les altérations). Dans les domaines modernes il est souvent requis par la politique. Sur VPN, il est redondant pour la confidentialité (le tunnel chiffre), mais il reste important pour l’intégrité si vous ne faites pas confiance au chemin ou si le tunnel termine à des endroits bizarres.
Réalité opérationnelle : le signing coûte du CPU et peut réduire le débit. Sur CPUs modernes c’est généralement acceptable. Sur un petit NAS ou une VM sous‑dimensionnée, c’est une taxe de performance que vous ressentirez.
Que faire : gardez le signing requis dans les environnements de domaine sauf raison solide de l’enlever. Si les performances plongent, corrigez le dimensionnement CPU et les offloads plutôt que de désactiver le signing par réflexe.
Chiffrement SMB : utilisez‑le chirurgicalement
Le chiffrement SMB est excellent quand :
- Vous avez des segments non fiables entre client et serveur (pas seulement « un VPN », mais peut‑être plusieurs réseaux routés).
- Vous avez besoin d’une sécurité par partage quel que soit le routage.
- Vous ne pouvez pas garantir la couverture VPN pour tous les chemins clients.
Le chiffrement SMB n’est pas idéal quand votre CPU serveur est déjà occupé et que le VPN chiffre déjà tout. Le double chiffrement peut fonctionner ; il peut aussi mener à une lenteur due aux nombreux changements de contexte.
Durable handles et continuous availability : ne confondez pas les fonctionnalités
Les durable handles aident un client à se reconnecter après une courte interruption sans corrompre l’état du fichier ouvert. C’est utile sur VPN car vous aurez des micro‑interruptions : rekeys, roam Wi‑Fi, jitter ISP.
La continuous availability est une autre bête : liée aux clusters de serveurs de fichiers et à des réglages spéciaux de partage. Si vous n’avez pas cette infrastructure, n’attendez pas de miracles. Vous pouvez quand même obtenir de la stabilité, simplement pas les sémantiques d’un NAS clusterisé gratuitement.
OpLocks/leases : booster de performance avec un tranchant
Dans la plupart des workflows documentaires de bureau, les leases réduisent les allers‑retours et accélèrent tout. Sur des partages utilisés par des applications métier, CAD ou tout ce qui a des comportements de verrouillage étranges, ils peuvent se traduire par des conflits « fichier en cours d’utilisation » ou une visibilité retardée des changements.
Ne les désactivez pas globalement à cause d’une application pénible. Isolez cette charge de travail dans son propre partage ou serveur et ajustez‑y les réglages spécifiquement.
Ajustements VPN et réseau pour SMB
MTU : le tueur silencieux des « gros fichiers qui plantent »
L’encapsulation VPN réduit le MTU effectif. Si vous gardez 1500 sur tout le réseau Ethernet mais ajoutez le overhead IPsec ESP ou OpenVPN, vous pouvez dépasser la véritable Path MTU. Si PMTUD est bloqué (commun sur des pare‑feu zélés), les paquets sont perdus au lieu d’être fragmentés, et TCP se bloque. SMB ressemble alors à des « déconnexions aléatoires », souvent pendant de grosses écritures.
Faites ceci : décidez du MTU effectif pour le tunnel, réglez‑le explicitement sur l’interface VPN, et clampiez le MSS pour les paquets SYN TCP traversant le tunnel. Oui, même en 2025. PMTUD reste un livre d’aventures à choix multiples.
Timeouts d’état du pare‑feu : adaptez‑les au comportement humain, pas au labo
Les humains ouvrent un fichier, réfléchissent, vont déjeuner et laissent le fichier ouvert. SMB garde l’état et peut envoyer des keepalives, mais votre pare‑feu peut ne pas les respecter ou avoir une logique d’« idle timeout VPN » séparée.
Si les utilisateurs se déconnectent après exactement 30 ou 60 minutes, ce n’est pas SMB capricieux. C’est une minuterie. Trouvez‑la et corrigez‑la.
QoS : priorisez ce qui fait le plus mal
SMB n’est pas que du flux massif. C’est aussi beaucoup de petites opérations « de contrôle ». Si votre lien est saturé par des sauvegardes, des appels vidéo ou quelqu’un synchronisant une image de VM, les appels métadonnées SMB passent derrière le trafic massif, et chaque ouverture de dossier ressemble à de la mélasse.
Priorisez TCP/445 et aussi les classes de trafic encapsulées VPN si nécessaire. Mais faites‑le avec précaution : « priorité » ne veut pas dire « laisser tout le reste crever ». Ça veut dire « réduire la latence de pointe pour les opérations interactives ».
Split tunneling : décidez selon le risque et la bande passante, pas selon l’intuition
Pour les VPN site‑à‑site, vous voulez généralement un routage complet entre les sites mais pas nécessairement « tout le trafic internet via HQ ». Hairpinner le trafic internet via HQ augmente la latence et la charge, et peut concurrencer SMB. D’un autre côté, si votre posture de sécurité exige un egress centralisé, acceptez que vous payiez pour cela et dimensionnez les circuits en conséquence.
Blague #2 : Si votre appliance VPN est aussi votre DNS, DHCP, IDS et machine à café, ne soyez pas surpris si le partage de fichiers a un goût de brûlé.
Réalités du backend de stockage (NAS, Windows, ZFS, VM)
Les problèmes de fiabilité SMB sont souvent mal diagnostiqués en « problème réseau » parce que le symptôme est une déconnexion. Mais les blocages de stockage et la surcharge serveur se manifestent de la même façon : le serveur ne répond plus assez vite, le client réessaie, la session est déchirée par quelque chose d’impatient au milieu.
La latence disque bat la bande passante dans le partage de bureau
Les partages de bureau sont majoritairement des I/O aléatoires petites : métadonnées, petits écrits, beaucoup de renommages et fichiers temporaires. Un serveur qui peut faire 1 Gbps en transfert séquentiel mais a des IOPS aléatoires médiocres semblera lent. Les utilisateurs n’établissent pas un benchmark avec une copie de 2 Go ; ils ouvrent un dossier avec 20 000 petits fichiers et veulent des miniatures.
Virtualisation : les voisins bruyants existent
Si votre serveur de fichiers est une VM sur un hyperviseur occupé, vos « déconnexions aléatoires » peuvent être du au CPU ready, à la latence stockage du datastore partagé ou à un problème de queue vNIC. L’ajustement VPN ne réparera pas un hôte sur‑alloué.
ZFS et SMB : bon combo, mais comprenez les écritures synchrones
Sur NAS à base ZFS (ou tout stockage axé intégrité), les écritures synchrones peuvent être coûteuses. Les charges SMB avec certains flags et comportements applicatifs peuvent forcer des sémantiques de sync. Si votre SLOG (dispositif de log séparé) est absent ou lent, vos opérations de « sauvegarde » peuvent se bloquer. Le réseau reste up ; l’application sature et time‑outte quand même.
Opérationnellement : mesurez await, mesurez le CPU, mesurez les hit rates ARC si applicable, et maintenez le service SMB sur une voie de stockage stable et basse‑latence. Mettez les backups ailleurs.
Antivirus et indexation de contenu : la taxe cachée
Le scan en temps réel sur le serveur pour chaque ouverture/lecture peut ruiner les performances. Idem pour l’indexation Windows Search sur le partage. Sur VPN, les utilisateurs cliqueront sur « ouvrir » et attendront pendant que le serveur scanne, indexe, puis répond.
Soyez disciplinés : excluez types et chemins de fichiers appropriés, spécialement pour les gros formats binaires qui changent fréquemment. Testez avec les équipes de sécurité, ne bricolez pas. Mais n’acceptez pas « scanner tout tout le temps » si ça casse le business.
Trois micro‑histoires du monde de l’entreprise
Micro‑histoire 1 : L’incident causé par une mauvaise hypothèse
La configuration semblait propre. HQ avait un serveur de fichiers. Deux succursales se connectaient via un tunnel IPsec. Tout le monde mappait par nom de serveur. L’équipe réseau jurait que le VPN était stable parce que le tunnel montrait « up » et que les pings fonctionnaient.
Les plaintes ne correspondaient pas à cette image propre. Les utilisateurs de la succursale A se faisaient déconnecter trois à cinq fois par jour, généralement en milieu d’après‑midi. La succursale B était correcte. Le helpdesk a escaladé en « SMB instable sur VPN », et l’instinct initial fut de bidouiller les timeouts SMB sur les clients.
La mauvaise hypothèse était que « tunnel up » signifie « tunnel sain ». En réalité, le pare‑feu HQ faisait du routage basé sur la politique pour certains sous‑réseaux et du routage basé sur les routes pour d’autres. Le trafic de retour de la succursale A prenait parfois un chemin WAN différent lors d’événements de load‑balancing ISP. Le routage asymétrique signifiait des drops par le pare‑feu stateful. Les flux TCP/445 mouraient silencieusement. SMB faisait alors ce qu’il fait : il réessayait, puis abandonnait, puis l’application paniquait.
La correction n’a pas été un réglage SMB. C’était rendre le routage symétrique et faire en sorte que la table d’état du pare‑feu voie les deux directions sur le même chemin. Après cela, les déconnexions ont pratiquement disparu. Les seuls problèmes restants étaient liés aux performances, ce qui est le genre de problème que l’on peut programmer.
Micro‑histoire 2 : L’optimisation qui s’est retournée contre eux
Une autre entreprise avait un vrai problème de bande passante. Ils poussaient des fichiers de conception volumineux de la succursale vers HQ toute la journée, et le lien était saturé. Quelqu’un a eu l’idée brillante d’activer le chiffrement SMB « parce que la sécurité le veut de toute façon », et simultanément d’activer la compression au niveau VPN pour « gagner en débit ».
En petit test, ça semblait bien. Puis la production est arrivée. Le CPU de l’appliance VPN a plafonné sous charge. Les opérations SMB ont commencé à time‑outter. Les utilisateurs signalaient que l’enregistrement d’un fichier finissait parfois, parfois bloquait, parfois renvoyait « network name no longer available ». Échec intermittent classique, qui ruine les week‑ends.
Le retournement était prévisible rétrospectivement : les données chiffrées se compressent mal, donc la compression VPN ajoutait de l’overhead sans gain. Le chiffrement SMB ajoutait plus de CPU sur les endpoints. L’effet combiné a augmenté latence et jitter — exactement ce que SMB déteste. Le débit n’a pas augmenté ; la latence de queue a empiré. Les opérations interactives ont souffert même quand la bande passante n’était pas pleinement utilisée car le CPU était le goulot.
La solution d’état stable a été banale : désactiver la compression VPN, garder le signing SMB, n’activer le chiffrement SMB que sur quelques partages sensibles, et upgrader le hardware VPN pour que le crypto ne concurrence pas le routage. Ils ont ensuite implémenté QoS pour que les transferts massifs n’écrasent pas le trafic métadonnées SMB interactif.
Micro‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Celle‑ci est moins dramatique, ce qui est le but. Une entreprise de taille moyenne avait quatre bureaux et un cluster de fichiers central. Ils avaient une règle : chaque trimestre, ils faisaient un « exercice de partage de fichiers WAN ». Pas un exercice table‑top — un test réel où ils mesuraient latence, perte de paquets, stats de connexions SMB et latence stockage sous charge contrôlée.
Ils avaient aussi une norme pas glamour : tous les bords VPN de bureau avaient les mêmes réglages MTU, règles de clamp MSS et politiques de timeout documentées. À chaque remplacement de pare‑feu, ils appliquaient la même baseline avant la mise en production. Pas de « on ajustera plus tard ». Le plus tard, c’est quand les utilisateurs crient.
Un jour, un ISP a changé quelque chose en amont et PMTUD a cessé de fonctionner de façon fiable pour un bureau. En quelques heures, leur supervision a détecté une augmentation des retransmissions TCP et de la latence d’ouverture SMB. Le helpdesk n’a presque pas eu de tickets car l’équipe a proactivement réduit le MTU sur ce tunnel et ajusté le clamp MSS avant que les utilisateurs ne remarquent grand‑chose.
La pratique n’était pas fancy. Elle était répétable et baseline. Elle a sauvé la mise précisément parce qu’elle était ennuyeuse et donc faite régulièrement.
Erreurs fréquentes : symptôme → cause racine → correction
Voici les motifs qui reviennent sans cesse. L’astuce est de cesser de les traiter comme des mystères.
1) Symptom: « Works for small files, hangs on large copies »
Cause racine : MTU/PMTUD blackhole sur VPN ; fragmentation bloquée ; MSS trop élevé.
Fix : Déterminez le MTU effectif avec des pings DF ; réglez le MTU de l’interface VPN ; clampiez le MSS TCP aux bords du tunnel ; assurez‑vous que les ICMP « frag needed » ne sont pas bloqués.
2) Symptom: Disconnects after exactly 30/60 minutes of idle
Cause racine : Timeout d’inactivité du pare‑feu/VPN plus court que les attentes de session SMB ; expiration de table NAT.
Fix : Augmentez les timeouts TCP established ; configurez keepalives/DPD VPN ; vérifiez les dispositifs intermédiaires (CPE ISP inclus) qui pourraient tuer les flux.
3) Symptom: Slow “open file” but fast big file copy
Cause racine : Latence et bavardise métadonnées ; scan AV ; énumération de répertoire ; await stockage élevé pour petites I/O.
Fix : Mesurez la latence d’ouverture et l’await stockage ; ajustez exclusions AV ; réduisez la taille des dossiers ; envisagez mise en cache locale/DFS pour ce partage.
4) Symptom: Only one office has issues, others fine
Cause racine : Routage asymétrique ; perte locale ISP ; Wi‑Fi/VLAN ; DNS résolvant vers le mauvais serveur.
Fix : Validez la symétrie de route avec ip route get ; lancez mtr depuis les deux bouts ; confirmez la résolution DNS et le mapping site AD.
5) Symptom: “Network name no longer available” during saves
Cause racine : Flap/rekey du tunnel provoquant reset TCP ; pare‑feu supprimant l’état ; pause serveur (blocage stockage) assez longue pour que le client abandonne.
Fix : Vérifiez les logs VPN pour renégociations ; vérifiez conntrack/timeouts d’état ; surveillez la latence disque et le CPU ready du serveur.
6) Symptom: Authentication prompts or “access denied” intermittently
Cause racine : Kerberos échouant à cause de dérive horaire/DNS ; bascule en NTLM ; contrôleur de domaine intermittemment accessible via VPN.
Fix : Corrigez la synchronisation horaire ; assurez‑vous que les clients atteignent un DC local ou un DC reachable de façon fiable ; validez les SPN ; nettoyez le DNS split.
7) Symptom: Throughput is low only when encryption/signing enabled
Cause racine : Limitation CPU sur serveur/NAS/appliance VPN ; absence d’accélération crypto ; overhead double chiffrement.
Fix : Mesurez le CPU sous charge ; montez en puissance ; activez l’accélération matérielle si disponible ; utilisez le chiffrement de façon sélective par partage.
8) Symptom: Random “file locked” conflicts across offices
Cause racine : Application qui gère mal leases/oplocks ; attentes de cache incompatibles ; comportement de conflit de réplication (DFS‑R).
Fix : Pour ce workload : partage séparé, ajustement prudent de la stratégie oplock/lease, ou refonte du workflow (ne pas éditer le même fichier depuis deux sites via réplication).
Listes de vérification / plan étape par étape
Plan étape par étape : stabiliser SMB entre bureaux en 10 mouvements
- Inventoriez le chemin. Dessinez le vrai chemin des paquets : client → switch/Wi‑Fi → routeur succursale → ISP → bord HQ → pare‑feu → VLAN serveur → serveur. Incluez les dispositifs NAT.
- Mesurez la latence, le jitter et la perte de base. Utilisez mtr et des boucles d’ouverture de fichier pendant les heures de pointe.
- Verrouillez MTU/MSS. Choisissez un MTU qui survit à l’encapsulation. Réglez‑le. Clampiez le MSS. Vérifiez avec des pings DF.
- Vérifiez la symétrie de routage. Confirmez que les chemins de retour utilisent le même tunnel, pas « la route par défaut qui gagne aujourd’hui ».
- Corrigez DNS et mapping AD site. Assurez‑vous que les clients de succursale résolvent correctement les serveurs de fichiers et atteignent les bons contrôleurs de domaine.
- Alignez les timeouts. Timeouts TCP established du pare‑feu, timers idle VPN et DPD/keepalives doivent supporter des sessions ouvertes de plusieurs heures.
- Instrumentez le serveur. Surveillez l’attente disque, le CPU, les événements SMB et les erreurs NIC. Prouvez que le serveur n’est pas le goulot.
- Contrôlez le trafic de fond. Appliquez QoS ou planifiez les backups/sync pour que le SMB interactif ne soit pas mis en file derrière du trafic bulk.
- Arrêtez les workloads hostiles au WAN. Ne mettez pas de PST Outlook sur SMB à travers un VPN. N’éditez pas de gros assemblages CAD directement depuis un partage distant sauf si vous aimez la douleur.
- Choisissez une architecture long terme. Si latence/perte sont inévitables, déployez mise en cache/replication locale ou migrez la collaboration hors SMB.
Checklist : à quoi ressemble le « bon »
- MTU connu et validé de bout en bout ; pas de PMTU blackholes.
- Le tunnel ne clignote pas et ne rékeye pas d’une façon qui détruit les flux TCP actifs.
- La perte est proche de zéro aux bords de succursale ; le jitter est modéré.
- Les timeouts d’état du pare‑feu supportent des sessions longue durée (heures).
- Le DNS est déterministe pour les noms de serveur de fichiers ; pas de résolutions publiques surprises.
- La latence de stockage serveur reste basse en pointe ; le scanning AV est contrôlé.
- Le dialecte SMB est moderne (3.x) et SMB1 est désactivé.
FAQ
1) Devons‑nous utiliser IPsec ou WireGuard/OpenVPN pour SMB ?
Utilisez ce que votre équipe peut opérer de façon fiable. Pour SMB, la stabilité et un comportement MTU prévisible comptent plus que la marque. Les VPN basés sur routage sont généralement plus faciles à raisonner que les tunnels basés sur politique, surtout à l’échelle multi‑sous‑réseaux.
2) SMB sur VPN est‑il « supporté » pour le travail de bureau en production ?
Oui, dans certaines limites. Si vous avez une latence constante et minimale et peu de perte, ça peut être parfaitement acceptable. Si votre WAN est peu fiable ou à haute latence, vous finirez par bricoler autour de la physique — utilisez cache/replication locale ou changez le workflow.
3) Pourquoi les lecteurs mappés se déconnectent‑ils quand personne ne copie de fichiers ?
Parce que « inactif » pour un humain signifie encore « session ouverte » pour le protocole. Les pare‑feu, NAT et dispositifs VPN expirent les flux. Alignez les timeouts et activez des keepalives pour que le réseau se souvienne que la session existe.
4) Augmenter les délais SMB sur les clients corrige‑t‑il les déconnexions ?
Parfois ça masque les symptômes, mais rarement ça corrige la cause racine. Si un dispositif intermédiaire supprime l’état TCP, le client peut attendre plus longtemps et se faire quand même couper. Corrigez MTU, perte, symétrie de routage et timeouts du pare‑feu en priorité.
5) Devons‑nous activer le chiffrement SMB si nous avons déjà un VPN ?
Seulement si vous avez besoin d’une défense en profondeur au niveau applicatif ou un routage complexe où le trafic peut contourner le VPN. Sinon, conservez le signing et reposez‑vous sur le chiffrement VPN. Mesurez le CPU avant et après si vous activez le chiffrement SMB.
6) Pourquoi la navigation dans les dossiers est‑elle lente mais la copie de fichiers rapide ?
La navigation déclenche beaucoup de petites opérations métadonnées. Sur un WAN, elles sont liées à la latence. La copie déclenche du débit et du pipelining. Corrigez latence/jitter, réduisez la taille des dossiers, contrôlez le scan AV ou utilisez des réplicas locaux.
7) DFS peut‑il résoudre nos problèmes SMB multi‑bureaux ?
DFS Namespaces peut résoudre les problèmes de nommage et de renvoi et faciliter les migrations. DFS Replication peut réduire le trafic inter‑sites pour des datasets adaptés. Il ne rendra pas « l’édition du même fichier depuis deux sites » sûre.
8) Quelle est la cause la plus commune de « hangs SMB aléatoires » sur VPN ?
Les problèmes MTU/PMTUD sont classiques, surtout quand quelqu’un a activé des jumbo frames en interne en oubliant l’overhead VPN. La deuxième cause la plus courante est le timeout d’état du pare‑feu qui ne correspond pas aux sessions SMB longue durée.
9) Devons‑nous désactiver SMB multichannel sur les liens VPN ?
Testez‑le. Le multichannel peut aider sur des réseaux bien conçus et nuire quand vous avez du NAT, plusieurs chemins ou du routage asymétrique. Ne copiez pas aveuglément : mesurez le comportement des connexions et décidez selon la stabilité.
10) Est‑il acceptable d’exécuter des bases de données ou des fichiers PST sur SMB à travers des bureaux ?
« Acceptable » est fort. Beaucoup d’applications se comportent mal sur SMB WAN car elles supposent une latence LAN et des locks stables. Si vous devez le faire, redesign : serveurs d’application locaux, remote desktop vers HQ, ou une approche de réplication supportée.
Conclusion : prochaines étapes pratiques
Si vous voulez du SMB entre bureaux sans déconnexions constantes, cessez de le traiter comme une fonctionnalité de copie de fichiers et commencez à le traiter comme un service distribué avec des dépendances strictes.
Faites ceci ensuite :
- Exécutez le mode opératoire de diagnostic rapide pendant les heures de pointe et capturez des preuves : perte/jitter, MTU, routage, timeouts, latence stockage serveur.
- Corrigez MTU/MSS et les timeouts d’état en priorité. Ce sont les deux premiers générateurs de « déconnexions aléatoires ».
- Instrumentez le serveur et le stockage pour distinguer « réseau lent » de « disque lent » en minutes, pas en jours.
- Décidez d’une architecture volontaire : serveur central si la latence est faible et stable ; DFS/mise en cache/serveurs locaux si ce n’est pas le cas ; ou migrez la collaboration hors SMB si les utilisateurs éditent cross‑site toute la journée.
Le but final est la fiabilité ennuyeuse : le partage reste monté, les ouvertures de fichiers sont prévisibles et personne n’apprend ce que signifie « SMB session teardown ». Gardez‑le ainsi.