Bumabagsak ang pagkopya ng file kapag kumonekta ang VPN: SMB multichannel

Mabilis ang pagkopya ng file sa pagitan ng dalawang Windows machine hanggang sa sumali ang dalawa sa parehong VPN, at pagkatapos ay bumabagsak ito habang ang throughput test sa parehong pares ay nag-uulat pa rin ng halos bilis ng linya. Ang agwat na iyon ang diagnosis: maayos ang link at may pumipili ng mas masamang landas para sa mismong paglilipat. Ang bagay na iyon ay karaniwang SMB3 multichannel, na ginagawa nang eksakto ang dinisenyo para gawin. Alisin ang sobrang channel at babalik ang kopya sa pisikal na link.

Naghihintay ang sintomas sa pinakamabagal na channel nito

Binibigyang-daan ng multichannel ang isang SMB session na gumamit ng ilang TCP connection, isa para sa bawat angkop na pares ng address sa pagitan ng client at server. Kapag ang dalawang machine ay nasa LAN at nasa parehong tunnel, maaaring ipares ng Windows ang mga address ng LAN sa mga address ng tunnel at ituring na magagamit ang dalawang pares. Sa huli, may mas maraming channel ang session kaysa kailangan ng pisikal na link, at ang isa sa kanila ay mas mabagal.

Hindi ito nabigo. Naghihintay ito, dahil hindi matatapos ang session nang mas mabilis kaysa sa pinakamabagal nitong channel.

Kaya naman maaaring mukhang malusog ang bandwidth test habang gumagapang ang kopya: ang pagsukat ng isang stream ay maaaring pumili ng isang landas, habang ang paglilipat ay nakalatag sa dalawa. Basahin ang listahan ng channel bago baguhin ang anumang setting ng adapter, at basahin ito habang tumatakbo pa ang kopya, dahil walang ipinapakita ang walang ginagawang session. Ang isusulat mo ay dapat pangalanan ang interface sa likod ng bawat channel, hindi lamang kung gaano kabagal ang naramdaman sa resulta.

Kumpirmahin na may pangalawang channel

Dalawang cmdlet ang direktang sumasagot sa tanong. Ipinapakita ng listahan ng koneksyon ang mga channel na ginagamit, at ipinapakita ng buod ng session ang mismong koneksyon. Patakbuhin ang dalawa habang mabagal ang kopya.

Get-SmbMultichannelConnection
Get-SmbConnection

Maghanap ng higit sa isang hilera na minarkahan bilang pinili para sa parehong server, pagkatapos ay lutasin ang address ng client sa kahina-hinalang hilera. Kung ang address na iyon ay pag-aari ng adapter ng tunnel, totoo at kumpirmado ang pangalawang landas. Kung ang bawat hilera ay pag-aari ng pisikal na interface, hindi mo problema ang multichannel at mabagal ang kopya dahil sa walang kaugnayang dahilan. Gawin muna ang kumpirmasyong iyon, dahil ang pag-aayos ay sapat na nakakagambala upang maging karapat-dapat sa isang minutong ebidensya.

Get-NetIPAddress -IPAddress 10.20.30.44

Ang mga address dito ay placeholder. Palitan ang mga ito ng iniuulat ng sarili mong output, dahil ang pagkopya ng address mula sa blog ang paraan kung paano nagiging nakakalitong mensahe ng error ang gumaganang command.

Alisin ang tunnel sa SMB at pagkatapos ay sukatin muli

Ang pagpapawalang-bisa ng multichannel ang pinakamabilis na paraan upang kumpirmahin ang diagnosis, at ito ay nababaligtad. Ilapat ang setting ng client sa machine na nagkopya at ang setting ng server sa machine na nagho-host ng share, dahil ang alinmang panig nang mag-isa ay maaaring magpanatili ng buhay sa sobrang channel. Ang pagbabago ay nalalapat sa mga bagong koneksyon at hindi sa mga umiiral na, kaya ang bukas na session ay nakakaligtas dito. I-restart ang dalawang machine, o hindi bababa sa isara ang bawat handle sa share, bago sukatin ang anuman.

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

Kumpirmahin ang bagong estado, pagkatapos ay tingnan kung ano ang ipinapahayag ng server sa mga client ngayon.

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

Dapat mahulog ang interface ng tunnel mula sa ipinahayag na listahan. Kung hindi, napunta ang setting sa maling dulo o bukas pa ang lumang session. Kung ang pagbabahagi ng file ay talagang hindi dapat gumamit ng tunnel, i-unbind ang component ng server mula sa adapter na iyon, na nag-iiwan sa tunnel na magagamit para sa bawat iba pang serbisyo.

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

Bigyang-priyoridad ang landas ng LAN nang hindi nagpapanggap na nagtatanggal ito ng channel

Sinasabi ng metric ng interface sa Windows kung aling landas ang pipiliin para sa mga bagong koneksyon. Hindi nito inaalis ang channel na napagpasyahan nang buksan ng multichannel. Sulit pa rin ang pagtaas ng metric ng tunnel, dahil inilalayo nito ang walang kaugnayang trapiko mula sa mabagal na landas at ginagawang mahulaan ang gustong ruta, ngunit ito ay isang tulak, hindi isang filter.

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

Kopyahin ang alias mula sa output na iyon sa halip na i-type ito, dahil ang ilang installation ay naglo-lokalisa ng pangalan ng adapter at hindi tutugma ang English na string.

Pagkatapos ay sukatin muli ang dalawang numero: ang pagkopya ng file at isang throughput test sa parehong pares. Kung bumangon ang kopya habang hindi kailanman mabagal ang throughput test, ang multichannel ang sanhi at maaari kang huminto. Kung parehong bumabagsak, ang tunnel ang bottleneck at pinalakas lamang ito ng multichannel. Kung nananatiling mabagal ang kopya habang mukhang tama ang dalawang landas, ang natitirang problema ay nasa share, storage o filter driver, na isa pang imbestigasyon.