Penyalinan berkas melambat saat VPN terhubung: Multichannel SMB

Menyalin berkas antara dua mesin Windows cepat sampai keduanya bergabung ke VPN yang sama, lalu runtuh sementara uji throughput pada pasangan yang sama masih melaporkan kecepatan mendekati laju jalur. Selisih itulah diagnosisnya: tautannya baik dan ada sesuatu yang memilih jalur lebih buruk untuk transfer itu sendiri. Sesuatu itu biasanya Multichannel SMB3, yang melakukan tepat seperti yang dirancang. Keluarkan kanal tambahan dari gambaran dan salinan kembali ke tautan fisik.

Gejalanya menunggu kanalnya yang paling lambat

Multichannel memungkinkan satu sesi SMB memakai beberapa koneksi TCP, satu untuk setiap pasangan alamat yang sesuai antara klien dan server. Ketika kedua mesin berada di LAN dan di terowongan yang sama, Windows dapat memasangkan alamat LAN dengan alamat terowongan dan menganggap kedua pasangan dapat dipakai. Sesi berakhir dengan lebih banyak kanal daripada yang dibutuhkan tautan fisik, dan salah satunya jauh lebih lambat.

Ini tidak gagal. Ia menunggu, karena sesi tidak dapat selesai lebih cepat daripada kanalnya yang paling lambat.

Itulah sebabnya uji bandwidth bisa tampak sehat sementara penyalinan merayap: pengukuran satu aliran mungkin memilih satu jalur, padahal transfernya tersebar di dua jalur. Baca daftar kanal sebelum mengubah pengaturan adaptor apa pun, dan baca saat penyalinan masih berjalan, karena sesi menganggur tidak menunjukkan apa pun. Yang Anda catat harus menyebut antarmuka di balik setiap kanal, bukan hanya seberapa lambat hasilnya terasa.

Pastikan ada kanal kedua

Dua cmdlet menjawab pertanyaan itu secara langsung. Daftar koneksi menunjukkan kanal yang dipakai, dan ringkasan sesi menunjukkan koneksinya sendiri. Jalankan keduanya selama penyalinan yang lambat.

Get-SmbMultichannelConnection
Get-SmbConnection

Cari lebih dari satu baris yang ditandai sebagai terpilih untuk server yang sama, lalu selesaikan alamat klien di baris yang mencurigakan. Jika alamat itu milik adaptor terowongan, jalur kedua nyata dan terkonfirmasi. Jika setiap baris milik antarmuka fisik, Multichannel bukan masalah Anda dan penyalinan lambat karena alasan yang tidak terkait. Lakukan konfirmasi itu lebih dulu, karena perbaikannya cukup mengganggu sehingga layak mendapat satu menit bukti.

Get-NetIPAddress -IPAddress 10.20.30.44

Alamat di sini adalah tempat penampung. Gantilah dengan apa yang dilaporkan keluaran Anda sendiri, karena menyalin alamat dari blog adalah cara perintah yang berfungsi berubah menjadi pesan galat yang membingungkan.

Keluarkan terowongan dari SMB, lalu ukur lagi

Menonaktifkan Multichannel adalah cara tercepat untuk memastikan diagnosis, dan bisa dibalik. Terapkan pengaturan klien pada mesin yang menyalin dan pengaturan server pada mesin yang menghosting berbagi, karena salah satu sisi saja dapat menjaga kanal tambahan tetap hidup. Perubahan berlaku untuk koneksi baru, bukan yang sudah ada, sehingga sesi terbuka selamat. Mulai ulang kedua mesin, atau setidaknya tutup setiap handle ke berbagi, sebelum mengukur apa pun.

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

Pastikan keadaan baru, lalu lihat apa yang kini diumumkan server kepada klien.

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

Antarmuka terowongan seharusnya keluar dari daftar yang diumumkan itu. Jika tidak, pengaturannya mendarat di ujung yang salah atau sesi lama masih terbuka. Jika berbagi berkas memang tidak boleh memakai terowongan, lepaskan komponen server dari adaptor itu, yang membuat terowongan tetap dapat dipakai untuk setiap layanan lain.

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

Utamakan jalur LAN tanpa berpura-pura menghapus kanal

Metrik antarmuka memberi tahu Windows jalur mana yang diutamakan untuk koneksi baru. Ia tidak menghapus kanal yang sudah diputuskan Multichannel untuk dibuka. Menaikkan metrik terowongan tetap layak, karena menjauhkan lalu lintas tak terkait dari jalur lambat dan membuat rute pilihan dapat diprediksi, tetapi itu dorongan, bukan penyaring.

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

Salin alias dari keluaran itu alih-alih mengetiknya, karena beberapa pemasangan melokalkan nama adaptor dan untai bahasa Inggris tidak akan cocok.

Lalu ukur lagi kedua angka: penyalinan berkas dan uji throughput pada pasangan yang sama. Jika salinan pulih sementara uji throughput tidak pernah lambat, Multichannel adalah penyebabnya dan Anda bisa berhenti. Jika keduanya runtuh, terowongan adalah hambatannya dan Multichannel hanya memperkuatnya. Jika salinan tetap lambat sementara kedua jalur tampak benar, masalah yang tersisa berada di berbagi, penyimpanan, atau pengandar penyaring, yang merupakan penyelidikan lain.