Filkopieringer kollapser når VPN-en kobler til: SMB-multikanal
En kopi venter på den langsomste kanalen sin, så en sunn båndbreddetest skjuler årsaken. Bekreft tunnelkanalen, ta den ut av SMB og mål deretter begge veiene.
En filkopiering mellom to Windows-maskiner er rask helt til begge blir med i samme VPN, og da kollapser den mens en gjennomstrømningstest over det samme paret fortsatt rapporterer nesten linjehastighet. Det gapet er diagnosen: forbindelsen er fin, og noe velger en dårligere vei for selve overføringen. Det noe er vanligvis SMB3-multikanal, som gjør nøyaktig det den ble laget for. Ta den ekstra kanalen ut av bildet, og kopien går tilbake til den fysiske forbindelsen.
Symptomet venter på sin langsomste kanal
Multikanal lar én SMB-økt bruke flere TCP-tilkoblinger, én per passende adressepar mellom klient og server. Når begge maskinene sitter på LAN-et og på samme tunnel, kan Windows pare LAN-adressene og tunneladressene og behandle begge parene som brukbare. Økten ender opp med flere kanaler enn den fysiske forbindelsen trenger, og én av dem er langt langsommere.
Den feiler ikke. Den venter, fordi økten ikke kan bli ferdig raskere enn sin langsomste kanal.
Derfor kan en båndbreddetest se sunn ut mens en kopi kryper: en enkeltstrømsmåling velger kanskje én vei, mens overføringen var spredt over to. Les kanallisten før du endrer noen adapterinnstilling, og les den mens kopien fortsatt kjører, for en inaktiv økt viser ingenting. Det du skriver ned, bør navngi grensesnittet bak hver kanal, ikke bare hvor langsomt resultatet føltes.
Bekreft at det finnes en andre kanal
To cmdleter svarer på spørsmålet direkte. Tilkoblingslisten viser kanalene som er i bruk, og øktsammendraget viser selve tilkoblingen. Kjør begge under den langsomme kopien.
Get-SmbMultichannelConnection
Get-SmbConnectionSe etter mer enn én rad merket som valgt for samme server, og slå deretter opp klientadressen i den mistenkelige raden. Hvis den adressen tilhører tunneladapteret, er den andre veien ekte og bekreftet. Hvis hver rad tilhører det fysiske grensesnittet, er multikanal ikke problemet ditt, og kopien er langsom av en urelatert grunn. Gjør den bekreftelsen først, fordi reparasjonen er forstyrrende nok til å fortjene ett minutt med bevis.
Get-NetIPAddress -IPAddress 10.20.30.44Adressene her er plassholdere. Bytt dem ut med det din egen utskrift rapporterer, for å kopiere en adresse fra en blogg er måten en fungerende kommando blir en forvirrende feilmelding.
Ta tunnelen ut av SMB, og mål deretter på nytt
Å slå av multikanal er den raskeste måten å bekrefte diagnosen på, og det er reversibelt. Bruk klientinnstillingen på maskinen som kopierer, og serverinnstillingen på maskinen som hoster delingen, fordi hver side alene kan holde den ekstra kanalen i live. Endringen gjelder nye tilkoblinger og ikke eksisterende, så en åpen økt overlever den. Start begge maskinene på nytt, eller lukk i det minste hvert håndtak mot delingen, før du måler noe.
Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -ForceBekreft den nye tilstanden, og se deretter hva serveren nå annonserer til klientene.
Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbServerNetworkInterface | Format-List *Tunnelgrensesnittet bør falle ut av den annonserte listen. Hvis ikke, har innstillingen landet på feil ende, eller en gammel økt er fortsatt åpen. Hvis fildeling rett og slett ikke skal bruke tunnelen, kan du i stedet løse serverkomponenten fra den adapteren, noe som lar tunnelen være brukbar for alle andre tjenester.
Get-NetAdapterBinding -Name "OpenVPN Data Channel Offload"
Disable-NetAdapterBinding -Name "OpenVPN Data Channel Offload" -ComponentID ms_serverForetrekk LAN-veien uten å late som den sletter kanaler
En grensesnittmetrikk forteller Windows hvilken vei som skal foretrekkes for nye tilkoblinger. Den fjerner ikke en kanal som multikanal allerede har bestemt seg for å åpne. Å heve metrikken til tunnelen er likevel verdt det, fordi det holder urelatert trafikk unna den langsomme veien og gjør den foretrukne ruten forutsigbar, men det er et dytt, ikke et filter.
Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000Kopier aliaset fra den utskriften i stedet for å skrive det, fordi noen installasjoner oversetter adapternavnet, og den engelske strengen vil ikke stemme.
Mål deretter begge tallene på nytt: filkopien og en gjennomstrømningstest over det samme paret. Hvis kopien kommer seg mens gjennomstrømningstesten aldri var langsom, var multikanal årsaken, og du kan stoppe. Hvis begge kollapser, er tunnelen flaskehalsen og multikanal forsterket den bare. Hvis kopien blir langsom mens begge veiene ser riktige ut, bor det gjenværende problemet i delingen, lagringen eller en filterdriver, noe som er en annen undersøkelse.