As copias de ficheiros derrúbanse ao conectar a VPN: multicanal de SMB
Unha copia espera polo seu canal máis lento, así que unha proba de ancho de banda saudable agocha a causa. Confirme o canal do túnel, sáqueo de SMB e despois mida as dúas rutas.
Copiar un ficheiro entre dúas máquinas Windows é rápido ata que ambas se unen á mesma VPN, e entón derrúbase mentres unha proba de rendemento polo mesmo par segue informando dunha velocidade próxima á da liña. Esa diferenza é o diagnóstico: a ligazón está ben e algo está a escoller unha ruta peor para a propia transferencia. Ese algo adoita ser o multicanal de SMB3, facendo exactamente aquilo para o que foi deseñado. Saque o canal extra da ecuación e a copia volve á ligazón física.
O síntoma espera polo seu canal máis lento
O multicanal permite que unha sesión SMB use varias conexións TCP, unha por cada par de enderezos axeitado entre cliente e servidor. Cando ambas as máquinas están na LAN e no mesmo túnel, Windows pode emparellar os enderezos da LAN cos do túnel e tratar ambos os pares como utilizables. A sesión acaba con máis canais dos que necesita a ligazón física, e un deles é moito máis lento.
Non falla. Espera, porque a sesión non pode rematar máis rápido que o seu canal máis lento.
Por iso unha proba de ancho de banda pode parecer saudable mentres unha copia se arrastra: unha medición dun só fluxo pode escoller unha ruta, mentres que a transferencia estaba repartida entre dúas. Lea a lista de canais antes de cambiar calquera axuste do adaptador, e léaa mentres a copia segue en marcha, porque unha sesión inactiva non mostra nada. O que anote debe nomear a interface que hai detrás de cada canal, non só o lento que pareceu o resultado.
Confirme que existe un segundo canal
Dous cmdlets responden a pregunta directamente. A lista de conexións mostra os canais en uso, e o resumo da sesión mostra a conexión en si. Execute ambos durante a copia lenta.
Get-SmbMultichannelConnection
Get-SmbConnectionBusque máis dunha fila marcada como seleccionada para o mesmo servidor, e despois resolva o enderezo do cliente na fila sospeitosa. Se ese enderezo pertence ao adaptador do túnel, a segunda ruta é real e está confirmada. Se todas as filas pertencen á interface física, o multicanal non é o seu problema e a copia vai lenta por un motivo alleo. Faga esa confirmación primeiro, porque a reparación é bastante disruptiva como para merecer un minuto de probas.
Get-NetIPAddress -IPAddress 10.20.30.44Os enderezos de aquí son marcadores de posición. Substitúaos polo que informe a súa propia saída, porque copiar un enderezo dun blog é a forma en que un comando que funciona se converte nunha mensaxe de erro confusa.
Saia do túnel en SMB e despois mida de novo
Desactivar o multicanal é a forma máis rápida de confirmar o diagnóstico, e é reversible. Aplique o axuste de cliente na máquina que fai a copia e o de servidor na máquina que aloxa o recurso compartido, porque calquera dos dous lados por si só pode manter vivo o canal extra. O cambio aplícase a conexións novas e non ás existentes, así que unha sesión aberta sobrevive a el. Reinicie ambas as máquinas, ou polo menos peche todos os identificadores do recurso compartido, antes de medir nada.
Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -ForceConfirme o novo estado e despois mire que anuncia agora o servidor aos clientes.
Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbServerNetworkInterface | Format-List *A interface do túnel debería desaparecer desa lista anunciada. Se non o fai, o axuste caeu no extremo equivocado ou unha sesión antiga segue aberta. Se compartir ficheiros simplemente non debe usar o túnel, desvincule o compoñente de servidor dese adaptador, o que deixa o túnel utilizable para calquera outro servizo.
Get-NetAdapterBinding -Name "OpenVPN Data Channel Offload"
Disable-NetAdapterBinding -Name "OpenVPN Data Channel Offload" -ComponentID ms_serverPrefera a ruta da LAN sen finxir que elimina canais
A métrica dunha interface dille a Windows que ruta preferir para as conexións novas. Non elimina un canal que o multicanal xa decidiu abrir. Subir a métrica do túnel segue paga a pena, porque mantén o tráfico alleo lonxe da ruta lenta e fai previsible a ruta preferida, pero é un empurrón, non un filtro.
Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000Copie o alias desa saída en lugar de escribilo, porque algunhas instalacións traducen o nome do adaptador e a cadea en inglés non coincidirá.
Despois mida de novo ambos os números: a copia do ficheiro e unha proba de rendemento polo mesmo par. Se a copia se recupera mentres a proba de rendemento nunca foi lenta, o multicanal era a causa e pode deterse. Se ambas se derrúban, o túnel é o pescozo de botella e o multicanal só o amplificou. Se a copia segue lenta mentres ambas as rutas parecen correctas, o problema restante vive no recurso compartido, no almacenamento ou nun controlador de filtro, que é outra investigación.