Comment puis-je résoudre les problèmes de performances réseau entre les instances EC2 Linux ou Windows d’un VPC et un hôte sur site via la passerelle Internet ?

Lecture de 13 minute(s)
0

Je souhaite résoudre les problèmes de perte de paquets ou de latence entre mes instances Amazon Elastic Compute Cloud (Amazon EC2) d’un réseau Amazon Virtual Private Cloud (Amazon VPC) et un hôte sur site via la passerelle Internet.

Brève description

Pour diagnostiquer les problèmes réseau tels que la perte de paquets ou la latence, testez d’abord le réseau afin d’isoler la source du problème. Avant de résoudre le problème, il est recommandé de comparer les résultats des performances.

Conditions préalables :

Résolution

Installez les outils suivants pour vous aider à dépanner et à tester le réseau :

  • AWSSupport-SetupIPMonitoringFromVPC pour collecter des métriques réseau telles que la perte de paquets, la latence, MTR, tcptraceroute et tracepath.
  • Utilisez MTR pour vérifier la perte de paquets ICMP ou TCP et la latence.
  • Utilisez la détermination d’itinéraire pour déterminer les problèmes de latence ou d’itinéraire.
  • Utilisez Hping3 pour déterminer les problèmes de perte de paquets TCP et de latence de bout en bout.
  • Utilisez tcpdump pour analyser les échantillons de capture de paquets.

Consulter les rapports de détermination d’itinéraire ou MTR

Dans les rapports de détermination d’itinéraire ou MTR, examinez les sauts en appliquant une approche ascendante. Dans une approche ascendante, vous vérifiez d’abord l’absence de perte au dernier saut ou à la dernière destination, puis vous examinez les sauts précédents.

  • Si les problèmes de perte de paquets ou de latence persistent jusqu’au dernier saut, il peut s’agir d’un problème de réseau ou d’itinéraire.
  • Si une limite de débit est appliquée au plan de contrôle sur ce nœud, une perte de paquets ou une latence sur un saut du chemin peuvent survenir.
  • Vérifiez si le dernier saut signalé est bien la destination indiquée dans la commande. Si le dernier saut n’est pas indiqué, cela peut être dû à un groupe de sécurité restrictif.

Tester les performances à l’aide d’AWSSupport-SetupIPMonitoringFromVPC

Cet outil intégré collecte de nombreuses métriques nécessaires au dépannage du réseau. Pour plus d’informations, consultez l’article Outil de débogage de la connectivité réseau à partir d’Amazon VPC.

Résolution des problèmes de performances des instances Linux

Consulter les statistiques de performances Linux

Si vous avez accès à l’instance source ou à l’instance de destination, vérifiez la présence de problèmes liés au processeur, à l’utilisation de la mémoire et à la charge moyenne.

Tester les performances à l’aide de MTR

La commande Linux MTR fournit une sortie continuellement mise à jour. Cet outil de diagnostic combine les fonctionnalités des utilitaires de détermination d’itinéraire et ping. La sortie de cet outil vous permet d’analyser les performances du réseau. La plupart des distributions Linux sont livrées avec les outils de détermination d’itinéraire et MTR préinstallés. Vous pouvez également télécharger MTR depuis le gestionnaire de packages logiciels de votre distribution.

Exécutez les commandes suivantes pour installer MTR :

Amazon Linux :

sudo yum install mtr

Ubuntu :

sudo apt-get install mtr-tiny

Pour tester les performances du réseau à l’aide de MTR, exécutez ce test de manière bidirectionnelle entre l’adresse IP publique des instances EC2 et l’hôte sur site. Si le sens est inversé, le chemin entre les nœuds d’un réseau TCP/IP peut changer. Il est recommandé d’obtenir les résultats du test MTR dans les deux sens. Vous pouvez utiliser un suivi basé sur TCP au lieu d'ICMP, car la plupart des appareils Internet dépriorisent les demandes de suivi basées sur ICMP.

Vérifiez la perte de paquets. Une perte de paquets ayant lieu lors d’un saut unique n’indique généralement pas de problème. Cette perte peut résulter d’une politique de plan de contrôle qui entraîne la suppression des messages « Temps ICMP dépassé ». Si vous constatez une perte de paquets prolongée jusqu’au saut de destination ou sur plusieurs sauts, alors cela peut indiquer un problème.

Remarque : il est courant que certaines demandes arrivent à expiration.

Remplacez PUBLIC_IP par l’hôte sur site de l’instance IP publique EC2.

MTR basé sur ICMP :

mtr -n -c 200 PUBLIC_IP --report

MTR basé sur TCP :

mtr -n -T -c 200 PUBLIC_IP --report

L’argument -T effectue un test MTR basé sur TCP et l’option report génère le résultat MTR dans un rapport. MTR s’exécute pendant le nombre de cycles spécifié par l’option -c. Imprimez les statistiques, puis quittez le programme.

Remarque : le MTR basé sur TCP teste le port TCP de destination 80, pour effectuer un test MTR sur un port TCP de destination spécifique, ajouté par -P, suivi du numéro de port. Voici un exemple de test MTR sur un port TCP 443 de destination :

mtr -n -T -c 200 PUBLIC_IP -P 443 --report

Tester les performances à l’aide de l’utilitaire de détermination d’itinéraire

L’utilitaire de détermination d’itinéraire de Linux identifie le chemin entre un nœud client et le nœud de destination. Il enregistre le temps nécessaire, en millisecondes, à chaque routeur pour répondre à la demande. L’utilitaire calcule également le temps nécessaire à chaque saut avant d’atteindre sa destination.

Pour installer l’utilitaire de détermination d’itinéraire, exécutez les commandes suivantes :

Amazon Linux :

sudo yum install traceroute

Ubuntu :

sudo apt-get update
 `sudo apt-get install traceroute`

Remarque : si vous exécutez un rapport MTR, il n’est pas nécessaire d’exécuter l’utilitaire de détermination d’itinéraire. MTR fournit des statistiques de latence et de perte de paquets vers une destination.

Assurez-vous que le port 22 ou le port que vous testez est ouvert dans les deux sens. Pour résoudre les problèmes de connectivité réseau à l’aide de l’utilitaire de détermination d’itinéraire, exécutez la commande depuis le client vers le serveur. Vous devez ensuite exécuter la commande depuis le serveur vers le client. Le chemin entre les nœuds d’un réseau TCP/IP peut changer si la direction est inversée. Utilisez une trace basée sur TCP (le port de votre application) au lieu de l’ICMP, car la plupart des appareils Internet dépriorisent les demandes de trace basées sur ICMP.

Détermination d’itinéraire basée sur ICMP :

sudo traceroute -I PUBLIC_IP

détermination d’itinéraire basée sur TCP :

sudo traceroute -n -T -p 22 PUBLIC_IP

L’argument -T -p 22 -n effectue un suivi basé sur TCP sur le port 22.

Remarque : vous pouvez utiliser le port spécifique à votre application pour les tests. Utilisez le port spécifique pour savoir s’il existe des appareils intermédiaires sur le chemin qui suppriment le trafic de votre application.

Tester les performances à l’aide de hping3

Hping3 est un assembleur et analyseur de paquets TCP/IP exécutable en ligne de commande, qui mesure la perte de paquets et la latence de bout en bout sur une connexion TCP. Téléchargez hping3 sur le site Die.net.

Outre les demandes d’écho ICMP, hping3 prend en charge les protocoles TCP, UDP et RAW-IP. Hping3 inclut également un mode de détermination d’itinéraire qui permet d'envoyer des fichiers entre des canaux couverts. Hping3 peut analyser les hôtes, exécuter des tests de pénétration, tester les systèmes de détection d’intrusion et envoyer des fichiers entre les hôtes.

Les rapports MTR et de détermination d’itinéraire capturent la latence par saut. Cependant, en plus de la perte de paquets, les résultats de hping3 indiquent la latence minimale, moyenne et maximale de bout en bout sur TCP.

Pour installer hping3, exécutez les commandes suivantes :

Amazon Linux 2 :

Installez le package EPEL pour RHEL 7 et activez le référentiel EPEL.

sudo amazon-linux-extras install epel -y

Amazon Linux 2 :

sudo yum --enablerepo=epel install hping3

Ubuntu :

sudo apt-get install hping3

La commande suivante envoie 50 paquets TCP SYN via le port 0. Par défaut, hping3 envoie des en-têtes TCP au port 0 de l’hôte cible avec une taille de fenêtre de 64 et sans aucune balise TCP :

sudo hping3 -S -c 50 -V PUBLIC_IP

La commande suivante envoie 50 paquets TCP SYN via le port 22 :

sudo hping3 -S -c 50 -V PUBLIC_IP -p 22

Remarque : assurez-vous que le port 22 ou le port que vous testez est ouvert.

Tester des échantillons de capture de paquets à l’aide de tcpdump

Lorsque vous diagnostiquez les problèmes de perte de paquets ou de latence, il est recommandé d’effectuer des captures de paquets simultanées à la fois sur l’instance EC2 et sur l’hôte sur site. Ces captures peuvent permettre d’identifier les paquets de demande et de réponse afin d’isoler le problème au niveau des couches réseau et applicative. Il est également recommandé de démarrer d’abord la capture de paquets, puis de lancer le trafic. Cet ordre d’action permet de capturer tous les paquets du flux.

Pour installer tcpdump, exécutez les commandes suivantes :

Amazon Linux :

sudo yum install tcpdump

Ubuntu :

sudo apt-get install tcpdump

Après avoir installé tcpdump, exécutez la commande suivante pour capturer le trafic du port TCP 22, puis enregistrez la sortie dans un fichier pcap.

sudo tcpdump -i eth0 port 22 -s0 -w samplecapture.pcap

Remarque : l’indicateur tcpdump -i spécifie l’interface de l’instance sur laquelle tcpdump capture le trafic. Il se peut que vous deviez remplacer l’interface eth0 par l’interface configurée dans votre environnement.

Résolution des problèmes de performances pour Windows

Vérifier la fonctionnalité ECN

  1. Pour déterminer si la fonctionnalité de notification explicite de congestion (ECN) est activée, exécutez la commande suivante :

    netsh interface tcp show global
  2. Si la fonctionnalité ECN est activée, pour la désactiver, exécutez la commande suivante :

    - netsh interface tcp set global ecncapability=disabled
  3. Si vous ne constatez aucune amélioration des performances, exécutez la commande suivante pour réactiver la fonctionnalité ECN :

    netsh interface tcp set global ecncapability=enabled

Examiner les sauts pour résoudre les problèmes de connectivité des ports TCP
Tout d’abord, utilisez MTR ou tracert pour examiner les sauts.

Méthode MTR :

  1. Téléchargez puis installez WinMTR depuis le site Web Sourceforge.net.
  2. Saisissez l’adresse IP de destination dans la section Hôte, puis sélectionnez Démarrer.
  3. Laissez le test s’exécuter pendant une minute, puis sélectionnez Arrêter.
  4. Sélectionnez Copier le texte dans le presse-papiers, puis collez le la sortie dans un fichier texte.
  5. Examinez le fichier texte pour déterminer si des pertes dans la colonne % se sont propagées vers l’adresse de destination.
    Remarque : ignorez tous les sauts présentant le message Aucune réponse de l’hôte. Ce message indique que ces sauts ne répondent pas aux sondes ICMP.
  6. Examinez les sauts dans les rapports MTR en appliquant une approche ascendante. Par exemple, recherchez d’abord les pertes potentielles sur le dernier saut ou la dernière adresse de destination, puis examinez les sauts précédents.

Méthode Tracert :
Si vous ne souhaitez pas installer MTR, exécutez l'utilitaire de commande tracert.

  1. Vous pouvez exécuter un diagnostic tracert vers l’URL ou l’adresse IP de destination.

  2. Recherchez tout saut qui présente un pic brusque pendant le temps de propagation aller-retour (RTT). Un pic brusque du RTT peut indiquer qu’un nœud est soumis à une charge élevée. Cette charge peut entraîner une latence ou des pertes de paquets dans le trafic.
    Remarque : l'option -d ne convertit pas les adresses IP en noms d’hôte. Supprimez l’option -d si vous devez convertir les adresses IP en noms d’hôte.

    tracert -d PUBLIC_IP

  3. Vérifiez ensuite la connectivité du port TCP.

Remarque : comme WinMTR et tracert sont tous deux basés sur ICMP, vous pouvez exécuter tracetcp pour résoudre les problèmes de connectivité des ports TCP.

  1. Téléchargez le fichier ZIP tracetcp depuis le site Web NetworkHunt.com.
  2. Extrayez le fichier Tracetcp.
  3. Copiez le fichier tracetcp.exe sur votre lecteur C:.
  4. Téléchargez puis installez WinPcap depuis le site Web WinPcap.org.
  5. Ouvrez l’invite de commande et les fichiers WinPcap racine sur votre lecteur C: à l’aide de la commande C:\Users\username>cd.
  6. Pour exécuter tracetcp, exécutez les commandes suivantes :
    tracetcp.exehostname:port
    -ou-
    tracetcp.exe ip:port

Vérifier le gestionnaire de tâches de Windows

Si vous avez accès à l’instance source ou à l’instance de destination, consultez le Gestionnaire des tâches Windows. Recherchez les problèmes liés à l’utilisation du processeur et de la mémoire ou à la charge moyenne.

Effectuer une capture de paquets

Remarque : lorsque vous diagnostiquez des problèmes de perte de paquets ou de latence, il est recommandé d’effectuer des captures de paquets simultanées à la fois sur l’instance EC2 et sur l’hôte local. Cette action permet d’identifier les paquets de demande et de réponse afin d’isoler le problème au niveau des couches réseau et applicative. l est également recommandé de démarrer d’abord la capture de paquets, puis de lancer le trafic. Ces actions permettent de capturer tous les paquets du flux.

  1. Téléchargez et installez Wireshark depuis le site Web Wireshark.org. Effectuez ensuite une capture de paquets.
  2. Utilisez le filtre suivant pour isoler le trafic entre des sources particulières lors de la capture de paquets : (ip.addr eq source_IP) && (tcp.flags.syn == 1).
    La sortie affiche tous les flux TCP émanant de cette adresse IP source.
  3. Sélectionnez la ligne contenant l’adresse IP source et l’adresse IP de destination pertinentes.
  4. Sélectionnez le menu contextuel (clic droit), puis sélectionnez Suivre, puis Flux TCP. Cette action génère un flux TCP entre l’adresse IP source et l’adresse IP de destination que vous souhaitez examiner.
  5. Recherchez les retransmissions, les paquets dupliqués ou les notifications relatives à la taille de la fenêtre TCP, telles que Fenêtre TCP pleine ou Taille de fenêtre zéro. Ces notifications peuvent indiquer que l’espace des tampons TCP est épuisé.

Si vous constatez une perte de paquets ou si le nombre de sauts change de manière significative par rapport aux tests de référence, consultez la documentation du fournisseur de votre équipement réseau. Si vous travaillez dans un environnement réseau multi-hébergement, effectuez ces tests en utilisant un fournisseur de services Internet différent.

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 5 mois