VPN 経由のリモートデスクトップ：どの失敗にいますか？

トンネルは上がり、社内 Wiki も読み込めるのに、リモートデスクトップは接続を拒否します。この組み合わせは正常で、VPN はホストへの経路を提供しますが、デスクトップサービスは待ち受け、自身のファイアウォールで許可され、アカウントを認証できる状態でなければなりません。正常なトンネルと使えるセッションの間には 四つの失敗段階があり、それぞれ別のメッセージで失敗します。段階の名前が書かれていますから、まずメッセージを読んでください。

一つに見える四つの失敗

段階には順序があり、名前が設計どおりのプライベートアドレスに解決され、ポートが TCP ハンドシェイクに応答し、ホストが自身のポリシーで接続を許可し、セッションのログインが成功します。各段階が次を検証不能にするため、ネットワークが整う前に RDP 設定を変えてもノイズが増えるだけです。ユーザーの側から見た症状は 四つの場合で同じに見えます。それらを分けるのはクライアントのメッセージだけです。

動く社内サイトは 四つのどれも証明しません。証明するのは、同じネットワークのホストが別のポートで別のサービスとして応答したことだけです。それはルーティングに関する証拠として扱い、それ以上ではないと考えてください。

順番にテストし、結果を書き留めます。ポートが応答したからとログイン画面に飛ぶのは、最初の手順ですでに特定できたファイアウォールの問題で午後を丸ごと費やす方法です。

3389 で何か待ち受けていますか？

誤ったアドレスに解決される名前は以降のテストをすべて無効にするため、名前から始めます。トンネルのリゾルバーに名前の意味を尋ね、その答えを成功応答ではなく設計どおりのプライベートアドレスと比較します。公開アドレスに解決される名前ならそれが問題そのもので、RDP の変更では直りません。

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

次にホストではなくポートをテストします。3389 で TCP ハンドシェイクが完了すれば、到達性をそれより上の層から切り分けられます。

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

二つの結果の差が障害を VPN 経路に限定するため、このテストは LAN からもトンネルからも実行します。経路にはファイアウォールが二つあり混同しやすいところで、ネットワークはクライアントのトンネルアドレスからホストへの到達を許可し、ホスト自身のファイアウォールは同じ送信元を待ち受けポートで許可する必要があります。LAN サブネットに限定した規則は VPN クライアントプールを覆わず、これがリモートユーザーだけが報告するタイムアウトの最も一般的な原因です。規則の有無ではなく適用範囲を確認してください。

戻り経路にも同じ確認が必要です。応答にはクライアントプールへの戻り経路が必要で、LAN 向きではなく、ホストの手前の変換はログに表示される送信元を変えます。ポートが片方向だけ応答する場合、欠けている半分は通常、戻り経路です。

設定を読む前にメッセージを読む

三番目の段階は、ホストが自身のポリシーで接続を拒否することで、すぐに開いて閉じるポートのように見えることがよくあります。何かが応答しており、それは沈黙より有用な情報です。ハンドシェイクが完了してセッションが即座に切れたなら、ネットワークは正常でホストが判断しています。ネットワークに再び触れる前に、リモートデスクトップの権限を確認してください。

機能はマシンで有効でも、アクセスが特定のグループに制限されていることがあり、リスナーが到着したアドレスを除外する形でバインドされていることもあります。ネットワークレベル認証はデスクトップが読み込まれる前に失敗するゲートを追加し、そのエラーテキストは誤ったパスワードとは異なります。クライアントのメッセージはゲートを、ホストのイベントログはアカウントを示すため、両者を比較してください。

セッションのログインはそれ自体が境界

認証は VPN ではなくデスクトップサービスに属します。トンネルの ID とデスクトップアカウントは別々の資格情報でロックアウトのポリシーも別なので、トンネルが動くことはトンネルがあなたを受け入れたことだけを証明します。デスクトップアカウントをロックしてもトンネルは乱されず、逆もまた同じです。

両方をそのまま保ちます。プライベート経路が欠けているなら、リスナーをインターネットに公開すると到達性の不具合を露出したデスクトップと交換することになるため、経路を直してください。同時に現れた証明書の警告を抜けるためにセッションの ID 確認を弱めてもいけません。RDP リスナーの自己署名証明書は設計上警告を出すので、受け入れるのは手順ではなく判断です。

再試行する前に試行回数を数えます。デスクトップのロックアウトしきい値は VPN の失敗とは別にログイン失敗を数えるため、タイマーで再試行するクライアントは、あなたがまだ規則を編集している間にしきい値を超えることがあります。これはパスワード変更後にアカウントをロックするのと同じ並行再試行の仕組みです。

セッションが運べるもの、残るもの

必要になる前に承認されたサインアウト手順を学んでください。ウィンドウを閉じても表示が切れるだけで、セッションは設定されたポリシーの下で動き続けることがあり、共有または監査対象のホストでは重要です。ポリシーが求める場合はセッションの内側からサインアウトしてください。

クリップボード、リダイレクトされたドライブ、プリンターのリダイレクト、ファイル転送はポリシーが許す範囲でローカルとリモートのシステム間でデータを移動させるため、次にセッションが何を運べるかを決めます。向こう側で動く公開アプリケーションは自動的にダウンロード不可の境界ではなく、読み取り専用に見えるセッションでもクリップボードを運べます。ファイルを開き、アプリケーションを使い、必要なリダイレクトを確認するなど、接続ではなく実際の作業をテストしてください。外部からリモートデスクトップに到達するための Microsoft のガイダンスはサポートされる公開オプションを説明しており、圧力の下で追加した公開リスナーより良い参照先です。