パブリック ネットワーク用 RDP Shortpath のトラブルシューティング
この記事は、パブリック ネットワークにリモート デスクトップ プロトコル (RDP) Shortpath を使用する場合の問題のトラブルシューティングに役立ちます。
STUN、TURN サーバー接続、NAT の種類を確認する
STUN および TURN エンドポイントへの接続を検証し、実行可能な avdnettest.exeを実行することで、基本的なユーザー データグラム プロトコル (UDP) 機能が機能することを確認できます。 最新バージョンの avdnettest.exe へのダウンロード リンクはこちらです。
avdnettest.exeを実行するには、ファイルをダブルクリックするか、コマンド ラインから実行します。 接続が成功した場合、出力は次のようになります。
Checking DNS service ... OK
Checking TURN support ... OK
Checking ACS server <IP Address:Port Number> ... OK
Checking ACS server <IP Address:Port Number> ... OK
You have access to TURN servers and your NAT type appears to be 'cone shaped'.
Shortpath for public networks is very likely to work on this host.
Log Analytics に記録されたエラー情報
Log Analytics にログに記録されるエラー タイトルとその意味を次に示します。
ShortpathTransportNetworkDrop
伝送制御プロトコル (TCP) 接続には、次の 2 つの異なるパスがあります。
- セッション ホストからゲートウェイへ
- ゲートウェイからクライアントへ
ただし、UDP 接続の場合、ゲートウェイが関係しないため、この違いは適用されません。 TCP でのもう 1 つの違いは、多くの場合、エンドポイントの 1 つ (または、中央の何らかのインフラストラクチャの場合もある) で TCP リセット パケット (RST 制御ビット) が生成され、それにより、TCP 接続のハード シャットダウンが引き起こされることです。 これは、TCP RST (および正常なシャットダウンのための TCP FIN) がオペレーティング システムと一部のルーターによって処理されるものの、アプリケーションでは処理されないことで行われます。 つまり、アプリケーションがクラッシュした場合、Windows は TCP 接続が切断されたことをピアに通知しますが、UDP にそのようなメカニズムは存在しません。
ConnectionFailedClientDisconnect や ConnectionFailedServerDisconnect などのほとんどの接続エラーは、タイムアウトではなく TCP リセット パケットによって発生します。オペレーティング システムまたはルーターが UDP を使用して何かを通知する方法がないため、ピアがなくなったことを知る唯一の方法はタイムアウト メッセージです。
ShortpathTransportReliabilityThresholdFailure
このエラーは、接続が切断されていない場合でも、特定のパケットが通過しない場合にトリガーされます。 パケットは最大 50 回再送信されるため、可能性は低いですが、次のシナリオで発生する可能性があります。
- 接続は、突然動作を停止する前に、高速かつ安定しています。 パケットが失われたと宣言されるまでに必要なタイムアウトは、クライアントとセッション ホストの間のラウンドトリップ時間 (RTT) によって異なります。 RTT が低い場合、一方の側はパケットの再送信を頻繁に試行できるため、50 回の試行に達するまでにかかる時間は、通常のタイムアウト値である 17 秒よりも短くなる可能性があります。
- パケットが大きい。 送信できる最大パケット サイズには制限があります。 パケットのサイズはプローブされますが、変動したり、縮小したりすることがあります。 その場合、送信されるパケットが大きすぎて、一貫して失敗する可能性があります。
ConnectionBrokenMissedHeartbeatThresholdExceeded
これは RDP レベルのタイムアウトです。構成が正しくないため、RDP レベルのタイムアウトは、UDP レベルのタイムアウトの前にトリガーされることがあります。