Dosierkopioj malakceliĝas kiam la VPN konektiĝas: SMB-plurkanaleco

Dosierkopio inter du Windows-maŝinoj estas rapida ĝis ambaŭ aliĝas al la sama VPN, kaj tiam ĝi kolapsas dum bendlarĝa testo tra la sama paro ankoraŭ raportas preskaŭ linian rapidon. Tiu breĉo estas la diagnozo: la ligo estas bona kaj io elektas pli malbonan vojon por la transigo mem. Tiu io kutime estas SMB3-plurkanaleco, farante ĝuste tion, por kio ĝi estis desegnita. Eligu la kroman kanalon el la bildo kaj la kopio revenas al la fizika ligo.

La simptomo atendas sian plej malrapidan kanalon

Plurkanaleco permesas al unu SMB-sesio uzi plurajn TCP-konektojn, unu por ĉiu taŭga adresparo inter kliento kaj servilo. Kiam ambaŭ maŝinoj sidas en la loka reto kaj en la sama tunelo, Windows povas parigi la lokretajn adresojn kun la tunelaj adresoj kaj trakti ambaŭ parojn kiel uzeblajn. La sesio finiĝas kun pli da kanaloj ol la fizika ligo bezonas, kaj unu el ili estas multe pli malrapida.

Ĝi ne fiaskas. Ĝi atendas, ĉar la sesio ne povas finiĝi pli rapide ol sia plej malrapida kanalo.

Tial bendlarĝa testo povas aspekti sana dum kopio rampas: unuflua mezurado eble elektas unu vojon, dum la transigo estis disigita super du. Legu la kanal-liston antaŭ ol ŝanĝi ajnan adaptilan agordon, kaj legu ĝin dum la kopio ankoraŭ funkcias, ĉar senokupa sesio montras nenion. Tio, kion vi notas, devus nomi la interfacon malantaŭ ĉiu kanalo, ne nur kiom malrapida la rezulto sentiĝis.

Konfirmu, ke dua kanalo ekzistas

Du cmdlet-j respondas la demandon rekte. La konekta listo montras la kanalojn en uzo, kaj la sesia resumo montras la konekton mem. Rulu ambaŭ dum la malrapida kopio.

Get-SmbMultichannelConnection
Get-SmbConnection

Serĉu pli ol unu vicon markitan kiel elektita por la sama servilo, poste solvu la klientan adreson en la suspektinda vico. Se tiu adreso apartenas al la tunela adaptilo, la dua vojo estas reala kaj konfirmita. Se ĉiu vico apartenas al la fizika interfaco, plurkanaleco ne estas via problemo kaj la kopio malrapidas pro senrilata kaŭzo. Faru tiun konfirmon unue, ĉar la riparo estas sufiĉe ĝena por meriti minuton da pruvoj.

Get-NetIPAddress -IPAddress 10.20.30.44

La adresoj ĉi tie estas anstataŭigiloj. Anstataŭigu ilin per tio, kion raportas via propra eligo, ĉar kopii adreson el blogo estas la maniero, kiel funkcianta komando fariĝas konfuza erarmesaĝo.

Eligu la tunelon el SMB, poste mezuru denove

Malŝalti plurkanalecon estas la plej rapida maniero konfirmi la diagnozon, kaj ĝi estas malfarebla. Apliku la klientan agordon sur la maŝino, kiu kopias, kaj la servilan agordon sur la maŝino, kiu gastigas la kunhavon, ĉar ĉiu flanko sola povas teni la kroman kanalon viva. La ŝanĝo validas por novaj konektoj, ne por ekzistantaj, do malfermita sesio travivos ĝin. Restartigu ambaŭ maŝinojn, aŭ almenaŭ fermu ĉiun tenilon al la kunhavo, antaŭ ol mezuri ion ajn.

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

Konfirmu la novan staton, poste rigardu, kion la servilo nun anoncas al klientoj.

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

La tunela interfaco devus elfali el tiu anoncita listo. Se ĝi ne faras tion, la agordo surteriĝis sur la malĝusta finpunkto aŭ malnova sesio ankoraŭ malfermiĝas. Se dosierkunhavigo simple ne rajtas uzi la tunelon, anstataŭe malligu la servilan komponanton de tiu adaptilo, kio lasas la tunelon uzebla por ĉiu alia servo.

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

Preferu la lokretan vojon sen pretendi, ke ĝi forigas kanalojn

Interfaca metriko diras al Windows, kiun vojon preferi por novaj konektoj. Ĝi ne forigas kanalon, kiun plurkanaleco jam decidis malfermi. Altigi la metrikon de la tunelo tamen indas, ĉar ĝi tenas senrilatan trafikon for de la malrapida vojo kaj faras la preferatan itineron antaŭvidebla, sed ĝi estas puŝo, ne filtrilo.

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

Kopiu la alinomon el tiu eligo anstataŭ tajpi ĝin, ĉar kelkaj instalaĵoj lokigas la adaptilan nomon kaj la angla ĉeno ne kongruos.

Poste mezuru denove ambaŭ nombrojn: la dosierkopion kaj bendlarĝan teston tra la sama paro. Se la kopio resaniĝas dum la bendlarĝa testo neniam estis malrapida, plurkanaleco estis la kaŭzo kaj vi povas halti. Se ambaŭ kolapsas, la tunelo estas la botelkoloo kaj plurkanaleco nur pligrandigis ĝin. Se la kopio restas malrapida dum ambaŭ vojoj aspektas ĝustaj, la restanta problemo loĝas en la kunhavo, la stokado aŭ filtro-ŝoforo, kio estas alia esploro.