VPN 経由の RDP フリーズ：入力は動くので、まず転送方式を試す

画面が更新されなくなってもマウスがリモート デスクトップ上を滑り続けるなら、VPN が切れたと結論したくなります。しかしその結論はたいてい間違いです。入力が効いたままフレームが固まるということは、セッションとその入力チャネルが生きているということであり、障害はルーティングや資格情報ではなくグラフィック転送側にあると示します。素早い二つの観察で、利用者が同じ言葉で呼ぶ三つの障害を切り分けられます。

フリーズが教えてくれないこと

リモート デスクトップは入力と画面更新を TCP 3389 で運び、現在の Windows クライアントはストリームのグラフィック負荷が大きい部分に UDP 転送を追加できます。大きなデータグラムを分割したり落としたりするトンネルでは、信頼性のあるチャネルがキー入力を運び続ける一方で、グラフィック チャネルが止まります。その結果、止まった画面と反応するキーボードという奇妙な組み合わせになります。これは、再接続で症状が一時的に治まり、その後また戻る理由も説明します。

切断して再接続するセッションは別の障害で、まったく開かないセッションは三つ目です。まず形に名前を付ければ、間違った層を試さずに済みます。

二つのコマンドで三つの障害を切り分ける

到達性の排除は安上がりです。クライアントから RDP ポートを試し、次にホストでセッション状態を読みます。

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

TCP テストが失敗したならセッションは一度も開いていないので、フリーズではなくファイアウォール、スコープ、サービスの問題として扱います。アクティブなセッションがある状態でテストが成功すれば制御チャネルは存在し、それはまさに画面が固まるケースです。権限エラーは空の一覧のように見えるため、ホストへの問い合わせはセッションを見る権限のあるアカウントで実行してください。切断されたまま ID を保持するセッションはアクティブなセッションと同じではないので、セッション ID と状態を記録してください。

UDP 転送を切り、比較する

表示だけが止まるなら、クライアントの転送方式を一度に一つの変更で比較します。受信トレイ クライアントと Store クライアントは同じスタックを共有せず、下のポリシーは受信トレイ クライアントから UDP を外します。

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

値が 1 ならそのクライアントでは UDP がすでに無効なので、設定後も続くフリーズは UDP 経路の問題ではありません。値がないときはポリシーを有効にし、再接続し、以前固まったのと同じ操作を正確に繰り返します。どちらが効いたのか分からなくなるので、二つの変更を組み合わせず、Store クライアントを別の手順として試してください。Windows のリリースごとに転送の挙動が変わっているため、クライアントのバージョンを記録に残してください。

一つのホストだけが固まり、ほかは問題ないとき

ほかは健全なサブネットで一つのホストだけが失敗するなら、原因はトンネルから離れています。VPN 設定に触れる前に、経路の MTU とリモート表示のスタックを確認してください。

ping -f -l 1472 rdp-host.example.com

応答があれば、経路がそのサイズで断片化せずにフルサイズのパケットを運べることが分かり、断片化禁止フラグ付きの失敗はトンネルの MTU に注意が必要だと示します。1472 バイトが通り、そのホストだけが固まるなら、ネットワークではなくグラフィック ドライバーと負荷を見てください。同じマシンへの高速なファイル コピーはスループットの話であり、RDP のグラフィック チャネルの話ではありません。一度に一つの変数だけを変え、同じ画面操作を繰り返して比較の意味を保ってください。

セッションがまったく開かないなら、それはフリーズではなく到達性なので、ここで止めてください。そうでなければ、症状を変えた転送設定を残し、クライアントのバージョンと一緒に記録します。