リモートコンピューターが VPN に接続すると RDP が固まる理由

あなたは RDP のウィンドウの中にいて、デスクトップが画面に映っており、そのリモートマシン上で動く VPN クライアントの Connect を押す。数秒後にウィンドウは固まり、やがて閉じる。トンネルは上がった。VPN のログが報告するのはまさにその点であり、それがこのインシデント全体で最も役に立たない事実だ。セッションが死んだのは、話していたマシンが応答の返し方を変えたからであり、トンネルに触る前に戻り経路を確認すべきだ。

セッションが実際に使っているエンドポイントを記録する

RDP クライアントに入力したアドレスが、リモート PC が応答するアドレスとは限らない。NAT、RD Gateway、あるいはホスト前段のロードバランサーがそれを書き換えることがあり、戻り経路は、確立済みの接続でリモートマシンが見ている送信元アドレスによって決まる。ここを誤ると、実際には関与していないルートを探すことになる。

リモート PC で、VPN を接続する前に、確立済みのセッションを一覧し、表からピアアドレスを読み取る。その後、そのマシンの外に書き留めておく。セッションが落ちた後では読めなくなるからだ。

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

そのアドレスは到達可能なまま保たなければならないものとして扱う。管理 VLAN 上のプライベートアドレスなら、トンネルはその経路に手を出してはならない。パブリックアドレスなら、応答は要求を運んできたのと同じインターフェイスから出ていく必要がある。

そのエンドポイントに応答するルートを読む

Windows は宛先ごとにインターフェイスを選び、Find-NetRouteは今そこが下す判断を示す。接続前にピアアドレスに対して実行し、次にトンネルを上げた状態でもう一度実行して、二つの答えのインターフェイスインデックスとネクストホップを比べる。インターフェイスが変わること、それが出力一行に表れたバグの全体だ。

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

フルトンネルプロファイルはトンネル経由のデフォルトルートをインストールする。Windows の VPN ルーティングガイドが説明するとおりで、すべての応答は VPN から出るようになり、相手側があなたのクライアントへ戻る経路を持っているかに依存する。スプリットトンネルプロファイルは既定ではより安全だが無敵ではなく、ピアアドレスを覆う特定のルートが物理的なデフォルトルートに勝つことはありうる。いずれにせよ問いは同じで、トンネルが上がった後、ピアアドレスはセッションを運んできたインターフェイスにまだ解決されるのか。

そうでなければ、修正はプロファイル側か、VPN ポリシーの所有者が承認した明示的な例外ルートに入る。インシデントの最中に本番ホストのルーティングテーブルを手で編集するのは、一時的な回避策が文書化されない構成になる道だ。

ファイアウォールプロファイルの変化を見る

新しいインターフェイスは現れた時点で分類され、その分類によって、どのファイアウォールプロファイルで通信が判定されるかが決まる。Public カテゴリに入ったトンネルアダプターは、ルーティングテーブルが完璧に見えても、受信 RDP を静かに止めうる。これが 二つ目の故障モードで、症状は異なる。ルートは正しく、パケットは届いているのに、ホストが接続を拒む。

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

トンネルインターフェイスに付いたプロファイルと、Remote Desktop の規則が対象としているプロファイルを比べる。Domain と Private だけで有効な規則は、Public と分類されたインターフェイスには何もしないし、ルートを直しても変わらない。VPN クライアントによっては設計上ローカルサブネットへのアクセスを制限しており、別の制御から同じ形の故障が起きる。

復旧できる場所から切り替えを試す

帯域外コンソールか 二本目の管理経路から、この順で全体を通す。既存セッションを確認し、VPN を接続し、新しいセッションを開き、次に VPN を切断してもう一つ開く。各手順は別の切り替えを試しており、最初に失敗した箇所がどの制御のせいかを教えてくれる。

始める前にロールバックを予定しておく。たとえば一定時間後にrasdial "Work VPN" /disconnectを実行するスケジュールタスクだ。これで失ったセッションは、現地訪問ではなく 五分の中断になる。手順全体で最も安い保険だ。

セッションがすでに消えた後に戻る

ホストにすでに到達できないなら、同じクライアントからの新しい RDP 接続を試すのをやめ、環境がすでに持っている復旧経路を使う。RD Gateway、ハイパーバイザーのコンソール、帯域外の管理インターフェイスだ。コンソールにアクセスできる人に、同じFind-NetRouteとGet-NetConnectionProfileのコマンドを実行してもらい、証拠が復旧後も残るようにする。

そのうえで、最短ではなく恒久的な取り決めを決める。管理経路を VPN プロファイルで明示的に保持するか、管理をホストのデフォルトルートに依存しない経路へ移すかだ。どちらも支持できる。推測したゲートウェイを使うホストルートは支持できない。どちらを選んだかを書き、生き残らせる必要があったピアアドレスを記録する。