Bestandskopieën storten in zodra de VPN verbindt: SMB-multichannel

Een bestand kopiëren tussen twee Windows-machines is snel tot beide aan dezelfde VPN deelnemen, en dan stort het in terwijl een doorvoertest over hetzelfde paar nog steeds bijna lijnsnelheid meldt. Dat verschil is de diagnose: de verbinding is in orde en iets kiest een slechter pad voor de overdracht zelf. Dat iets is meestal SMB3-multichannel, dat precies doet waarvoor het is ontworpen. Haal het extra kanaal uit het beeld en de kopie keert terug naar de fysieke verbinding.

Het symptoom wacht op zijn traagste kanaal

Multichannel laat één SMB-sessie meerdere TCP-verbindingen gebruiken, één per geschikt adrespaar tussen client en server. Wanneer beide machines op de LAN en op dezelfde tunnel zitten, kan Windows de LAN-adressen en de tunneladressen paren en beide paren als bruikbaar beschouwen. De sessie houdt uiteindelijk meer kanalen over dan de fysieke verbinding nodig heeft, en één ervan is veel trager.

Het faalt niet. Het wacht, omdat de sessie niet sneller klaar kan zijn dan zijn traagste kanaal.

Daarom kan een bandbreedtetest gezond lijken terwijl een kopie kruipt: een meting van één stream kiest misschien één pad, terwijl de overdracht over twee was verdeeld. Lees de kanalenlijst voordat u een adapterinstelling wijzigt, en lees hem terwijl de kopie nog loopt, want een inactieve sessie toont niets. Wat u opschrijft hoort de interface achter elk kanaal te noemen, niet alleen hoe traag het resultaat aanvoelde.

Bevestig dat er een tweede kanaal bestaat

Twee cmdlets beantwoorden de vraag rechtstreeks. De verbindingslijst toont de kanalen in gebruik, en de sessiesamenvatting toont de verbinding zelf. Voer beide uit tijdens de trage kopie.

Get-SmbMultichannelConnection
Get-SmbConnection

Zoek naar meer dan één rij die als geselecteerd is gemarkeerd voor dezelfde server, en los dan het clientadres in de verdachte rij op. Als dat adres bij de tunneladapter hoort, is het tweede pad echt en bevestigd. Als elke rij bij de fysieke interface hoort, is multichannel niet uw probleem en is de kopie traag om een ongerelateerde reden. Doe die bevestiging eerst, want de reparatie is storend genoeg om een minuut bewijs te verdienen.

Get-NetIPAddress -IPAddress 10.20.30.44

De adressen hier zijn plaatsaanduidingen. Vervang ze door wat uw eigen uitvoer meldt, want een adres van een blog kopiëren is de manier waarop een werkend commando een verwarrende foutmelding wordt.

Haal de tunnel uit SMB en meet daarna opnieuw

Multichannel uitschakelen is de snelste manier om de diagnose te bevestigen, en het is omkeerbaar. Pas de clientinstelling toe op de machine die kopieert en de serverinstelling op de machine die de share host, want elke kant alleen kan het extra kanaal in leven houden. De wijziging geldt voor nieuwe verbindingen en niet voor bestaande, dus een open sessie overleeft hem. Herstart beide machines, of sluit ten minste elke handle naar de share, voordat u iets meet.

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

Bevestig de nieuwe toestand en kijk dan wat de server nu aan clients aankondigt.

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

De tunnelinterface zou uit die aangekondigde lijst moeten vallen. Gebeurt dat niet, dan is de instelling op het verkeerde uiteinde beland of is een oude sessie nog open. Als bestandsdeling simpelweg de tunnel niet mag gebruiken, ontkoppel dan in plaats daarvan de servercomponent van die adapter, waardoor de tunnel bruikbaar blijft voor elke andere dienst.

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

Geef het LAN-pad voorrang zonder te doen alsof het kanalen verwijdert

Een interfacestatistiek vertelt Windows welk pad de voorkeur heeft voor nieuwe verbindingen. Het verwijdert geen kanaal dat multichannel al heeft besloten te openen. De statistiek van de tunnel verhogen is nog steeds de moeite waard, want het houdt ongerelateerd verkeer weg van het trage pad en maakt de voorkeursroute voorspelbaar, maar het is een duwtje, geen filter.

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

Kopieer de alias uit die uitvoer in plaats van hem te typen, want sommige installaties vertalen de adaptornaam en de Engelse tekenreeks komt niet overeen.

Meet daarna beide getallen opnieuw: de bestandskopie en een doorvoertest over hetzelfde paar. Als de kopie herstelt terwijl de doorvoertest nooit traag was, was multichannel de oorzaak en kunt u stoppen. Als beide instorten, is de tunnel de flessenhals en multichannel heeft die alleen versterkt. Als de kopie traag blijft terwijl beide paden correct lijken, woont het resterende probleem in de share, de opslag of een filterstuurprogramma, wat een ander onderzoek is.