Pourquoi mon application rencontre-t-elle des problèmes de latence et de performances lorsque j'utilise un VPN de site à site ?

Résolution

Si vous rencontrez des problèmes de performances ou de latence lorsque vous utilisez un VPN de site à site pour accéder à des ressources, procédez comme suit :

• Isolez les systèmes source et de destination un par un.
• Vérifiez le chemin du réseau pour détecter les problèmes susceptibles d'entraîner une latence.
• Vérifiez que votre application ne contient pas d'erreurs courantes à l'origine de problèmes de latence.

Isolez vos systèmes source et destination

Pour atténuer les problèmes de performances entre votre application sur site et AWS, commencez par isoler les systèmes source et de destination. Utilisez ensuite les outils réseau pour vérifier les pertes et les temps de latence en dehors de l'application susceptibles d'avoir un impact direct sur les performances.

1.    Modifiez la source et la destination. Utilisez une autre source puis une autre destination et vérifiez si le problème persiste après chaque modification. Vérifiez ensuite l'appareil pour déterminer s'il existe un problème de configuration du système d'exploitation (SE) ou un autre problème.

2.    Effectuez un test des capacités de bande passante UDP. Les problèmes de performances peuvent indiquer des problèmes de débit. Utilisez donc l'outil iperf3 pour vérifier votre bande passante provisionnée. Effectuez ce test de manière bidirectionnelle. L'exemple de test UDP suivant utilise l'outil iperf3.

**Remarque : ** -i fait référence à un intervalle, -u à UDP, -b à la bande passante (à ajuster en conséquence), -p fait référence au port UDP et -v à une description précise.

Server: sudo iperf -s -u [-p 5001]
client: sudo iperf3 -i 1 -u -p 33344 -b 1.2G -c <private IP> -V

Remarque : Assurez-vous que votre crédit de bande passante est disponible pour l'instance Amazon Elastic Compute Cloud (Amazon EC2) que vous utilisez. Ou essayez d'utiliser une taille d'instance plus grande, puis testez à nouveau.

3.    Utilisez iperf3 pour effectuer un test de débit TCP sur votre VPN de site à site. Effectuez ce test de manière bidirectionnelle. Consultez l’exemple suivant :

Remarque : Pour des performances optimales, essayez différentes tailles de fenêtre de réception TCP afin de tester les tampons de mémoire source et de destination lorsque vous augmentez la taille de l'instance.

Server : iperf3 -s [-p 5001]
Client:
sudo iperf3 -c <Private IP> -P 10 -w 128K -V
sudo iperf3 -c <Private IP> -P 10 -w 512K -V
sudo iperf3 -c <Private IP> -P 10 -w 1024K -V  

Vérifiez si le chemin du réseau ne présente pas de problèmes

Vérifiez le correctif réseau pour identifier le saut ou le périphérique spécifique à l'origine des problèmes sur le réseau :

• Vérifiez qu'il n'y a pas de perte de paquets le long du trajet entre les homologues VPN de site à site.
• Vérifiez le débit du tunnel VPN de site à site.
• Vérifiez la configuration du routeur de la passerelle client.
• Vérifiez le MTU le plus bas du chemin.

Vérifiez qu'il n'y a pas de perte de paquets le long du trajet entre des homologues VPN de site à site

Votre tunnel VPN de site à site est une communication cryptée entre pairs. Toutefois, le réseau sous-jacent peut présenter des pertes qui ont un impact sur la qualité de la communication cryptée. La perte de paquets augmente la latence et a un impact direct sur le débit.

Reportez-vous à l'équation et à l'exemple suivants :

Mathis Equation: Throughput = (MSS/RTT)*(1 / sqrt{p}):

Eg. 1375 MSS, 33ms latency, 0.001%= (1375B / 0.033 sec) * (1/𝑠𝑞𝑟𝑡{0.001})=  (41,666.6 * 31.6227)*8 <<< To go from Bps to bps= 10,540,925.5 bps (10.5 Mbps)

La mesure du débit est [Taille de la fenêtre TCP en bits] / [Latence (RTT) en secondes]. Consultez l’exemple suivant :

Eg.  64K in receive Window, 33ms latency= 524288 bits / 0.033 = 15,887,515 = 15.8 Mbps MAX Possible Throughput

Pour vérifier la perte de paquets sur le chemin public entre des homologues VPN de site à site, utilisez un test ICMP, tel que MTR. Pour plus de détails, voirComment 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 ?

Consultez l’exemple suivant :

Remarque : La sortie MTR de cet exemple inclut des valeurs sans données ou avec une perte de 100 %. Cela indique que le périphérique a abandonné le paquet avec un TTL de 0, mais qu'il n'a pas répondu avec un message ICMP dépassé (Type 11, Code 0). Ces valeurs n'indiquent donc pas de problème.

 [ec2-user@ip-10-7-10-67 ~]$ sudo mtr --no-dns --report --report-cycles 20 18.189.121.166Start: 2023-04-07T16:28:28+0000HOST: ip-10-7-10-67.ec2.internalr Loss%   Snt   Last   Avg  Best  Wrst StDev  1.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  3.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  4.|-- 241.0.12.14                0.0%    20    0.4   0.4   0.3   0.8   0.1  5.|-- 240.0.204.2                0.0%    20    0.4   0.4   0.3   0.5   0.0  6.|-- 240.0.204.17               0.0%    20    0.4   0.4   0.3   0.5   0.0  7.|-- 240.0.204.5                0.0%    20    0.4   0.4   0.4   0.5   0.0  8.|-- 242.2.74.145               0.0%    20    1.2   4.0   0.4  23.9   5.7  9.|-- 52.93.29.71                0.0%    20    0.8   2.3   0.7   9.2   2.8 10.|-- 100.100.8.66               0.0%    20   10.8   2.5   0.7  12.8   4.0 11.|-- 100.92.53.85               0.0%    20   26.0  13.3  11.0  26.0   4.4 12.|-- 52.93.239.5                0.0%    20   11.6  12.8  11.4  23.7   2.7 13.|-- 52.95.1.159                0.0%    20   11.0  12.0  11.0  18.3   1.7 14.|-- 52.95.1.186                0.0%    20   11.5  14.1  11.2  32.6   5.9 15.|-- 15.230.39.135              0.0%    20   11.6  11.9  11.1  15.5   1.1 16.|-- 15.230.39.124              0.0%    20   11.7  12.8  11.2  27.2   3.6 17.|-- 108.166.252.38             0.0%    20   11.2  11.2  11.1  11.3   0.0 18.|-- 242.0.102.17               0.0%    20   12.1  12.4  11.2  23.9   2.8 19.|-- 108.166.252.35             0.0%    20   11.3  11.3  11.2  12.3   0.2 20.|-- 241.0.12.207               0.0%    20   11.2  11.3  11.1  13.2   0.5 21.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 22.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 23.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 24.|-- 100.65.30.129              0.0%    20   57.2  24.9  11.6  76.4  17.9 25.|-- 18.189.121.166             0.0%    20   11.3  11.8  11.2  17.6   1.6[ec2-user@ip-10-7-10-67 ~]$

Vérifiez le débit du tunnel VPN de site à site

Vérifiez si votre débit dépasse la limite de 1,2 Gbit/s :

1.    Ouvrez la console Amazon CloudWatchpour afficher les métriques VPN de site à site.

2.    Choisissez les métriques pour TunnelDataIn et TunnelDataOut.

3.    Pour Statistiques, choisissez Somme, puis pour Période, choisissez 5 minutes.

4.    Appliquez le calcul suivant aux points de données à leur maximum. Dans cette équation, m1 = TunnelDataIn et m2 = TunnelDataOut.

Remarque : Si le débit est supérieur à 1,2 Gbit/s pendant une période prolongée, implémentez deux tunnels BGP avec ECMP et passerelle de transit.

(((m1+m2)/300)*8)/1000000

Vérifiez la configuration du routeur de votre passerelle client

Vérifiez les configurations suivantes sur votre appareil de passerelle client :

• Assurez-vous qu'aucune politique de contrôle ou d'élaboration ne limite le débit.
• Réinitialisez l'indicateur Ne pas fragmenter (DF) dans les paquets IP.
• Assurez-vous de fragmenter les paquets IPsec avant de les chiffrer.
• Vérifiez que la passerelle client possède une configuration MSS de telle sorte que les en-têtes IP, TCP, UDP ou ESP et la charge utile de données ne dépassent pas 1 500. Suivez les directives MTU relatives à l'algorithme de chiffrement que vous utilisez. Pour plus d'informations, consultez la section Meilleures pratiques pour votre appareil de passerelle client.

Vérifiez le MTU le plus bas du chemin

Testez le chemin pour vous assurer que le MTU le plus bas du chemin correspond à ce qui est attendu :

Pour ce faire, envoyez un ping -s 1460 <DESTINATION> -M fait :

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1460 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1460(1488) bytes of data.1468 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=1.06 ms1468 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=1.04 ms1468 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=4 ttl=51 time=1.07 ms1468 bytes from 1.1.1.1: icmp_seq=5 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=6 ttl=51 time=1.06 ms

Si un périphérique situé le long du chemin ne peut pas transporter la charge utile, il renvoie le message suivant : MTU du chemin ICMP a dépassé le délai de livraison :

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1480 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1480(1508) bytes of data.From 10.7.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500

Vérifiez que votre application ne contient pas d'erreurs courantes

Vérifiez si votre application locale présente les problèmes les plus courants :

• Problèmes de configuration de l'application.
• Utilisation de threads parallèles dans le transfert de données. Si vous observez un débit VPN de site à site qui semble plus lent que prévu, utilisez des threads parallèles pour confirmer le débit indépendamment de l'application.
• Implémentation de l'algorithme de nouvelle tentative avec retard exponentiel. Si vous constatez des délais d'expiration lorsque vous appelez les services AWS, utilisez l'algorithme de nouvelle tentative avec retard exponentiel.

Informations connexes

Réseau amélioré sous Linux

FAQ sur le VPN AWS