Les còpies de fitxers s’alenteixen quan es connecta la VPN: multicanal SMB
Una còpia espera el seu canal més lent, així que una prova d’amplada de banda saludable amaga la causa. Confirmeu el canal del túnel, traieu-lo de SMB i després mesureu tots dos camins.
Copiar un fitxer entre dues màquines Windows és ràpid fins que totes dues s’uneixen a la mateixa VPN, i llavors s’enfonsa mentre una prova d’amplada de banda pel mateix parell encara informa d’una velocitat propera a la de la línia. Aquesta diferència és el diagnòstic: l’enllaç està bé i alguna cosa tria un camí pitjor per a la transferència mateixa. Aquesta alguna cosa sol ser el multicanal SMB3, que fa exactament allò per a què va ser dissenyat. Traieu el canal extra de l’equació i la còpia torna a l’enllaç físic.
El símptoma espera el seu canal més lent
El multicanal permet que una sessió SMB faci servir diverses connexions TCP, una per a cada parell d’adreces adequat entre client i servidor. Quan les dues màquines són a la LAN i al mateix túnel, Windows pot aparellar les adreces de la LAN amb les del túnel i considerar tots dos parells utilitzables. La sessió acaba amb més canals dels que necessita l’enllaç físic, i un d’ells és molt més lent.
No falla. Espera, perquè la sessió no pot acabar més de pressa que el seu canal més lent.
Per això una prova d’amplada de banda pot semblar saludable mentre una còpia s’arrossega: un mesurament d’un sol flux pot triar un camí, mentre que la transferència s’havia repartit entre dos. Llegiu la llista de canals abans de canviar qualsevol paràmetre de l’adaptador, i llegiu-la mentre la còpia encara s’executa, perquè una sessió inactiva no mostra res. El que anoteu ha de nomenar la interfície que hi ha darrere de cada canal, no només com de lent va semblar el resultat.
Confirmeu que existeix un segon canal
Dos cmdlets responen la pregunta directament. La llista de connexions mostra els canals en ús, i el resum de la sessió mostra la connexió mateixa. Executeu tots dos durant la còpia lenta.
Get-SmbMultichannelConnection
Get-SmbConnectionBusqueu més d’una fila marcada com a seleccionada per al mateix servidor, i després resoleu l’adreça del client a la fila sospitosa. Si aquesta adreça pertany a l’adaptador del túnel, el segon camí és real i queda confirmat. Si totes les files pertanyen a la interfície física, el multicanal no és el vostre problema i la còpia va lenta per un motiu sense relació. Feu aquesta confirmació primer, perquè la reparació és prou disruptiva per merèixer un minut de proves.
Get-NetIPAddress -IPAddress 10.20.30.44Les adreces d’aquí són marcadors de posició. Substituïu-les pel que informi la vostra pròpia sortida, perquè copiar una adreça d’un blog és com una ordre que funciona es converteix en un missatge d’error confús.
Traieu el túnel de SMB i torneu a mesurar
Desactivar el multicanal és la manera més ràpida de confirmar el diagnòstic, i és reversible. Apliqueu el paràmetre del client a la màquina que fa la còpia i el del servidor a la màquina que allotja el recurs compartit, perquè qualsevol dels dos costats sol pot mantenir viu el canal extra. El canvi s’aplica a connexions noves i no a les existents, així que una sessió oberta el sobreviu. Reinicieu les dues màquines, o almenys tanqueu tots els handles del recurs compartit, abans de mesurar res.
Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -ForceConfirmeu l’estat nou i després mireu què anuncia ara el servidor als clients.
Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbServerNetworkInterface | Format-List *La interfície del túnel hauria de desaparèixer d’aquesta llista anunciada. Si no ho fa, el paràmetre ha anat a parar al punt final equivocat o una sessió antiga encara és oberta. Si el fet de compartir fitxers simplement no ha d’usar el túnel, deslligueu el component del servidor d’aquest adaptador, cosa que deixa el túnel utilitzable per a qualsevol altre servei.
Get-NetAdapterBinding -Name "OpenVPN Data Channel Offload"
Disable-NetAdapterBinding -Name "OpenVPN Data Channel Offload" -ComponentID ms_serverPreferiu el camí de la LAN sense fingir que elimina canals
La mètrica d’una interfície diu a Windows quin camí preferir per a les connexions noves. No elimina un canal que el multicanal ja ha decidit obrir. Pujar la mètrica del túnel encara val la pena, perquè manté el trànsit no relacionat lluny del camí lent i fa predictible la ruta preferida, però és un toc, no un filtre.
Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000Copieu l’àlies d’aquesta sortida en lloc d’escriure’l, perquè algunes instal·lacions tradueixen el nom de l’adaptador i la cadena en anglès no coincidirà.
Després mesureu de nou tots dos números: la còpia del fitxer i una prova d’amplada de banda pel mateix parell. Si la còpia es recupera mentre la prova d’amplada de banda mai no havia estat lenta, el multicanal era la causa i podeu parar. Si tots dos s’enfonsen, el túnel és el coll d’ampolla i el multicanal només el va amplificar. Si la còpia continua lenta mentre tots dos camins semblen correctes, el problema restant viu al recurs compartit, a l’emmagatzematge o en un controlador de filtre, que és una altra investigació.