Filkopiering går i stå, når VPN’en kobler til: SMB-multikanal

En filkopi mellem to Windows-maskiner er hurtig, indtil begge melder sig på samme VPN, og så bryder den sammen, mens en gennemstrømningstest over det samme par stadig rapporterer tæt på linjehastigheden. Det gab er diagnosen: forbindelsen er fin, og noget vælger en dårligere vej for selve overførslen. Det noget er som regel SMB3-multikanal, som gør præcis det, den blev designet til. Tag den ekstra kanal ud af billedet, og kopien vender tilbage til den fysiske forbindelse.

Symptomet venter på sin langsomste kanal

Multikanal lader én SMB-session bruge flere TCP-forbindelser, én pr. passende adressepar mellem klient og server. Når begge maskiner sidder på LAN’et og på samme tunnel, kan Windows parre LAN-adresserne og tunneladresserne og behandle begge par som brugbare. Sessionen ender med flere kanaler, end den fysiske forbindelse har brug for, og en af dem er langt langsommere.

Den fejler ikke. Den venter, fordi sessionen ikke kan blive færdig hurtigere end sin langsomste kanal.

Derfor kan en båndbreddetest se sund ud, mens en kopi kravler: en enkeltstrømsmåling vælger måske én vej, mens overførslen var spredt over to. Læs kanallisten, før du ændrer nogen adapterindstilling, og læs den, mens kopien stadig kører, for en inaktiv session viser intet. Det, du skriver ned, skal navngive det interface, der ligger bag hver kanal, ikke bare hvor langsomt resultatet føltes.

Bekræft, at der findes en anden kanal

To cmdlet’er besvarer spørgsmålet direkte. Forbindelseslisten viser de kanaler, der er i brug, og sessionsoversigten viser selve forbindelsen. Kør begge under den langsomme kopi.

Get-SmbMultichannelConnection
Get-SmbConnection

Led efter mere end én række markeret som valgt for samme server, og slå derefter klientadressen i den mistænkelige række op. Hvis den adresse hører til tunneladapteren, er den anden vej virkelig og bekræftet. Hvis hver række hører til det fysiske interface, er multikanal ikke dit problem, og kopien er langsom af en uvedkommende grund. Foretag den bekræftelse først, fordi reparationen er forstyrrende nok til at fortjene et minut med beviser.

Get-NetIPAddress -IPAddress 10.20.30.44

Adresserne her er pladsholdere. Erstat dem med det, din egen udskrift rapporterer, for at kopiere en adresse fra en blog er måden, hvorpå en fungerende kommando bliver en forvirrende fejlmeddelelse.

Tag tunnelen ud af SMB, og mål derefter igen

At slå multikanal fra er den hurtigste måde at bekræfte diagnosen på, og det er reversibelt. Anvend klientindstillingen på den maskine, der kopierer, og serverindstillingen på den maskine, der hoster sharen, fordi hver side alene kan holde den ekstra kanal i live. Ændringen gælder nye forbindelser og ikke eksisterende, så en åben session overlever den. Genstart begge maskiner, eller luk i det mindste hvert håndtag til sharen, før du måler noget.

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

Bekræft den nye tilstand, og se derefter, hvad serveren nu annoncerer til klienterne.

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

Tunnel-interfacet bør falde ud af den annoncerede liste. Hvis ikke, er indstillingen landet på den forkerte ende, eller en gammel session er stadig åben. Hvis fildeling simpelthen ikke må bruge tunnelen, skal du i stedet afkoble serverkomponenten fra den adapter, hvilket efterlader tunnelen brugbar for enhver anden tjeneste.

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

Foretræk LAN-vejen uden at foregive, at den fjerner kanaler

En interface-metrik fortæller Windows, hvilken vej der skal foretrækkes for nye forbindelser. Den fjerner ikke en kanal, som multikanal allerede har besluttet at åbne. At hæve tunnelens metrik er stadig værd at gøre, fordi det holder uvedkommende trafik væk fra den langsomme vej og gør den foretrukne rute forudsigelig, men det er et puf, ikke et filter.

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

Kopiér aliaset ud af den udskrift i stedet for at skrive det, fordi nogle installationer oversætter adapternavnet, og den engelske streng vil ikke matche.

Mål derefter begge tal igen: filkopien og en gennemstrømningstest over det samme par. Hvis kopien kommer sig, mens gennemstrømningstesten aldrig var langsom, var multikanal årsagen, og du kan stoppe. Hvis begge bryder sammen, er tunnelen flaskehalsen og multikanal forstærkede den blot. Hvis kopien forbliver langsom, mens begge veje ser korrekte ud, bor det resterende problem i sharen, lageret eller en filterdriver, hvilket er en anden undersøgelse.