J'ai du mal à me connecter à une instance Windows d'Amazon EC2. Existe-t-il des outils permettant de résoudre les problèmes de connexion réseau ?

Les problèmes de connectivité entre les nœuds d'un réseau TCP/IP sont généralement dus à des informations de routage incorrectes dont les causes peuvent être les suivantes, sans s'y limiter :

  • Serveur(s) DNS non autorisé(s) : si un client demande des informations à un serveur DNS non autorisé qui est mal configuré, les informations renvoyées ne sont pas fiables.
  • Entrées incorrectes du fichier HOSTS : Windows implémente un fichier HOSTS où les mappings hôte-adresse IP peuvent être définis statiquement. Sur les systèmes d'exploitation Windows, ce fichier se trouve dans le répertoire « %SystemRoot%\system32\drivers\etc\hosts », où %SystemRoot% est la variable d'environnement qui référence l'emplacement du lecteur et du dossier d'installation de Windows. Les entrées du fichier HOSTS de Windows respectent le format suivant :
        1.2.3.4    hostname
    1.2.3.4 correspond à l'adresse IP physique utilisée pour référencer hostname.
    Le comportement par défaut de toutes les versions de Windows consiste à consulter le fichier HOSTS avant d'essayer les autres méthodes de résolution du nom d'hôte, telles que DNS. Par conséquent, si l'adresse IP affectée à un nom d'hôte dans le fichier HOSTS local d'un client Windows est incorrecte, le nom d'hôte est résolu en cette adresse IP incorrecte jusqu'à ce que l'entrée du fichier HOSTS soit corrigée ou que l'ordre de résolution des noms de réseau Windows soit modifié comme décrit dans l'article Comment modifier l'ordre de résolution des noms sous Windows 95 et Windows NT.

Remarque : L'article de la base de connaissances Microsoft indique à tort que « par défaut, Windows 2000 et les versions ultérieures essaient de résoudre un nom via DNS avant d'essayer de le résoudre à l'aide de la configuration du type de nœud des versions antérieures. »

  • Panne matérielle : en cas de panne matérielle d'un serveur DNS, les enregistrements DNS gérés par les serveurs DNS ne sont pas mis à jour comme prévu, ce qui peut entraîner l'envoi de mappings hôte-adresse IP incorrects aux clients.
  • Ports TCP/IP bloqués : si un port requis par un service ou un protocole de la couche applicative est bloqué, les communications réseau sont bloquées.
  • Configuration TCP/IP du client incorrecte : si un client est mal configuré, il peut rencontrer des problèmes de connectivité de divers niveaux. Cela peut se produire lorsqu'un client est configuré pour utiliser la configuration TCP/IP automatique et qu'il est incapable de récupérer les informations de configuration ou qu'il reçoit des informations de configuration incorrectes.

L'utilitaire ping envoie un paquet ICMP (Internet Control Message Protocol) à l'adresse IP ou au nom de réseau indiqué depuis un client :

C:\WINDOWS\system32>ping www.amazon.com

Envoi d'une demande Ping à www.amazon.com [205.251.242.54] avec 32 octets de données :

Délai d'attente de la demande dépassé.

Délai d'attente de la demande dépassé.

Délai d'attente de la demande dépassé.

Délai d'attente de la demande dépassé.

 

Statistiques Ping pour 205.251.242.54 :

    Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100 %)

De nombreux serveurs accessibles publiquement annulent la priorité des paquets ICMP entrants. En conséquence, il n'est pas rare qu'une demande ping renvoie la réponse « Délai d'attente de la demande dépassé ». Lors du lancement d'une demande ping, il est important de vérifier les points suivants :

  1. La demande ping résout-elle le nom en adresse IP ? Par exemple, dans l'exemple précédent, le nom www.amazon.com a été résolu en adresse IP 205.251.242.54 même si le délai d'attente de toutes les demandes ping a été dépassé. Si un autre nom d'hôte avait été utilisé, par exemple www.bamazon.com, la résolution de nom aurait échoué et aucune demande ping n'aurait été tentée :
           C:\WINDOWS\system32>ping www.bamazon.com
           La demande Ping n'a pas pu trouver l'hôte www.bamazon.com. Vérifiez le nom et essayez à nouveau.
  2. Si le nom est résolu en adresse IP, il y a de grandes chances que la destination soit accessible via un autre service ou protocole de la couche applicative. Par exemple, même si le délai d'attente d'une demande ping à www.amazon.com est dépassé, la connexion à http://www.amazon.com aboutit généralement, car cette destination est un serveur Web qui accepte les demandes de navigateur via le port TCP 80.
  3. Si la demande ping aboutit et qu'une réponse est renvoyée, vérifiez que 4 réponses ont été renvoyées dans un délai raisonnable (<250 ms). Utilisez le commutateur -c pour spécifier le nombre de demandes ping. Si moins de 4 réponses sont renvoyées ou si le temps de réponse dépasse 250 ms, des étapes de dépannage supplémentaires peuvent être requises. Pour spécifier le délai d'attente d'une demande ping en millisecondes, utilisez le commutateur -w. Pour envoyer continuellement des demandes ping à la destination jusqu'à ce qu'elle soit arrêtée, utilisez le commutateur -t.
  4. L'adresse IP est-elle résolue en nom d'hôte ? Pour tester la résolution d'adresse en nom d'hôte, utilisez le commutateur -a et spécifiez l'adresse IP de la destination. Par exemple, la demande ping suivante teste la résolution d'adresse en nom d'hôte d'une des adresses IP associées à www.ubuntu.org :
           C:\WINDOWS\system32>ping -a 82.98.134.233
           Envoi d'une demande Ping à hl231.dinaserver.com [82.98.134.233] avec 32 octets de données :
           Réponse de 82.98.134.233 : octets=32 délai=166 ms durée de vie=49
           Réponse de 82.98.134.233 : octets=32 délai=184 ms durée de vie=49
           Réponse de 82.98.134.233 : octets=32 délai=176 ms durée de vie=49
           Réponse de 82.98.134.233 : octets=32 délai=165 ms durée de vie=49
           Statistiques Ping pour 82.98.134.233 :
               Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0 %),
           Durée approximative des boucles en millisecondes :
               Minimum = 165 ms, Maximum = 184 ms, Moyenne = 172 ms

    Notez que la réponse a renvoyé le nom hl231.dinaserver.com, qui est l'un des serveurs Web à charge équilibrée traitant les demandes de http://www.ubuntu.org.

Pour en savoir plus sur le protocole ICMP, consultez Understanding the ICMP Protocol (Part 1) et Understanding the ICMP Protocol (Part 2).

L'utilitaire Windows tracert identifie le chemin suivi depuis un nœud client jusqu'au nœud de destination spécifié et le temps de réponse à une demande, en millisecondes, de chaque routeur identifié dans ce chemin. Par défaut, l'utilitaire tracert utilise une valeur maximale par défaut de 30 sauts. Si le chemin entre le client et la destination nécessite plus de 30 routeurs ou sauts, vous pouvez augmenter le nombre maximal de sauts à l'aide du commutateur -h. Etant donné que les demandes tracert dépendent des réponses aux demandes ICMP, certains sauts de l'itinéraire peuvent abandonner des demandes en faveur d'un trafic réseau ayant une priorité supérieure.

Les données de sortie suivantes ont été créées à l'aide de la commande Windows tracert par défaut. Dans cet exemple, un message « Délai d'attente de la demande dépassé » est renvoyé au niveau des sauts 1, 2, 3 et 15 :

C:\Users\Administrator>tracert www.ubuntu.org

Détermination de l'itinéraire vers www.ubuntu.org [82.98.134.233]

avec un maximum de 30 sauts :

  1     *        *        *     Délai d'attente de la demande dépassé.

  2     *        *        *     Délai d'attente de la demande dépassé.

  3     *        *        *     Délai d'attente de la demande dépassé.

  4     1 ms    <1 ms    <1 ms  100.64.16.13

  5     1 ms     1 ms     1 ms  205.251.232.254

  6     2 ms     3 ms     2 ms  205.251.232.148

  7     9 ms     9 ms     9 ms  205.251.232.91

  8     9 ms     8 ms     8 ms  205.251.226.188

  9    10 ms     9 ms     9 ms  ae-14.r04.sttlwa01.us.bb.gin.ntt.net [129.250.201.169]

 10    10 ms     9 ms     7 ms  ae-6.r21.sttlwa01.us.bb.gin.ntt.net [129.250.5.44]

 11    75 ms    76 ms    91 ms  ae-3.r22.nycmny01.us.bb.gin.ntt.net [129.250.2.50]

 12   145 ms   145 ms   145 ms  ae-5.r22.londen03.uk.bb.gin.ntt.net [129.250.3.127]

 13   170 ms   168 ms   172 ms  ae-6.r01.mdrdsp03.es.bb.gin.ntt.net [129.250.4.138]

 14   171 ms   171 ms   168 ms  dinahosting-0.r01.mdrdsp03.es.bb.gin.ntt.net [62.73.183.78]

 15     *        *        *     Délai d'attente de la demande dépassé.

 16   176 ms   165 ms   179 ms  hl231.dinaserver.com [82.98.134.233]

Itinéraire déterminé.

Le dépassement du délai d'attente de quelques demandes ne constitue généralement pas un problème dont il faut s'inquiéter. Par contre, vous devez surveiller les pertes de paquets à destination ou au niveau du dernier saut de l'itinéraire. L'accumulation de pertes de paquets sur plusieurs sauts peut également indiquer un problème.

Important : Lorsque vous résolvez les problèmes de connectivité réseau à l'aide de l'utilitaire Windows tracert, il est souvent bénéfique d'exécuter la commande dans les deux sens, c'est-à-dire du client vers le serveur, puis du serveur vers le client. S'il y a des différences de latence importantes dans l'un des chemins, envisagez de consulter l'excellent article Traceroute (http://cluepon.net/ras/traceroute.pdf) de Richard A Steenbergen. L'auteur y décrit en détails les complexités d'une analyse correcte de l'itinéraire.

  • Tracetcp (http://simulatedsimian.github.io/tracetcp.html) offre la possibilité de spécifier des ports TCP dans le but d'obtenir des informations de traçage. Son utilisation s'avère particulièrement utile si plusieurs routeurs entre une source et une destination annulent la priorité du trafic ICMP ou bloquent celui-ci.
  • Winmtr (http://winmtr.net/) est l'équivalent Windows de l'utilitaire Linux mtr.

Amazon Elastic Compute Cloud, Windows, résolution des problèmes réseau, ping, tracert

En plus de ping et tracert, envisagez d'utiliser l'un des nombreux utilitaires disponibles publiquement proposés par les fournisseurs de service Internet (ISP), tels que les serveurs « Looking Glass ». Pour en savoir plus, consultez l'article Wikipédia Looking Glass Server.

Pour en savoir plus sur la résolution des problèmes TCP/IP, consultez les informations suivantes :


Cette page vous a-t-elle été utile ? Oui | Non

Retour au Centre de connaissances AWS Support

Vous avez besoin d'aide ? Consultez le site du Centre AWS Support

Date de publication : 05/12/2015
Date de mise à jour : 18/02/2016