Impossible de se connecter à l’instance de rôle de travail « HealthMonitor » à l’aide de RDP

Cet article fournit des informations sur la résolution des problèmes dans lesquels l’instance de rôle de travail « HealthMonitor » n’est pas en mesure de se connecter à distance avec une erreur : cet ordinateur ne peut pas se connecter à l’ordinateur distant.

Version du produit d’origine : service Gestion des API
Numéro de la base de connaissances d’origine : 4464850

Note

En se référant à l’article sur la série de résolution des problèmes du service cloud Azure, il s’agit du sixième scénario du labo. Assurez-vous que vous avez suivi les instructions de configuration du laboratoire pour l’application Super Convertor en fonction de cela, pour recréer le problème.

Symptômes

Vous avez activé le protocole RDP pour tous les rôles de service cloud, mais pour une raison quelconque, la connexion Bureau à distance échoue uniquement pour l’instance de rôle de travail « HealthMonitor » qui lève l’erreur ci-dessous. Alors que RDP fonctionne comme prévu pour les autres instances de rôle de service cloud.

Étapes de résolution des problèmes

Le protocole Bureau à distance est encapsulé et chiffré dans TCP. Par défaut, le serveur écoute le port TCP 3389 pour la connexion RDP. Vérifiez d’abord si le port TCP 3389 est ouvert ou non. Vous pouvez utiliser PsPing ou telnet pour vérifier la connectivité au port 3389 pour votre nom d’hôte de service cloud.

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

Conformément aux statistiques ci-dessus, le port RDP est ouvert et le serveur répond comme prévu au test ping TCP sur le port 3389. Voici trois questions :

• Pourquoi le serveur ne répond pas à la demande de connexion RDP même si le port 3389 est ouvert ?
• Existe-t-il des listes de contrôle d’accès définies pour le service cloud ?
• Existe-t-il une règle de pare-feu Windows configurée à l’aide de la tâche de démarrage ?

Si vous avez vérifié le fichier ServiceDefinition.csdef , mais que vous n’avez pas trouvé de liste de contrôle d’accès configurée et qu’aucune tâche de démarrage n’était liée à la configuration du pare-feu pour cette solution de service cloud, la seule chose qui était laissée était de capturer une trace network Monitor et d’analyser le trafic RDP.

Nous allons fractionner la capture d’écran de trace réseau ci-dessus en deux moitiés pour mieux comprendre. Chaque session TCP est toujours établie avec la négociation tridirectionnel, qui est représentée par la première moitié de la capture d’écran.

Les trois premières images (90, 97 et 98) avec les indicateurs Syn, Syn/Ack et Ack représentés comme S, A.. S, et A, respectivement, est ce que l’on appelle collectivement l’établissement d’une négociation tcp tridirectionnel, qui réussit dans ce cas. Passer à la moitié ultérieure de la trace réseau, vous pouvez voir que le client a lancé une demande de connexion RDP représentée par X224 : Demande de connexion, mais n’a reçu aucune confirmation du côté serveur en fonction de la séquence de connexion RDP. La demande de connexion X.224 PDU est une séquence de connexion RDP envoyée du client au serveur pendant la phase d’initiation de connexion de la séquence de connexion RDP (section 1.3.1.1 pour obtenir une vue d’ensemble des phases de séquence de connexion RDP).

Au lieu de cela, le serveur décompose la session TCP avec un indicateur Fin (représenté comme A... F dans le numéro d’image 491). Le client reconnaît à son tour le paquet du serveur, puis se poursuit pour mettre fin brusquement à la session avec l’indicateur de réinitialisation (représenté sous la forme A.R..) dans la capture d’écran ci-dessous, en reconnaissant également la réception du pacte précédent du serveur (par conséquent, le A dans A dans A.R.).

Cela ressemble à un problème de pare-feu, car le serveur termine correctement la demande de connexion RDP une fois la négociation TCP terminée. Mais où ou comment sont configurées exactement les règles de pare-feu ? Lors de l’examen des WorkerRole.cs du rôle « HealthMonitor », vous pouvez constater que les règles de pare-feu ont été ajoutées par programmation à l’aide de l’interface INetFwRules. Par conséquent, les règles de pare-feu peuvent être ajoutées non seulement par le biais de tâches de démarrage ou de liste de contrôle d’accès, mais également par le biais du code d’application.

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);

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.