J'ai du mal à me connecter à une instance Linux 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 : la plupart des systèmes d'exploitation implémentent un fichier HOSTS où les mappings hôte-adresse IP peuvent être définis statiquement. Sur les systèmes d'exploitation Linux, ce fichier est généralement conservé dans le répertoire /etc/hosts et il a le format suivant :
1.2.3.4 hostname
où 1.2.3.4 correspond à l'adresse IP physique utilisée pour référencer hostname. - 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 :
ubuntu@ip-10-0-0-252:~$ sudo ping -c 1 www.amazon.com
PING www.amazon.com (54.239.19.16) 56(84) bytes of data.
--- www.amazon.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
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 des statistiques indiquant 100 % de perte de paquets. Lors du lancement d'une demande ping, il est important de vérifier les points suivants :
- 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 54.239.19.16 même si aucune réponse ping n'a été renvoyée. 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 :
ubuntu@ip-10-0-0-252:~$ sudo ping -c 1 www.bamazon.com
ping: unknown host www.bamazon.com
- 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 80.
- Si la demande ping aboutit et qu'une réponse est renvoyée, vérifiez que les 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 la moitié des demandes ping spécifiées sont renvoyées ou si le temps de réponse moyen 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 -W avec la valeur 0, par exemple :
sudo ping –W 0 www.ubuntu.org
Appuyez sur la combinaison de touches Ctrl+C pour arrêter de générer des demandes ping. - L'adresse est-elle résolue en nom d'hôte ? Pour tester la résolution d'adresse en nom d'hôte, utilisez la commande Linux nslookup et spécifiez l'adresse IP de la destination. Par exemple, la demande nslookup suivante en mode non interactif teste la résolution d'adresse en nom d'hôte d'une des adresses IP associées à www.ubuntu.org :
ubuntu@ip-10-0-0-252:~$ nslookup 82.98.134.233
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
233.134.98.82.in-addr.arpa name = hl231.dinaserver.com.
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 Linux traceroute 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 traceroute 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 traceroute 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.
La commande traceroute suivante a été émise à partir d'une instance Amazon Web Services EC2 d'Ubuntu Linux 14.04. Les arguments -T -p 80 -n exécutent un traçage basé sur TCP sur le port 80 et renvoient les adresses IP au lieu des noms d'hôte. L'option Linux traceroute permettant de spécifier un traçage basé sur TCP au lieu de s'appuyer sur le protocole ICMP est utile car la plupart des appareils Internet annulent la priorité des demandes trace basées sur ICMP. L'option Linux traceroute permettant de récupérer uniquement les adresses IP est utile lorsque les noms d'hôte renvoyés sont incorrects ou trompeurs :
ubuntu@ip-10-0-0-252:~$ sudo traceroute -T -p 80 -n www.ubuntu.org
traceroute to www.ubuntu.org (82.98.134.233), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 100.64.16.75 1.176 ms
100.64.16.129 1.059 ms
100.64.16.209 0.923 ms
5 54.239.48.178 3.958 ms
54.239.48.184 1.200 ms
54.239.48.178 1.805 ms
6 205.251.232.204 1.198 ms
205.251.232.154 1.793 ms
205.251.232.142 1.549 ms
7 205.251.232.76 6.341 ms
205.251.232.78 6.546 ms
205.251.232.76 7.611 ms
8 205.251.226.230 6.220 ms 7.418 ms
205.251.226.192 8.096 ms
9 198.104.202.189 9.178 ms
129.250.201.165 9.006 ms
198.104.202.181 9.001 ms
10 129.250.5.44 8.746 ms
129.250.5.48 8.912 ms
129.250.5.44 27.57 ms
11 * 129.250.2.50 86.83 ms *
12 129.250.3.127 153.9 ms 144.401 ms 161.867 ms
13 129.250.4.138 176.5 ms 165.466 ms 181.772 ms
14 62.73.183.78 166.5 ms 166.834 ms 169.297 ms
15 * * *
16 82.98.134.233 177.9 ms 164.656 ms 169.607 ms
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 traceroute, 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.
La commande Linux mtr fournit une sortie mise à jour en permanence, ce qui vous permet d'analyser les performances du réseau au fil du temps.
Remarque : Si l'utilitaire mtr n'est pas installé sur Ubuntu Linux, obtenez-le en exécutant la commande suivante :
sudo apt-get install mtr
Pour afficher la liste des options de ligne de commande mtr, exécutez la commande mtr -h
ubuntu@ip-10-0-0-252:~$ mtr www.ubuntu.org
My traceroute [v0.85]
ip-10-0-0-252 (0.0.0.0) Sat Nov 22 18:54:13 2014
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. ???
2. ???
3. ???
4. 100.64.16.139 0.0% 64 2.4 2.3 0.6 32.6 5.4
5. 54.239.48.186 0.0% 64 0.9 2.2 0.8 19.8 4.0
6. 205.251.232.210 0.0% 64 1.5 2.4 0.7 17.7 3.7
7. 205.251.232.76 0.0% 64 37.6 11.1 6.1 47.2 7.9
8. 205.251.225.165 0.0% 64 14.2 7.1 5.6 28.4 4.2
9. ae-8.r05.sttlwa01.us.bb.gin.ntt.net 0.0% 63 7.7 9.3 7.3 26.7 4.9
10. ae-7.r21.sttlwa01.us.bb.gin.ntt.net 0.0% 63 7.4 10.2 7.2 35.4 6.1
11. ae-3.r22.nycmny01.us.bb.gin.ntt.net 22.2% 63 73.7 82.2 73.1 101.7 8.8
12. ae-5.r22.londen03.uk.bb.gin.ntt.net 0.0% 63 153.1 159.2 142.1 223.3 17.7
13. ae-6.r01.mdrdsp03.es.bb.gin.ntt.net 0.0% 63 174.9 176.1 165.4 193.2 6.3
14. dinahosting-0.r01.mdrdsp03.es.bb.gin.ntt.net 0.0% 63 174.6 182.7 164.1 263.1 21.3
15. ???
16. hl231.dinaserver.com 0.0% 63 175.5 178.4 166.1 200.4 7.4
mtr fournit également une option --report qui résume les résultats de l'envoi de 10 paquets ping à chaque tronçon :
ubuntu@ip-10-0-0-252:~$ mtr --report www.ubuntu.org
Start: Sat Nov 22 19:06:10 2014
HOST: ip-10-0-0-252 Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- 100.64.16.139 0.0% 10 0.8 0.8 0.5 1.4 0.0
5.|-- 54.239.48.186 0.0% 10 1.0 1.1 0.8 2.0 0.0
6.|-- 205.251.232.210 0.0% 10 0.8 1.3 0.8 2.9 0.5
7.|-- 205.251.232.76 0.0% 10 6.1 8.3 6.1 18.2 3.4
8.|-- 205.251.225.165 0.0% 10 6.3 5.8 5.6 6.3 0.0
9.|-- ae-8.r05.sttlwa01.us.bb.g 0.0% 10 7.5 7.5 7.4 7.6 0.0
10.|-- ae-7.r21.sttlwa01.us.bb.g 0.0% 10 8.8 10.2 7.3 33.4 8.1
11.|-- ae-3.r22.nycmny01.us.bb.g 0.0% 10 73.8 78.2 73.3 108.2 10.9
12.|-- ae-5.r22.londen03.uk.bb.g 10.0% 10 151.6 154.8 145.4 169.5 6.5
13.|-- ae-6.r01.mdrdsp03.es.bb.g 0.0% 10 175.0 174.1 165.7 178.3 3.5
14.|-- dinahosting-0.r01.mdrdsp0 0.0% 10 173.8 172.2 165.1 176.4 4.3
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
16.|-- hl231.dinaserver.com 10.0% 10 183.1 177.9 168.1 192.4 7.5
Remarque : Etant donné que le chemin entre les nœuds d'un réseau TCP/IP peut changer quand le sens est inversé, il est important d'obtenir les résultats du traçage d'itinéraire dans les deux sens.
Amazon Elastic Compute Cloud, Linux, résolution des problèmes réseau, ping, traceroute, tracert, mtr
En plus de ping, traceroute et mtr, 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 Traceroute.
Quelles sont les commandes Linux les plus couramment utilisées ?
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.
