この記事では、"HealthMonitor" worker ロール インスタンスがエラーでリモート接続できない問題のトラブルシューティングに関する情報を提供します。このコンピューターはリモート コンピューターに接続できません。
元の製品バージョン: API Management サービス
元の KB 番号: 4464850
Note
Azure Cloud Service トラブルシューティング シリーズに関する記事を参照して、これはラボの 6 番目のシナリオです。 問題を再現するには、super Convertor アプリケーションのラボセットアップ手順 従っていることを確認してください。
現象
すべてのクラウド サービス ロールに対して RDP を有効にしましたが、何らかの理由で、"HealthMonitor" worker ロール インスタンスのみが失敗し、次のエラーがスローされます。 一方、RDP は他のクラウド サービス ロール インスタンスで想定どおりに動作します。
トラブルシューティングの手順
リモート デスクトップ プロトコルは、TCP 内でカプセル化および暗号化されます。 既定では、サーバーは TCP ポート 3389 で RDP 接続をリッスンします。 まず、TCP ポート 3389 が開いているかどうかを確認します。 PsPing または telnet を使用して、クラウド サービスのホスト名のポート 3389 への接続を確認できます。
psping.exe cloudservicelabs.cloudapp.net:3389
PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utilityCopyright (C) 2012-2014 Mark RussinovichSysinternals - www.sysinternals.com
TCP connect to 40.124.28.4:3389:
5 iterations (warmup 1) connecting test:
Connecting to 40.124.28.4:3389 (warmup): 281.25ms
Connecting to 40.124.28.4:3389: 279.08ms
Connecting to 40.124.28.4:3389: 283.01ms
Connecting to 40.124.28.4:3389: 269.29ms
Connecting to 40.124.28.4:3389: 270.12ms
TCP connect statistics for 40.124.28.4:3389:Sent = 4, Received = 4, Lost = 0 (0% loss),Minimum = 269.29ms, Maximum = 283.01ms, Average = 275.37ms
上記の統計に従って、RDP ポートが開いている間違いなく、サーバーはポート 3389 経由の TCP ping に期待どおりに応答しています。 次の 3 つの質問があります。
- ポート 3389 が開いている場合でも、サーバーが RDP 接続要求に応答しないのはなぜですか?
- クラウド サービスに対して定義されている Access コントロール リスト はありますか?
- スタートアップ タスクを使用して構成されたファイアウォール規則 はありますか?
ServiceDefinition.csdef ファイルを確認したが、構成されている ACL が見つからず、このクラウド サービス ソリューションのファイアウォール構成に関連するスタートアップ タスクがなかった場合、残されたのは、Network Monitor をキャプチャし RDP トラフィックをトレースして分析することだけです。
上記のネットワーク トレースのスクリーンショットを 2 つの半分に分割して、理解を深めましょう。 すべての TCP セッションは、スクリーンショットの前半で示されている 3 方向ハンドシェイクで常に確立されます。
最初の 3 つのフレーム (90、97、98) で、Syn、Syn/Ack、および Ack フラグが S、A. として示されています。S、A はそれぞれ TCP 3 ウェイ ハンドシェイクと総称され、この場合は成功します。 ネットワーク トレースの後半に進み、クライアントが X224: 接続要求によって示された RDP 接続要求を開始したが、 RDP 接続シーケンスに従ってサーバー側から確認を受信しなかったことがわかります。 X.224 接続要求 PDU は、RDP 接続シーケンスの接続開始フェーズ中にクライアントからサーバーに送信される RDP 接続シーケンス PDU です (RDP 接続シーケンスフェーズの概要については、セクション 1.3.1.1 )。
代わりに、サーバーは Fin フラグ (A... として示されています) を使用して TCP セッションを引き継いでいます。フレーム番号 491 の F)。 次に、クライアントはサーバーのパケットを確認し、下のスクリーンショットのリセット フラグ (A.R. として示されています) でセッションを突然終了し、サーバーからの以前のペース (つまり A.R. の A) の受信も確認します。
TCP ハンドシェイクが完了した後にサーバーが RDP 接続要求を正常に終了している場合、これはファイアウォールの問題のように見えます。 しかし、ファイアウォール規則はどこで、どのように正確に構成されますか? "HealthMonitor" ロールのWorkerRole.csを確認すると、 INetFwRules インターフェイスを使用してファイアウォール規則がプログラムによって追加されていることがわかります。 そのため、ファイアウォール規則は、スタートアップ タスクや ACL だけでなく、アプリケーション コードを介して追加することもできます。
Type Policy2 = Type.GetTypeFromProgID("HNetCfg.FwPolicy2", false);
INetFwPolicy2 FwPolicy = (INetFwPolicy2)Activator.CreateInstance(Policy2);
INetFwRules rules = FwPolicy.Rules;
rules.Remove("Magic Rule");
Type RuleType = Type.GetTypeFromProgID("HNetCfg.FWRule");
INetFwRule rule = (INetFwRule)Activator.CreateInstance(RuleType);
rule.Name = "Magic Rule";rule.Protocol = 6;
rule.LocalPorts = "3389";
rule.Action = NET_FW_ACTION_.NET_FW_ACTION_BLOCK;
rule.Direction = NET_FW_RULE_DIRECTION_.NET_FW_RULE_DIR_IN;
rule.Enabled = true;
rules.Add(rule);
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。