Le copie di file crollano quando si connette la VPN: multicanale SMB

Copiare un file tra due macchine Windows è veloce finché entrambe non si uniscono alla stessa VPN, e allora crolla mentre un test di throughput sulla stessa coppia riporta ancora una velocità vicina a quella della linea. Quel divario è la diagnosi: il collegamento sta bene e qualcosa sceglie un percorso peggiore per il trasferimento stesso. Quel qualcosa di solito è il multicanale di SMB3, che fa esattamente ciò per cui è stato progettato. Togliete il canale in più dall’equazione e la copia torna sul collegamento fisico.

Il sintomo attende il suo canale più lento

Il multicanale consente a una sessione SMB di usare più connessioni TCP, una per ogni coppia di indirizzi adatta tra client e server. Quando entrambe le macchine stanno sulla LAN e sullo stesso tunnel, Windows può accoppiare gli indirizzi della LAN con quelli del tunnel e considerare entrambe le coppie utilizzabili. Alla fine la sessione ha più canali di quanti ne servano al collegamento fisico, e uno di essi è molto più lento.

Non fallisce. Aspetta, perché la sessione non può terminare più in fretta del suo canale più lento.

Ecco perché un test di banda può sembrare sano mentre una copia si trascina: una misurazione a flusso singolo può scegliere un percorso, mentre il trasferimento era distribuito su due. Leggete l’elenco dei canali prima di cambiare qualsiasi impostazione dell’adattatore, e leggetelo mentre la copia è ancora in corso, perché una sessione inattiva non mostra nulla. Ciò che annotate deve nominare l’interfaccia dietro ogni canale, non solo quanto è sembrato lento il risultato.

Confermate che esiste un secondo canale

Due cmdlet rispondono direttamente alla domanda. L’elenco delle connessioni mostra i canali in uso, e il riepilogo della sessione mostra la connessione stessa. Eseguiteli entrambi durante la copia lenta.

Get-SmbMultichannelConnection
Get-SmbConnection

Cercate più di una riga contrassegnata come selezionata per lo stesso server, poi risolvete l’indirizzo del client nella riga sospetta. Se quell’indirizzo appartiene all’adattatore del tunnel, il secondo percorso è reale e confermato. Se ogni riga appartiene all’interfaccia fisica, il multicanale non è il vostro problema e la copia è lenta per un motivo non correlato. Fate prima questa conferma, perché la riparazione è abbastanza invasiva da meritare un minuto di prove.

Get-NetIPAddress -IPAddress 10.20.30.44

Gli indirizzi qui sono segnaposto. Sostituiteli con ciò che riporta il vostro output, perché copiare un indirizzo da un blog è il modo in cui un comando funzionante diventa un messaggio di errore confuso.

Togliete il tunnel da SMB e poi misurate di nuovo

Disattivare il multicanale è il modo più rapido per confermare la diagnosi, ed è reversibile. Applicate l’impostazione del client sulla macchina che copia e quella del server sulla macchina che ospita la condivisione, perché ciascun lato da solo può tenere in vita il canale in più. La modifica vale per le connessioni nuove e non per quelle esistenti, quindi una sessione aperta le sopravvive. Riavviate entrambe le macchine, o almeno chiudete ogni handle verso la condivisione, prima di misurare qualsiasi cosa.

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

Confermate il nuovo stato, poi guardate cosa il server annuncia ora ai client.

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

L’interfaccia del tunnel dovrebbe sparire da quell’elenco annunciato. Se non lo fa, l’impostazione è finita sull’estremità sbagliata o una vecchia sessione è ancora aperta. Se la condivisione di file semplicemente non deve usare il tunnel, scollegate invece il componente server da quell’adattatore, il che lascia il tunnel utilizzabile per ogni altro servizio.

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

Preferite il percorso della LAN senza fingere che elimini i canali

La metrica di un’interfaccia dice a Windows quale percorso preferire per le nuove connessioni. Non rimuove un canale che il multicanale ha già deciso di aprire. Alzare la metrica del tunnel vale comunque la pena, perché tiene il traffico non correlato lontano dal percorso lento e rende prevedibile la rotta preferita, ma è una spinta, non un filtro.

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

Copiate l’alias da quell’output invece di digitarlo, perché alcune installazioni localizzano il nome dell’adattatore e la stringa inglese non corrisponderà.

Poi misurate di nuovo entrambi i numeri: la copia del file e un test di throughput sulla stessa coppia. Se la copia si riprende mentre il test di throughput non è mai stato lento, il multicanale era la causa e potete fermarvi. Se entrambi crollano, il tunnel è il collo di bottiglia e il multicanale non ha fatto che amplificarlo. Se la copia resta lenta mentre entrambi i percorsi sembrano corretti, il problema rimanente vive nella condivisione, nello storage o in un driver di filtro, il che è un’altra indagine.