Les copies de fichiers s’effondrent quand le VPN se connecte : multicanal SMB

La copie d’un fichier entre deux machines Windows est rapide jusqu’à ce que toutes deux rejoignent le même VPN, et elle s’effondre alors qu’un test de débit sur la même paire annonce toujours une vitesse proche de celle de la ligne. Cet écart est le diagnostic : la liaison est bonne et quelque chose choisit un chemin moins bon pour le transfert lui-même. Ce quelque chose est généralement le multicanal SMB3, qui fait exactement ce pour quoi il a été conçu. Retirez le canal supplémentaire de l’équation et la copie revient sur la liaison physique.

Le symptôme attend son canal le plus lent

Le multicanal permet à une session SMB d’utiliser plusieurs connexions TCP, une par paire d’adresses appropriée entre le client et le serveur. Quand les deux machines se trouvent sur le LAN et sur le même tunnel, Windows peut apparier les adresses du LAN avec celles du tunnel et considérer les deux paires comme utilisables. La session finit avec plus de canaux que la liaison physique n’en a besoin, et l’un d’eux est bien plus lent.

Elle n’échoue pas. Elle attend, car la session ne peut pas se terminer plus vite que son canal le plus lent.

C’est pourquoi un test de bande passante peut sembler sain pendant qu’une copie rampe : une mesure mono-flux peut choisir un chemin, alors que le transfert était réparti sur deux. Lisez la liste des canaux avant de modifier le moindre réglage d’adaptateur, et lisez-la pendant que la copie tourne encore, car une session inactive ne montre rien. Ce que vous notez doit nommer l’interface derrière chaque canal, pas seulement la lenteur ressentie du résultat.

Confirmez qu’un second canal existe

Deux cmdlets répondent directement à la question. La liste des connexions montre les canaux en service, et le résumé de session montre la connexion elle-même. Exécutez les deux pendant la copie lente.

Get-SmbMultichannelConnection
Get-SmbConnection

Cherchez plus d’une ligne marquée comme sélectionnée pour le même serveur, puis résolvez l’adresse client de la ligne suspecte. Si cette adresse appartient à l’adaptateur du tunnel, le second chemin est réel et confirmé. Si toutes les lignes appartiennent à l’interface physique, le multicanal n’est pas votre problème et la copie est lente pour une raison sans rapport. Faites cette confirmation d’abord, car la réparation est assez perturbante pour mériter une minute de preuves.

Get-NetIPAddress -IPAddress 10.20.30.44

Les adresses ici sont des espaces réservés. Remplacez-les par ce que votre propre sortie indique, car copier une adresse depuis un blog est la façon dont une commande qui fonctionne devient un message d’erreur déroutant.

Retirez le tunnel de SMB, puis mesurez à nouveau

Désactiver le multicanal est le moyen le plus rapide de confirmer le diagnostic, et c’est réversible. Appliquez le réglage client sur la machine qui copie et le réglage serveur sur la machine qui héberge le partage, car chaque côté à lui seul peut maintenir le canal supplémentaire en vie. Le changement s’applique aux nouvelles connexions et non aux existantes, donc une session ouverte y survit. Redémarrez les deux machines, ou au moins fermez tous les handles du partage, avant de mesurer quoi que ce soit.

Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -Force

Confirmez le nouvel état, puis regardez ce que le serveur annonce désormais aux clients.

Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbServerNetworkInterface | Format-List *

L’interface du tunnel devrait disparaître de cette liste annoncée. Si ce n’est pas le cas, le réglage a atterri sur le mauvais point de terminaison ou une ancienne session est encore ouverte. Si le partage de fichiers ne doit simplement pas utiliser le tunnel, déliez plutôt le composant serveur de cet adaptateur, ce qui laisse le tunnel utilisable pour tous les autres services.

Get-NetAdapterBinding -Name "OpenVPN Data Channel Offload"
Disable-NetAdapterBinding -Name "OpenVPN Data Channel Offload" -ComponentID ms_server

Préférez le chemin du LAN sans prétendre qu’il supprime des canaux

La métrique d’une interface indique à Windows quel chemin préférer pour les nouvelles connexions. Elle ne supprime pas un canal que le multicanal a déjà décidé d’ouvrir. Relever la métrique du tunnel vaut quand même la peine, car cela éloigne le trafic sans rapport du chemin lent et rend l’itinéraire préféré prévisible, mais c’est une petite poussée, pas un filtre.

Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000

Copiez l’alias depuis cette sortie au lieu de le taper, car certaines installations traduisent le nom de l’adaptateur et la chaîne anglaise ne correspondra pas.

Mesurez ensuite à nouveau les deux chiffres : la copie du fichier et un test de débit sur la même paire. Si la copie récupère alors que le test de débit n’a jamais été lent, le multicanal était la cause et vous pouvez vous arrêter. Si les deux s’effondrent, le tunnel est le goulot d’étranglement et le multicanal n’a fait que l’amplifier. Si la copie reste lente alors que les deux chemins semblent corrects, le problème restant vit dans le partage, le stockage ou un pilote de filtre, ce qui est une autre enquête.