VPN接続でファイルコピーが失速する:SMBマルチチャネル
コピーは最も遅いチャネルを待つため、健全な帯域テストでは原因が見えない。トンネルのチャネルを確認し、SMBから外してから両方の経路を測定する。
二台のWindowsマシン間のファイルコピーは、両方が同じVPNに参加するまでは高速です。しかし参加した途端に崩れ落ちる一方、同じ組み合わせで測ったスループットテストは依然として回線速度に近い値を報告します。この差が診断の手がかりです。リンク自体は正常で、転送そのものに対して何かがより悪い経路を選んでいるのです。その何かは通常SMB3マルチチャネルであり、設計どおりの動作をしているにすぎません。余分なチャネルを除外すれば、コピーは物理リンクに戻ります。
症状は最も遅いチャネルを待つ
マルチチャネルは、一つのSMBセッションが複数のTCP接続を使えるようにします。クライアントとサーバーの間の適切なアドレスペアごとに一本ずつです。両方のマシンがLAN上にあり、かつ同じトンネル上にあると、WindowsはLANのアドレスとトンネルのアドレスを組み合わせ、両方のペアを使用可能と見なします。その結果、セッションには物理リンクが必要とする以上のチャネルが残り、そのうち一本がはるかに遅くなります。
失敗するのではありません。セッションは最も遅いチャネルより速く完了できないため、待つのです。
だからこそ、コピーが這うように遅いのに帯域テストは健全に見えることがあります。単一ストリームの測定が一本の経路を選ぶ一方、転送は二本に分散していた可能性があるからです。アダプターの設定を変える前にチャネル一覧を読み、コピーがまだ実行中のうちに読んでください。アイドル状態のセッションは何も示しません。記録すべきは各チャネルの背後にあるインターフェースであり、結果がどれほど遅く感じたかではありません。
二本目のチャネルが存在することを確認する
二つのcmdletがこの問いに直接答えます。接続一覧は使用中のチャネルを示し、セッション概要は接続そのものを示します。遅いコピーの最中に両方を実行してください。
Get-SmbMultichannelConnection
Get-SmbConnection同じサーバーに対して選択済みと印された行が複数ないか探し、次に疑わしい行のクライアントアドレスを解決します。そのアドレスがトンネルのアダプターに属していれば、二本目の経路は実在し、確認できたことになります。すべての行が物理インターフェースに属していれば、マルチチャネルは原因ではなく、コピーは無関係な理由で遅いのです。この確認を最初に行ってください。修復はそれだけ擾乱が大きいので、一分の証拠に値します。
Get-NetIPAddress -IPAddress 10.20.30.44ここに示したアドレスはプレースホルダーです。自分の出力が報告する値に置き換えてください。ブログからアドレスをコピーすると、動作するコマンドが不可解なエラーメッセージに変わるからです。
トンネルをSMBから外してから、もう一度測定する
マルチチャネルを無効にするのが診断を確認する最速の方法で、元に戻せます。コピーを行うマシンにクライアント設定を、共有をホストするマシンにサーバー設定を適用してください。どちらか片側だけでも余分なチャネルを生かし続けられるからです。変更は既存ではなく新規の接続に適用されるため、開いているセッションはそのまま生き残ります。何かを測定する前に、両方のマシンを再起動するか、少なくとも共有へのハンドルをすべて閉じてください。
Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -Force新しい状態を確認し、サーバーが今クライアントに何を通知しているかを見ます。
Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbServerNetworkInterface | Format-List *トンネルのインターフェースはその通知一覧から外れるはずです。外れない場合、設定が誤った端点に適用されたか、古いセッションがまだ開いています。ファイル共有でトンネルをどうしても使わせたくない場合は、代わりにそのアダプターからサーバーコンポーネントをバインド解除してください。トンネルは他のあらゆるサービスに使えるままになります。
Get-NetAdapterBinding -Name "OpenVPN Data Channel Offload"
Disable-NetAdapterBinding -Name "OpenVPN Data Channel Offload" -ComponentID ms_serverチャネルを消すふりをせずにLAN経路を優先する
インターフェースメトリックは、新しい接続にどの経路を優先するかをWindowsに伝えます。マルチチャネルがすでに開くと決めたチャネルを削除するものではありません。トンネルのメトリックを上げる価値は依然としてあります。無関係なトラフィックを遅い経路から遠ざけ、優先経路を予測可能にするからです。ただしそれは後押しであり、フィルターではありません。
Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000エイリアスは入力せずにその出力からコピーしてください。インストールによってはアダプター名が日本語化され、英語の文字列が一致しないからです。
次に両方の数値を測り直します。ファイルコピーと、同じ組み合わせでのスループットテストです。スループットテストが決して遅くなかったのにコピーが回復したなら、原因はマルチチャネルであり、そこで止めてかまいません。両方が崩れるなら、トンネルがボトルネックであり、マルチチャネルはそれを増幅したにすぎません。両方の経路が正しく見えるのにコピーが遅いままなら、残る問題は共有、ストレージ、またはフィルタードライバーの中にあり、それは別の調査になります。