Copierea fișierelor se prăbușește când se conectează VPN-ul: SMB multicanal

Copierea unui fișier între două mașini Windows este rapidă până când ambele se alătură aceluiași VPN, iar atunci se prăbușește în timp ce un test de debit prin aceeași pereche raportează în continuare aproape viteza liniei. Acea diferență este diagnosticul: legătura este bună și ceva alege o cale mai proastă pentru transferul în sine. Acel ceva este de obicei SMB3 multicanal, făcând exact ceea ce a fost proiectat să facă. Scoateți canalul suplimentar din ecuație și copia revine pe legătura fizică.

Simptomul așteaptă cel mai lent canal al său

Multicanalul permite unei singure sesiuni SMB să folosească mai multe conexiuni TCP, una pentru fiecare pereche de adrese potrivită între client și server. Când ambele mașini stau în LAN și în același tunel, Windows poate împerechea adresele din LAN cu adresele tunelului și poate considera ambele perechi utilizabile. Sesiunea ajunge cu mai multe canale decât are nevoie legătura fizică, iar unul dintre ele este mult mai lent.

Nu eșuează. Așteaptă, pentru că sesiunea nu se poate termina mai repede decât cel mai lent canal al ei.

De aceea un test de lățime de bandă poate părea sănătos în timp ce o copie se târăște: o măsurătoare pe un singur flux poate alege o cale, în timp ce transferul era împărțit pe două. Citiți lista canalelor înainte de a schimba orice setare a adaptorului și citiți-o cât timp copia încă rulează, pentru că o sesiune inactivă nu arată nimic. Ce notați ar trebui să numească interfața din spatele fiecărui canal, nu doar cât de lent s-a simțit rezultatul.

Confirmați că există un al doilea canal

Două cmdlet-uri răspund direct la întrebare. Lista conexiunilor arată canalele în uz, iar rezumatul sesiunii arată conexiunea în sine. Rulați ambele în timpul copierii lente.

Get-SmbMultichannelConnection
Get-SmbConnection

Căutați mai mult de un rând marcat ca selectat pentru același server, apoi rezolvați adresa clientului din rândul suspect. Dacă acea adresă aparține adaptorului tunelului, a doua cale este reală și confirmată. Dacă fiecare rând aparține interfeței fizice, multicanalul nu este problema dumneavoastră și copia este lentă dintr-un motiv nelegat. Faceți această confirmare prima, pentru că reparația este destul de perturbatoare încât să merite un minut de dovezi.

Get-NetIPAddress -IPAddress 10.20.30.44

Adresele de aici sunt substituenți. Înlocuiți-le cu ce raportează propria ieșire, pentru că a copia o adresă dintr-un blog este felul în care o comandă funcțională devine un mesaj de eroare confuz.

Scoateți tunelul din SMB și apoi măsurați din nou

Dezactivarea multicanalului este cel mai rapid mod de a confirma diagnosticul și este reversibilă. Aplicați setarea de client pe mașina care copiază și setarea de server pe mașina care găzduiește partajarea, pentru că oricare parte singură poate ține în viață canalul suplimentar. Modificarea se aplică conexiunilor noi, nu celor existente, așa că o sesiune deschisă o supraviețuiește. Reporniți ambele mașini sau măcar închideți toate handle-urile către partajare înainte de a măsura ceva.

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

Confirmați noua stare, apoi vedeți ce anunță acum serverul clienților.

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

Interfața tunelului ar trebui să dispară din lista anunțată. Dacă nu dispare, setarea a ajuns la capătul greșit sau o sesiune veche este încă deschisă. Dacă partajarea fișierelor pur și simplu nu trebuie să folosească tunelul, dezasociați în schimb componenta de server de acel adaptor, ceea ce lasă tunelul utilizabil pentru orice alt serviciu.

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

Preferați calea prin LAN fără să pretindeți că șterge canale

Metrica unei interfețe îi spune lui Windows ce cale să prefere pentru conexiunile noi. Ea nu elimină un canal pe care multicanalul a decis deja să îl deschidă. Creșterea metricii tunelului merită totuși făcută, pentru că ține traficul nelegat departe de calea lentă și face ruta preferată previzibilă, dar este o împingere, nu un filtru.

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

Copiați aliasul din acea ieșire în loc să îl tastați, pentru că unele instalări localizează numele adaptorului și șirul în engleză nu se va potrivi.

Apoi măsurați din nou ambele numere: copierea fișierului și un test de debit prin aceeași pereche. Dacă copia își revine în timp ce testul de debit nu a fost niciodată lent, multicanalul a fost cauza și puteți opri. Dacă ambele se prăbușesc, tunelul este gâtul de sticlă iar multicanalul doar l-a amplificat. Dacă copia rămâne lentă în timp ce ambele căi par corecte, problema rămasă locuiește în partajare, în stocare sau într-un driver de filtru, ceea ce este altă investigație.