Filkopior kollapsar när VPN:en ansluter: SMB-multikanal

En filkopia mellan två Windows-datorer är snabb tills båda ansluter till samma VPN, och då kollapsar den medan ett genomströmningstest över samma par fortfarande rapporterar nästan linjehastighet. Den skillnaden är diagnosen: länken är frisk och något väljer en sämre väg för själva överföringen. Det något är oftast SMB3-multikanal, som gör precis det den konstruerades för. Ta bort den extra kanalen och kopian återgår till den fysiska länken.

Symtomet väntar på sin långsammaste kanal

Multikanal låter en SMB-session använda flera TCP-anslutningar, en per lämpligt adresspar mellan klient och server. När båda datorerna sitter på LAN:et och i samma tunnel kan Windows para ihop LAN-adresserna med tunneladresserna och behandla båda paren som användbara. Sessionen har till slut fler kanaler än den fysiska länken behöver, och en av dem är mycket långsammare.

Det misslyckas inte. Det väntar, eftersom sessionen inte kan bli klar snabbare än sin långsammaste kanal.

Därför kan ett bandbreddstest se friskt ut medan en kopia kryper: en mätning av ett enda flöde väljer kanske en väg, medan överföringen var utspridd över två. Läs kanallistan innan du ändrar någon adapterinställning, och läs den medan kopian fortfarande körs, för en inaktiv session visar ingenting. Det du skriver ner bör namnge gränssnittet bakom varje kanal, inte bara hur långsamt resultatet kändes.

Bekräfta att det finns en andra kanal

Två cmdletar svarar direkt på frågan. Anslutningslistan visar kanalerna som används, och sessionssammanfattningen visar själva anslutningen. Kör båda under den långsamma kopian.

Get-SmbMultichannelConnection
Get-SmbConnection

Leta efter mer än en rad markerad som vald för samma server, och slå sedan upp klientadressen i den misstänkta raden. Om adressen tillhör tunneladaptern är den andra vägen verklig och bekräftad. Om varje rad tillhör det fysiska gränssnittet är multikanal inte ditt problem och kopian är långsam av en orelaterad anledning. Gör den bekräftelsen först, eftersom reparationen är störande nog att förtjäna en minut av bevis.

Get-NetIPAddress -IPAddress 10.20.30.44

Adresserna här är platshållare. Byt ut dem mot det din egen utdata rapporterar, för att kopiera en adress från en blogg är sättet en fungerande kommandoraden blir ett förvirrande felmeddelande.

Ta bort tunneln från SMB och mät sedan igen

Att stänga av multikanal är det snabbaste sättet att bekräfta diagnosen, och det är reversibelt. Använd klientinställningen på datorn som kopierar och serverinställningen på datorn som är värd för utdelningen, eftersom varje sida för sig kan hålla den extra kanalen vid liv. Ändringen gäller nya anslutningar och inte befintliga, så en öppen session överlever den. Starta om båda datorerna, eller stäng åtminstone varje handtag mot utdelningen, innan du mäter något.

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

Bekräfta det nya tillståndet och se sedan vad servern annonserar till klienterna nu.

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

Tunnelgränssnittet bör falla bort från den annonserade listan. Om det inte gör det har inställningen landat på fel ände, eller så är en gammal session fortfarande öppen. Om filutdelningen helt enkelt inte får använda tunneln, koppla i stället loss serverkomponenten från den adaptern, vilket lämnar tunneln användbar för alla andra tjänster.

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

Föredra LAN-vägen utan att låtsas att den raderar kanaler

En gränssnittsmetrik talar om för Windows vilken väg som ska föredras för nya anslutningar. Den tar inte bort en kanal som multikanal redan har beslutat att öppna. Att höja tunnelns metrik är ändå värt det, eftersom det håller orelaterad trafik borta från den långsamma vägen och gör den föredragna vägen förutsägbar, men det är en knuff, inte ett filter.

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

Kopiera aliaset från den utdatan i stället för att skriva det, eftersom vissa installationer lokaliserar adapternamnet och den engelska strängen inte kommer att matcha.

Mät sedan båda siffrorna igen: filkopian och ett genomströmningstest över samma par. Om kopian återhämtar sig medan genomströmningstestet aldrig var långsamt, var multikanal orsaken och du kan sluta. Om båda kollapsar, är tunneln flaskhalsen och multikanal förstärkte den bara. Om kopian förblir långsam medan båda vägarna ser korrekta ut, bor det kvarvarande problemet i utdelningen, lagringen eller en filterdrivrutin, vilket är en annan utredning.