Comment puis-je résoudre les problèmes de perte de paquets sur ma connexion VPN ?
Je rencontre des pertes de paquets continues ou intermittentes et des problèmes de latence élevés sur ma connexion VPN.
Résolution
Vérifier l’utilisation des ressources
Une utilisation élevée du processeur, de la mémoire ou de la bande passante réseau contribue à la perte de paquets. Surveillez les métriques CPUUtilization, NetworkIn, NetworkOut, NetworkPacketsIn et NetworkPacketsOut Amazon CloudWatch. Vérifiez l'utilisation des ressources sur les hôtes source et de destination.
Vérifier les problèmes de réseau
Pour vérifier la perte ou la latence des paquets ICMP ou TCP, installez l'outil réseau mtr sur la machine sur site locale. Installez également mtr sur une instance Amazon Elastic Compute Cloud (Amazon EC2).
Pour Amazon Linux 2, exécutez la commande suivante :
sudo yum install mtr
Pour Ubuntu, exécutez la commande suivante :
sudo apt-get install mtr
Pour Windows, utilisez WinMTR de SourceForge.
Remarque : WinMTR ne prend pas en charge MTR basé sur TCP.
Vérifiez l’existence éventuelle d’une perte de paquets dans le tunnel VPN AWS. Testez la connexion entre l'hôte sur site qui utilise le tunnel et l'adresse IP privée de votre instance Amazon EC2. Testez également la connexion entre votre passerelle client sur site et l'adresse IP publique de chaque tunnel. Si vous ne pouvez pas utiliser mtr sur votre périphérique de passerelle client, utilisez un hôte doté de la même connexion Internet que le périphérique de passerelle client.
Important : Obtenez les résultats de mtr dans les deux directions. Le chemin entre les nœuds d'un réseau d'adresses TCP et IP peut changer lorsque vous inversez la direction.
Exécutez le test suivant sur une adresse IP privée avec ICMP :
mtr -b -c 50 -rw Host_Instance_Private_IP
Exécutez le test suivant sur une adresse IP privée avec TCP :
mtr -b -c 50 -rw -T -P 443 Host_Instance_Private_IP
Remarque : Dans les commandes précédentes, remplacez Host_instance_private_IP par l’adresse IP privée de votre instance EC2 ou de votre hôte sur site, et 443 par votre port.
Exécutez le test suivant sur une adresse IP publique avec ICMP :
mtr -b -c 50 -rw AWS_Tunnel_Public_IP
Exécutez les tests suivants sur une adresse IP publique avec UDP :
mtr -b -c 50 -rw -u -P 500 AWS_Tunnel_Public_IP
mtr -b -c 50 -rw -u -P 4500 AWS_Tunnel_Public_IP
Remarque : Dans les commandes précédentes, remplacez AWS_Tunnel_Public_IP par l'adresse IP publique du tunnel, et 500 et 4500 par vos ports UDP.
Une perte de paquets et une augmentation de la durée de l’aller-retour (RTT) sur un seul saut sont attendues. La perte de paquets et l'augmentation de la RTT ne sont des problèmes que si vous les visualisez à chaque saut. L'exemple de sortie suivant montre une perte constante qui commence au saut 3 et se poursuit jusqu'au dernier saut :
HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9 6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2
L'exemple suivant illustre un test de l'adresse IP publique d'un tunnel qui utilise le port UDP 500. Entre les sauts 1 et 4, la colonne % de perte indique un pourcentage de perte. Cependant, étant donné qu’il n’existe aucune perte de paquets entre les sauts 5 et 13, cette perte n'est pas considérée comme une perte de paquets significative. La perte entre le saut 14 et le saut final indique une perte de paquets importante car il s'agit d'une perte durable qui se termine par une perte de 100 %. Dans cet exemple, le problème se produit au saut 14.
sudo mtr -b -c 30 -rw -u -P 500 185.156.137.215 Start: 2024-08-28T18:59:49+0000 HOST: ip-10-100-20-25 Loss% Snt Last Avg Best Wrst StDev 1. |-- ??? 100.0 30 0.0 0.0 0.0 0.0 0.0 2. |-- 240.1.84.6 73.3% 30 0.5 0.5 0.5 0.5 0.0 3. |-- 242.3.160.33 63.3% 30 1.4 1.0 0.6 1.4 0.3 4. |-- 241.0.6.67 63.3% 30 0.5 6.7 0.5 12.4 5.9 5. |-- 100.100.6.39 0.0% 30 0.5 3.1 0.5 27.7 6.2 6. |-- 100.100.72.6 0.0% 30 1.1 9.9 0.5 96.0 17.6 7. |-- 100.91.209.81 0.0% 30 11.5 20.6 11.1 127.3 24.3 8. |-- 100.100.6.107 0.0% 30 12.8 19.9 11.6 127.8 22.6 9. |-- 99.83.70.223 0.0% 30 12.3 18.1 11.7 117.0 19.2 10.|-- 100.100.92.209 0.0% 30 11.9 13.7 11.6 50.6 7.0 11.|-- 100.100.16.88 0.0% 30 13.2 14.0 11.9 33.1 3.8 12.|-- gw-as249.retn.net (87.245.240.41) 0.0% 30 13.2 13.2 11.8 19.9 1.5 13.|-- thw.sw01.loudltd.net (185.156.136.14) 0.0% 30 11.4 12.5 11.4 14.2 1.0 14.|-- no-ptr.pckear.com (185.116.108.124) 20.0% 30 14.8 13.2 12.5 14.8 0.5 15.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 14.1 13.6 12.5 15.5 0.8 16.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 16.5 14.5 13.3 16.5 0.8 17.|-- ??? 100.0% 30 0.0 0.0 0.0 0.0 0.0
Vérifier les problèmes de latence et de routage
L'outil traceroute indique le chemin emprunté par les données sur le réseau. Utilisez ces informations pour identifier les retards.
Pour installer traceroute sur Amazon Linux, exécutez la commande suivante :
sudo yum install traceroute
Pour installer traceroute sur Ubuntu, exécutez la commande suivante :
sudo apt-get install traceroute
Pour Windows, à la place de traceroute, utilisez l'outil tracert. Cet outil est installé par défaut sur toutes les machines Windows. Notez que tracert n'autorise pas le suivi TCP. Pour bénéficier de toutes les fonctionnalités, vous pouvez installer l'outil tracetcp.
Exécutez les tests suivants entre l'adresse IP privée et publique de votre instance Amazon EC2 et celle de votre hôte sur site.
Important : Obtenez des résultats dans les deux directions. Le chemin entre les nœuds d'un réseau d'adresses TCP et IP peut changer lorsque vous inversez la direction.
Pour Linux, exécutez la commande suivante :
sudo traceroute -T -p 80 Host_IP
Remarque : Remplacez Host_IP par l'adresse IP privée de votre instance EC2 ou de votre hôte sur site et 80 par votre port. Pour une meilleure précision, l'exemple précédent utilise une trace basée sur TCP (T) pour tester le chemin du trafic à l'intérieur du tunnel. Pour tester le chemin du trafic sur Internet, remplacez Host_IP par l'adresse IP publique du tunnel.
Vous recevez un résultat qui ressemble à l’exemple suivant :
traceroute -T -p 443 aws.com traceroute to aws.com (3.161.213.43), 30 hops max, 60 byte packets 1 SEA-1801842641.mshome.net (172.28.96.1) 0.363 ms 0.346 ms 0.362 ms 2 192.168.50.1 (192.168.50.1) 5.514 ms 5.508 ms 5.501 ms 3 172.27.232.1 (172.27.232.1) 45.179 ms 52.879 ms 52.871 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 server.yul62.r.ct.net (3.161.213.43) 57.452 ms 57.741 ms 62.604 ms
Cet exemple de sortie montre des sauts intermédiaires sans réponse. Bien que les appareils n'aient pas répondu sur le port 443 demandé, il n'y a aucun problème car la destination répond toujours comme prévu.
Pour Windows, exécutez tracert. Ou, si vous avez installé tracetcp, exécutez la commande PowerShell suivante :
tracetcp.exe Host_IP:80
Remarque : Remplacez Host_IP par l'adresse IP privée de votre instance EC2 ou de votre hôte sur site et 80 par votre port. Pour une meilleure précision, l'exemple précédent utilise une trace basée sur TCP (T) pour tester le chemin du trafic à l'intérieur du tunnel. Pour tester le chemin du trafic sur Internet, remplacez Host_IP par l'adresse IP publique du tunnel.
Vous recevez un résultat qui ressemble à l’exemple suivant :
PS C:\Users\UserA> tracetcp.exe aws.com:443 Tracing route to 18.239.168.29 [server-18-239-168-29.bos50.r.cloudfront.net] on port 443 Over a maximum of 30 hops. 1 5 ms 7 ms 6 ms 192.168.50.1 2 41 ms 42 ms 44 ms 172.27.232.1 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 51 ms 43 ms 45 ms 241.0.11.143 7 62 ms 54 ms 43 ms 241.0.11.135 8 53 ms 53 ms 55 ms 240.4.8.24 9 52 ms 56 ms 53 ms 240.4.8.17 10 56 ms 59 ms 62 ms 240.64.239.162 11 57 ms 56 ms 61 ms 240.64.239.162 12 57 ms 55 ms 57 ms 240.64.239.162 13 58 ms Destination Reached in 54 ms. Connection established to 18.239.168.29 Trace Complete.
Tester les performances TCP de bout en bout
Utilisez hping3 pour tester la perte de paquets TCP de bout en bout et la latence. Cet outil vous permet d'évaluer les performances TCP directement entre les hôtes.
Pour installer hping3 sur Amazon Linux, exécutez la commande suivante :
sudo yum --enablerepo=epel install hping3
Pour installer hping3 sur Ubuntu, exécutez la commande suivante :
sudo apt-get install hping3
Pour exécuter hping3, exécutez la commande suivante :
hping3 -S -c 50 -V Host_IP
Remarque : Remplacez Host_IP par l'adresse IP privée de votre instance EC2 ou de votre hôte sur site, ou par l'adresse IP publique du tunnel.
L'exemple de sortie suivant montre un test par rapport à l'adresse IP publique d'un point de terminaison de VPN qui utilise le port TCP 8443 :
sudo hping3 -S -c 3 -p 8443 -V 34.233.155.9 using eth0, addr: 172.28.100.111, MTU: 1500 HPING 34.233.155.9 (eth0 34.233.155.9): S set, 40 headers + 0 data bytes len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=0 win=26883 rtt=49.6 ms seq=2996814187 ack=1585541078 sum=22f7 urp=0 len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=1 win=26883 rtt=49.6 ms seq=3555645549 ack=1207738370 sum=29a5 urp=0 len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=2 win=26883 rtt=49.2 ms seq=4045561197 ack=742863285 sum=f78c urp=0
Identifier les problèmes liés au réseau ou à l'application
Obtenez des captures de paquets simultanées sur l'instance EC2 et sur l'hôte sur site lorsque le problème survient. Utilisez la capture de paquets pour identifier les problèmes liés au réseau ou à l'application.
Pour obtenir une capture de paquets pour les instances Linux, utilisez tcpdump.
Pour installer tcpdump sur Amazon Linux, exécutez la commande suivante :
sudo yum install tcpdump
Pour installer tcpdump sur Ubuntu, exécutez la commande suivante :
sudo apt-get install tcpdump
Pour Windows, utilisez Wireshark au lieu de tcpdump. Pour télécharger l'outil, consultez la page Télécharger Wireshark sur le site Web de Wireshark.
La capture de paquets est similaire à l'exemple suivant :
tcpdump -i any -nnvv port 500 and port 4500 tcpdump: listening on any, link-type EN10MB (Ethernet), capture size 65535 bytes 18:12:54.944933 IP (tos 0x0, ttl 63, id 43082, offset 0, flags [DF], proto UDP (17), length 212) 10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=7080)(type=enc value=aes)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024)))) (vid: len=16) (vid: len=16) (vid: len=16) (vid: len=16) (vid: len=16) out slot1/tmm0 lis=$_ike_1061b_out_23.20.145.20 port=1.0 trunk= 18:12:54.946069 IP (tos 0x0, ttl 253, id 56278, offset 0, flags [none], proto UDP (17), length 152) 23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifedura tion value=7080)))) (vid: len=16) (vid: len=16) in slot1/tmm0 lis= port=1.0 trunk= 18:12:54.949988 IP (tos 0x0, ttl 63, id 43084, offset 0, flags [DF], proto UDP (17), length 256) 10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 I ident: (ke: key len=128) (nonce: n len=16 data=(e84ae917994501b5b4f4...1a547b3cf720e35995f5b0c69198c9f796b5d9f9)) (pay20) (pay20) out slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk= 18:12:54.951858 IP (tos 0x0, ttl 253, id 56279, offset 0, flags [none], proto UDP (17), length 272) 23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident: (ke: key len=128) (nonce: n len=32 data=(c5170686e88069e33323...4448aaf06cc37d4b32d67df97e275e5756a534d8)) (pay20) (pay20) in slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk=
(Windows uniquement) Désactiver ECN
Si la notification de congestion explicite (ECN) est activée pour vos instances Windows, il est possible que vous rencontriez des problèmes de perte de paquets ou de performances.
Pour vérifier si ECN est activé, exécutez la commande PowerShell suivante :
netsh interface tcp show global
Pour désactiver ECN, exécutez la commande PowerShell suivante :
netsh interface tcp set global ecncapability=disabled
Informations connexes
Contenus pertinents
- demandé il y a 8 mois
- demandé il y a 8 mois
- demandé il y a un an
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
