Optimisation des performances de WireGuard
|
Important
|
Traduction d’un article du site Pro Custodibus Le contenu de cette page est la traduction Française de l’article WireGuard Performance Tuning de Justin Ludwig |
WireGuard Performance Tuning
WireGuard n’a généralement pas besoin d’ajustements de performance pour être utilisé. Il a été conçu pour fonctionner bien sur les piles réseau modernes sous diverses configurations. Envoyer du trafic à travers son tunnel crypté nécessite seulement une petite quantité d’overhead, sous forme d’utilisation légèrement plus élevée du CPU et du réseau.
Cependant, il existe quelques ajustements que vous pouvez effectuer si vous rencontrez des problèmes de performance avec WireGuard. Cet article vous guidera à travers certaines stratégies pour Tester et Ajuster les performances de votre réseau WireGuard.
Tester
Comment savoir si vous avez un problème de performance avec WireGuard ? Il existe en effet deux classes principales de problèmes :
- Performance faible avec une Connexion Unique
- Performance faible lorsque de Plusieurs Connexions sont actives
Connexion Unique
Pour vérifier la performance avec une seule connexion WireGuard, essayez d’exécuter une opération à haut débit entre deux points de terminaison qui reflètent le problème de performance que vous semblez avoir, comme l’upload ou le download d’un fichier volumineux vers ou depuis une application web, ou la participation à un appel vidéo. Exécutez-le plusieurs fois avec la connexion WireGuard active et plusieurs fois en utilisant les mêmes points de terminaison exacts avec la connexion WireGuard inactive, puis comparez vos résultats.
Vous devriez attendre d’voir environ 90% de la performance avec vos tests lorsque vous utilisez WireGuard par rapport au cas où vous ne l’utilisez pas. Vous pourriez avoir besoin de modifier temporairement certains de vos paramètres de pare-feu ou autres paramètres réseau pour permettre aux deux points de terminaison de se connecter à l’extérieur du tunnel WireGuard.
Si il n’est pas possible de connecter les deux points de terminaison en dehors de WireGuard pour le test, et que vous avez un ou plusieurs sauts WireGuard entre les deux points de terminaison — par exemple, si vous avez un hub WireGuard entre les deux points de terminaison, ou une connexion site à site WireGuard entre les deux points de terminaison — vous pourriez essayer de tester chaque saut individuellement sans WireGuard ; puis comparer le rendement du pire saut sans WireGuard par rapport à la connexion complète point à point avec WireGuard. Tant que vous avez seulement deux ou trois sauts WireGuard, vous devriez attendre d’au moins 50% du rendement de votre test de connexion point à point WireGuard en comparaison de l’envoi du même trafic sans WireGuard sur le pire saut.
Si le rendement d’une application spécifique via WireGuard est important pour vous, vous devriez tester avec elle ; mais si vous n’avez pas une application spécifique à l’esprit (ou si c’est impossible de la tester des mêmes points de terminaison lorsqu’on utilise WireGuard que lorsqu’on ne l’utilise pas), iPerf est un outil pratique pour tester le bande passant général disponible pour une connexion entre deux points de terminaison. Il est disponible via le package iperf3 dans la plupart des distributions Linux.
Par exemple, pour tester le débit TCP générique d’upload d’une connexion WireGuard entre deux points de terminaison, vous pouvez exécuter iperf3 --server sur le côté “serveur” de la connexion et iperf3 --client 10.0.0.2 sur le côté “client” de la connexion (où 10.0.0.2 est l’adresse IP de l’interface WireGuard du côté serveur). Ensuite, exécutez iperf3 --client 10.0.0.2 --reverse pour tester le débit TCP générique d’download de la connexion.
La sortie d’iPerf sur le côté client ressemblera à ceci :
$ iperf3 --c
```plaintext
Client 10.0.0.2
Connecting to host 10.0.0.2, port 5201
[ 5] local 10.0.0.1 port 51340 connected to 10.0.0.2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 64.0 MBytes 537 Mbits/sec 1 854 KBytes
[ 5] 1.00-2.00 sec 78.5 MBytes 659 Mbits/sec 0 854 KBytes
[ 5] 2.00-3.00 sec 76.7 MBytes 643 Mbits/sec 0 854 KBytes
[ 5] 3.00-4.00 sec 76.6 MBytes 642 Mbits/sec 0 854 KBytes
[ 5] 4.00-5.00 sec 77.8 MBytes 653 Mbits/sec 0 854 KBytes
[ 5] 5.00-6.00 sec 68.4 MBytes 574 Mbits/sec 7 730 KBytes
[ 5] 6.00-7.00 sec 77.9 MBytes 653 Mbits/sec 0 846 KBytes
[ 5] 7.00-8.00 sec 76.3 MBytes 640 Mbits/sec 0 846 KBytes
[ 5] 8.00-9.00 sec 77.9 MBytes 654 Mbits/sec 0 846 KBytes
[ 5] 9.00-10.00 sec 77.7 MBytes 652 Mbits/sec 0 846 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 752 MBytes 631 Mbits/sec 8 sender
[ 5] 0.00-10.05 sec 750 MBytes 626 Mbits/sec receiver
iperf Done.
$ iperf3 --server
Listening on 5201
Connecting to host 10.0.0.1, port 46262
[ 5] local 10.0.0.2 port 5201 connected to 10.0.0.1 port 46262
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 15.9 MBytes 133 Mbits/sec
[ 5] 1.00-2.00 sec 10.3 MBytes 86.6 Mbits/sec
[ 5] 2.00-3.00 sec 7.55 MBytes 63.3 Mbits/sec
[ 5] 3.00-4.00 sec 8.38 MBytes 70.2 Mbits/sec
[ 5] 4.00-5.00 sec 14.6 MBytes 122 Mbits/sec
[ 5] 5.00-6.00 sec 14.2 MBytes 119 Mbits/sec
[ 5] 6.00-7.00 sec 18.3 MBytes 154 Mbits/sec
[ 5] 7.00-8.00 sec 11.5 MBytes 96.5 Mbits/sec
[ 5] 8.00-9.00 sec 12.9 MBytes 108 Mbits/sec
[ 5] 9.00-10.00 sec 8.60 MBytes 72.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 124 MBytes 104 Mbits/sec 64 sender
[ 5] 0.00-10.00 sec 122 MBytes 103 Mbits/sec receiver
iperf Done.
$ iperf3 --server
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Connection from 10.0.0.1, port 51334
[ 5] local 10.0.0.2 port 5201 connected to 10.0.0.1 port 51340
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 59.0 MBytes 495 Mbits/sec
[ 5] 1.00-2.00 sec 77.8 MBytes 652 Mbits/sec
[ 5] 2.00-3.00 sec 77.2 MBytes 648 Mbits/sec
[ 5] 3.00-4.00 sec 76.7 MBytes 643 Mbits/sec
[ 5] 4.00-5.00 sec 77.7 MBytes 651 Mbits/sec
[ 5] 5.00-6.00 sec 68.8 MBytes 578 Mbits/sec
[ 5] 6.00-7.00 sec 76.7 MBytes 643 Mbits/sec
[ 5] 7.00-8.00 sec 76.9 MBytes 645 Mbits/sec
[ 5] 8.00-9.00 sec 77.4 MBytes 649 Mbits/sec
[ 5] 9.00-10.00 sec 78.0 MBytes 655 Mbits/sec
[ 5] 10.00-10.05 sec 4.02 MBytes 661 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.05 sec 750 MBytes 626 Mbits/sec receiver
iperf Done.
$ iperf3 --server
Listening on 5201
Connecting to host 10.0.0.1, port 46262
[ 5] local 10.0.0.2 port 5201 connected to 10.0.0.1 port 46262
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 16.5 MBytes 138 Mbits/sec 6 194 KBytes
[ 5] 1.00-2.00 sec 10.9 MBytes 91.1 Mbits/sec 8 93.1 KBytes
[ 5] 2.00-3.00 sec 7.22 MBytes 60.5 Mbits/sec 7 101 KBytes
[ 5] 3.00-4.00 sec 8.25 MBytes 69.2 Mbits/sec 7 124 KBytes
[ 5] 4.00-5.00 sec 14.8 MBytes 124 Mbits/sec 5 132 KBytes
[ 5] 5.00-6.00 sec 15.0 MBytes 127 Mbits/sec 4 140 KBytes
sec 14.3 MBytes 120 Mbits/sec 5 186 KBytes [ 5] 6.00-7.00 sec 18.1 MBytes 152 Mbits/sec 4 186 KBytes [ 5] 7.00-8.00 sec 12.0 MBytes 101 Mbits/sec 7 116 KBytes [ 5] 8.00-9.00 sec 12.4 MBytes 104 Mbits/sec 5 210 KBytes [ 5] 9.00-10.00 sec 8.85 MBytes 74.3 Mbits/sec 10 85.4 KBytes [ 5] 10.00-10.02 sec 559 KBytes 215 Mbits/sec 0 93.1 KBytes
[ ID] Intervalle Transfert Taux de bits Rét. [ 5] 0.00-10.02 sec 124 MBytes 104 Mbits/sec 64 expéditeur
Serveur en écoute sur 5201
À partir de ces deux exécutions, il semble que notre débit d'upload TCP générique via le tunnel WireGuard soit d'environ 600 Mbits/sec et le débit de download environ 100 Mbits/sec.
La sortie de chaque côté devrait ressembler à peu près la même chose, mais notez que nous ne voyons que le calcul de la taille de la fenêtre de congestion (la colonne étiquetée « Cwnd » dans la sortie) sur le côté « envoi » de la connexion — sur le côté client lors des tests d'upload (premier test), et sur le côté serveur lors des tests de download (second test).
La fenêtre de congestion est un facteur clé déterminant à quelle vitesse le côté envoi de la connexion peut envoyer des données au destinataire. Une fenêtre plus grande permet au l'envoyeur d'envoyer plus de données au destinataire avant que l'envoyeur n'aie besoin d'une reconnaissance du destinataire indiquant qu'il a reçu tous les paquets envoyés. L'envoyeur s'arrêtera lorsque la fenêtre atteindra son extrémité sans recevoir une reconnaissance ; et il essayera de renvoyer un sous-ensemble des paquets qu'il vient de envoyer (c'est-à-dire renvoyer avec une fenêtre de congestion plus petite) si il doit s'arrêter pendant trop longtemps.
Idealement, la pile réseau de l'hôte sur le côté envoi devrait être capable de déterminer rapidement la taille optimale de la fenêtre de congestion et de rester à cette taille pour la durée du test. C'est ce qui s'est passé avec notre premier test ci-dessus (upload), mais pas avec le second (download). Avec le deuxième test, la fenêtre de congestion a commencé à 194K, puis est immédiatement tombée à 93K, avant d'augmenter progressivement jusqu'à 210K, avant de terminer le test à nouveau à 93K.
Pour obtenir un résultat plus répétable, il serait mieux de jeter les parties du test où la pile réseau cherche la meilleure fenêtre de congestion ; et si la fenêtre de congestion continue de fluctuer, d'effectuer une échantillonnage de données plus long que celui par défaut d'iPerf de 10 secondes.
Essayons à nouveau de lancer le test de download, mais cette fois en jetant les 10 premières secondes et en prenant un échantillon de 20 secondes. Nous exécuterions la commande suivante sur le côté client :
```bash
$ iperf3 --client 10.0.0.2 --reverse --omit 10 --time 20
Connecting to host 10.0.0.2, port 5201
Reverse mode, remote host 10.0.0.2 is sending
[ 5] local 10.0.0.1 port 52710 connected to 10.0.0.2 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 1.00-2.00 sec 9.58 MBytes 80.4 Mbits/sec (omitted)
[ 5] 2.00-3.00 sec 11.1 MBytes 93.1 Mbits/sec (omitted)
[ 5] 3.00-4.00 sec 12.5 MBytes 105 Mbits/sec (omitted)
[ 5] 4.00-5.00 sec 13.5 MBytes 114 Mbits/sec (omitted)
[ 5] 5.00-6.00 sec 11.8 MBytes 98.9 Mbits/sec (omitted)
[ 5] 6.00-7.00 sec 8.60 MBytes 72.1 Mbits/sec (omitted)
[ 5] 7.00-8.00 sec 10.5 MBytes 88.5 Mbits/sec (omitted)
[ 5] 8.00-9.00 sec 11.4 MBytes 95.7 Mbits/sec (omitted)
[ 5] 9.00-10.00 sec 8.79 MBytes 73.8 Mbits/sec
```bash
iperf Done.
Et consultez la sortie suivante côté serveur :
-----------------------------------------------------------
Serveur écoute sur le port 5201
-----------------------------------------------------------
Connexion acceptée de 10.0.0.1, port 52702
[ 5] local 10.0.0.2 port 5201 connecté à 10.0.0.1 port 52710
[ ID] Intervalle Transfert Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 18.9 MBytes 159 Mbits/sec 13 163 KBytes (omitted)
[ 5] 1.00-2.00 sec 10.0 MBytes 83.9 Mbits/sec 8 85.4 KBytes (omitted)
[ 5] 2.00-3.00 sec 11.0 MBytes 92.1 Mbits/sec 5 140 KBytes (omitted)
[ 5] 3.00-4.00 sec 12.1 MBytes 102 Mbits/sec 5 140 KBytes (omitted)
[ 5] 4.00-5.00 sec 13.2 MBytes 110 Mbits/sec 5 147 KBytes (omitted)
[ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec 5 163 KBytes (omitted)
[ 5] 6.00-7.00 sec 8.79 MBytes 73.8 Mbits/sec 8 109 KBytes (omitted)
[ 5] 7.00-8.00 sec 9.94 MBytes 83.4 Mbits/sec 6 116 KBytes (omitted)
[ 5] 8.00-9.00 sec 12.1 MBytes 101 Mbits/sec 6 186 KBytes (omitted)
[ 5] 9.00-10.00 sec 8.79 MBytes 73.8 Mbits/sec 10 62.1 KBytes (omitted)
[ 5] 0.00-1.00 sec 6.73 MBytes 56.5 Mbits/sec 7 101 KBytes
[ 5] 1.00-2.00 sec 7.70 MBytes 64.6 Mbits/sec 10 101 KBytes
[ 5] 2.00-3.00 sec 12.1 MBytes 102 Mbits/sec 6 69.9 KBytes
[ 5] 3.00-4.00 sec 12.2 MBytes 102 Mbits/sec 9 46.6 KBytes
[ 5] 4.00-5.00 sec 7.70 MBytes 64.6 Mbits/sec 4 171 KBytes
[ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec 8 62.1 KBytes
[ 5] 6.00-7.00 sec 7.64 MBytes 64.1 Mbits/sec 9 69.9 KBytes
[ 5] 7.00-8.00 sec 9.82 MBytes 82.4 Mbits/sec 9 69.9 KBytes
[ 5] 8.00-9.00 sec 6.61 MBytes 55.4 Mbits/sec 5 179 KBytes
[ 5] 9.00-10.00 sec 12.0 MBytes 101 Mbits/sec 5 186 KBytes
[ 5] 10.00-11.00 sec 9.94 MBytes 83.4 Mbits/sec 8 93.1 KBytes
[ 5] 11.00-12.00 sec 8.85 MBytes 74.3 Mbits/sec 8 116 KBytes
[ 5] 12.00-13.00 sec 15.3 MBytes 129 Mbits/sec 4 147 KBytes
[ 5] 13.00-14.00 sec 14.3 MBytes 120 Mbits/sec 6 116 KBytes
[ 5] 14.00-15.00 sec 7.64 MBytes 64.1 Mbits/sec 7 140 KBytes
[ 5] 15.00-16.00 sec 14.3 MBytes 120 Mbits/sec 9 62.1 KBytes
[ 5] 16.00-17.00 sec 7.82 MBytes 65.6 Mbits/sec 7 85.4 KBytes
[ 5] 17.00-18.00 sec 13.3 MBytes 112 Mbits/sec 4 132 KBytes
[ 5] 18.00-19.00 sec 17.6 MBytes 148 Mbits/sec 6 132 KBytes
Il semble que notre connexion de téléchargement soit simplement fondamentalement assez instable, car la fenêtre de congestion continuait à osciller entre un minimum de 46K et un maximum de 186K tout au long du test. Prendre plus d’échantillons nous a permis d’arriver à ce qui est probablement un peu plus de débit fiable, environ 90Mbits/sec.
Mais est-ce bon ou mauvais ?
Pour savoir, nous devons tester la connexion en dehors du tunnel WireGuard. Pour cela, nous exécuterions le même test avec l’adresse IP publique du point de terminaison côté serveur, au lieu de son adresse IP WireGuard. Pour accéder au serveur iPerf depuis le client, nous pourrions avoir besoin d’ajuster nos règles de pare-feu (par exemple, pour permettre l’accès au port TCP 5201 sur l’interface publique du serveur à partir de l’adresse IP publique du client).
Dans cet exemple, supposons que le côté serveur de la connexion ait une adresse IP publique de 203.0.113.2. C’est ce que nous voyons lors de l’exécution des tests depuis le côté client :
$ iperf3 --client 203.0.113.2
Connecting to host 203.0.113.2, port 5201
[ 5] local 192.168.1.11 port 59094 connected to 203.0.113.2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 84.1 MBytes 706 Mbits/sec 0 1.60 MBytes
[ 5] 1.00-2.00 sec 98.8 MBytes 828 Mbits/sec 50 1.17 MBytes
[ 5] 2.00-3.00 sec 102 MBytes 860 Mbits/sec 0 1.30 MBytes
[ 5] 3.00-4.00 sec 102 MBytes 860 Mbits/sec 0 1.39 MBytes
[ 5] 4.00-5.00 sec 102 MBytes 860 Mbits/sec 0 1.47 MBytes
[ 5] 5.00-6.00 sec 104 MBytes 870 Mbits/sec 0 1.52 MBytes
[ 5] 6.00-7.00 sec 104 MBytes 870 Mbits/sec 0 1.56 MBytes
[ 5] 7.00-8.00 sec 104 MBytes 870 Mbits/sec 0 1.58 MBytes
[ 5] 8.00-9.00 sec 104 MBytes 870 Mbits/sec 0 1.60 MBytes
[ 5] 9.00-10.00 sec 105 MBytes 881 Mbits/sec 0 1.60 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1010 MBytes 848 Mbits/sec 50 sender
[ 5] 0.00-10.04 sec 1008 MBytes 843 Mbits/sec receiver
iperf Done.
$ iperf3 --client 203.0.113.2 --reverse --omit 10 --time 20
Connecting to host 203.0.113.2, port 5201
Reverse mode, remote host 203.0.113.2 is sending
[ 5] local 192.168.1.11 port 33482 connected to 203.0.113.2 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 8.84 MBytes 74.1 Mbits/sec (omitted)
[ 5] 1.00-2.00 sec 3.70 MBytes 31.0 Mbits/sec (omitted)
[ 5] 2.00-3.00 sec 5.58 MBytes 46.8 Mbits/sec (omitted)
[ 5] 3.00-4.00 sec 3.89 MBytes 32.6 Mbits/sec (omitted)
[ 5] 4.00-5.00 sec 4.19 MBytes 35.2 Mbits/sec (omitted)
[ 5] 5.00-6.00 sec 3.74 MBytes 31.4 Mbits/sec (omitted)
[ 5] 6.00-7.00 sec 3.70 MBytes 31.1 Mbits/sec (omitted)
[ 5] 7.00-8.00 sec 2.51 MBytes 21.0 Mbits/sec (omitted)
[ 5] 8.00-9.00 sec 4.02 MBytes 33.7 Mbits/sec (omitted)
[ 5] 9.00-10.00 sec 3.63 MBytes 30.4 Mbits/sec (omitted)
[ 5] 0.00-1.00 sec 3.84 MBytes 32.2 Mbits/sec
[ 5] 1.00-2.00 sec 6.70 MBytes 56.2 Mbits/sec
[ 5] 2.00-3.00 sec 4.86 MBytes 40.8 Mbits/sec
[ 5] 3.00-4.00 sec 5.28 MBytes 44.3 Mbits/sec
[ 5] 4.00-5.00 sec 5.49 MBytes 46.0 Mbits/sec
```ipérf Terminé.
Et ceci du serveur :
```bash
-----------------------------------------------------------
Serveur écoute sur le port 5201
-----------------------------------------------------------
Connexion acceptée de 198.100.51.11, port 48277
[ 5] local 192.168.200.22 port 5201 connecté à 198.100.51.11 port 10908
[ ID] Intervalle Transfert Taux de données
[ 5] 0.00-1.00 sec 78.2 MBytes 656 Mbits/sec
[ 5] 1.00-2.00 sec 98.8 MBytes 829 Mbits/sec
[ 5] 2.00-3.00 sec 103 MBytes 862 Mbits/sec
[ 5] 3.00-4.00 sec 102 MBytes 852 Mbits/sec
[ 5] 4.00-5.00 sec 103 MBytes 868 Mbits/sec
[ 5] 5.00-6.00 sec 104 MBytes 871 Mbits/sec
[ 5] 6.00-7.00 sec 103 MBytes 867 Mbits/sec
[ 5] 7.00-8.00 sec 104 MBytes 871 Mbits/sec
[ 5] 8.00-9.00 sec 104 MBytes 873 Mbits/sec
[ 5] 9.00-10.00 sec 104 MBytes 876 Mbits/sec
[ 5] 10.00-10.04 sec 4.17 MBytes 868 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervalle Transfert Taux de données Rét.
[ 5] 0.00-1.00 sec 9.78 MBytes 82.0 Mbits/sec 17 48.1 KBytes (omis)
[ 5] 1.00-2.00 sec 3.98 MBytes 33.4 Mbits/sec 15 38.2 KBytes (omis)
[ 5] 2.00-3.00 sec 5.72 MBytes 48.0 Mbits/sec 3 52.3 KBytes (omis)
[ 5] 3.00-4.00 sec 3.98 MBytes 33.4 Mbits/sec 11 29.7 KBytes (omis)
[ 5] 4.00-5.00 sec 3.91 MBytes 32.8 Mbits/sec 5 50.9 KBytes (omis)
[ 5] 5.00-6.00 sec 3.91 MBytes 32.8 Mbits/sec 10 63.6 KBytes (omis)
[ 5] 6.00-7.00 sec 3.91 MBytes 32.8 Mbits/sec 8 24.0 KBytes (omis)
[ 5] 7.00-8.00 sec 2.24 MBytes 18.8 Mbits/sec 10 33.9 KBytes (omis)
[ 5] 8.00-9.00 sec 3.91 MBytes 32.8 Mbits/sec 6 45.2 KBytes (omis)
[ 5] 9.00-10.00 sec 3.91 MBytes 32.8 Mbits/sec 8 39.6 KBytes (omis)
[ 5] 0.00-1.00 sec 3.36 MBytes 28.1 Mbits/sec 6 50.9 KBytes
[ 5] 1.00-2.00 sec 6.71 MBytes 56.3 Mbits/sec 7 56.6 KBytes
[ 5] 2.00-3.00 sec 5.03 MBytes 42.2 Mbits/sec 5 82.0 KBytes
[ 5] 3.00-4.00 sec 5.59 MBytes 46.9 Mbits/sec 15 48.1 KBytes
[ 5] 4.00-5.00 sec 5.03 MBytes 42.3 Mbits/sec 2 91.9 KBytes
[ 5] 5.00-6.00 sec 7.27 MBytes 61.0 Mbits/sec 5 91.9 KBytes
[ 5] 6.00-7.00 sec 6.77 MBytes 56.8 Mbits/sec 10 63.6 KBytes
[ 5] 7.00-8.00 sec 5.03 MBytes 48.0 Mbits/sec 6 79.2 KBytes
[ 5] 8.00-9.00 sec 5.03 MBytes 42.2 Mbits/sec 6 63.6 KBytes
[ 5] 9.00-10.00 sec 5.59 MBytes 46.8 Mbits/sec 5 79.2 KBytes
[ 5] 10.00-11.00 sec 6.71 MBytes 56.4 Mbits/sec 6 56.6 KBytes
[ 5] 11.00-12.00 sec 5.59 MBytes 46.9 Mbits/sec 12 46.7 KBytes
[ 5] 12.00-13.00 sec 3.42 MBytes 28.7 Mbits/sec 11 33.9 KBytes
[ 5] 13.00-14.00 sec 2.80 MBytes 23.5 Mbits/sec 14 41.0 KBytes
[ 5] 14:00-15:00 sec 3.91 MBytes 32.8 Mbits/sec 8 49.5 KBytes
[ 5] 15:00-16:00 sec 5.65 MBytes 47.4 Mbits/sec 5 60.8 KBytes
[ 5] 16:00-17:00 sec 7.27 MBytes 61.0 Mbits/sec 5 91.9 KBytes
[ 5] 17:00-18:00 sec 6.77 MBytes 56.8 Mbits/sec 10 63.6 KBytes
[ 5] 18:00-19:00 sec 5.72 MBytes 48.0 Mbits/sec 6 79.2 KBytes
[ 5] 19:00-20:00 sec 3.42 MBytes 28.7 Mbits/sec 18 38.2 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Intervalle Transfert Taux de données Rét.
[ 5] 0.00-20.02 sec 104 MBytes 43.5 Mbits/sec 169 expéditeur
-----------------------------------------------------------
Serveur écoute sur le port 5201
-----------------------------------------------------------
Pour ces deux exécutions, il semble que notre débit de téléchargement TCP générique en dehors du tunnel WireGuard soit d'environ 850 Mbits/sec et le débit de téléversement environ 45 Mbits/sec. Nos résultats précédents à l'intérieur du tunnel WireGuard ont montré un débit de téléversement d'environ 600 Mbits/sec et un débit de téléchargement de 90 Mbits/sec — donc il semble qu'il y ait encore une place pour l'amélioration sur le côté de la téléversement (nous ne recevons que 70% de notre débit de téléversement lorsqu'il est transmis via le tunnel WireGuard) — mais notre débit de téléchargement est en réalité deux fois meilleur lorsque nous utilisons WireGuard !
Pourquoi est le débit de téléchargement tellement meilleur avec WireGuard que sans lui dans cet exemple ? C'est un résultat assez inhabituel et il est probablement simplement une conséquence d'un réseau fortement congestionné dans notre direction de téléchargement. Certains des sauts dans cette direction ont peut-être été configurés avec plus d'espace de bande disponible pour le trafic UDP par rapport au trafic TCP, donc dans ce cas particulier, nous sommes en mesure d'obtenir beaucoup plus de données à travers la connexion simplement en emballant notre trafic TCP dans des paquets UDP WireGuard.
Mais ces résultats illustrent néanmoins l'importance de tester chaque ensemble de points de terminaison avec des connexions WireGuard et non-WireGuard afin de déterminer si vous pouvez espérer obtenir un avantage en termes de performance à partir de la configuration spécifique à WireGuard.
### De nombreuses Connexions
Pour vérifier les problèmes de performance lorsque de nombreuses connexions WireGuard sont actives, vous généralement avez besoin d'un outil de test de charge dédié, comme [JMeter](https://jmeter.apache.org/), [Gatling](https://gatling.io/), [K6](https://k6.io/), etc., afin de simuler les actions de nombreux utilisateurs individuels WireGuard qui utilisent leurs connexions simultanément. Similaire à la test d'une [Connexion Unique](#single-connection), vous exécuteriez un test de charge plusieurs fois avec la connexion WireGuard active, et vous exécuteriez le même test avec la connexion WireGuard inactive, puis vous compareriez les résultats.
Et comme avec une [Connexion Unique](#single-connection), vous devriez attendre d'obtenir environ 90% de la performance dans vos tests lorsque vous utilisez WireGuard par rapport au cas où vous ne l'utilisez pas.
De plus, similaire à une [Connexion Unique](#single-connection), si il n'est pas possible de se connecter depuis les mêmes points de terminaison en exécutant un test de charge contre une application spécifique avec WireGuard que sans, vous pouvez utiliser iPerf pour au moins simuler le trafic réseau générique. (Le désavantage de cela est que vous ajustez effectivement vos performances afin d'obtenir des résultats meilleurs sur iPerf, plutôt que d'améliorer nécessairement les performances d'une application réelle.)
Par exemple, vous pouvez simuler des connexions supplémentaires passant à travers le tunnel WireGuard entre deux points de terminaison en ajoutant l'option `--parallel` à la commande iPerf. Le suivant simulerait 10 connexio
Voici le texte corrigé :
ns ; la première test dans le sens d'upload, puis la deuxième dans le sens de download :
```bash
$ iperf3 --client 10.0.0.2 --parallel 10
Connecting to host 10.0.0.2, port 5201
[ 5] local 10.0.0.1 port 52428 connected to 10.0.0.2 port 5201
[ 7] local 10.0.0.1 port 52442 connected to 10.0.0.2 port 5201
[ 9] local 10.0.0.1 port 52444 connected to 10.0.0.2 port 5201
[ 11] local 10.0.0.1 port 52446 connected to 10.0.0.2 port 5201
[ 13] local 10.0.0.1 port 52458 connected to 10.0.0.2 port 5201
[ 15] local 10.0.0.1 port 52468 connected to 10.0.0.2 port 5201
[ 17] local 10.0.0.1 port 52474 connected to 10.0.0.2 port 5201
[ 19] local 10.0.0.1 port 52480 connected to 10.0.0.2 port 5201
[ 21] local 10.0.0.1 port 52490 connected to 10.0.0.2 port 5201
[ 23] local 10.0.0.1 port 52504 connected to 10.0.0.2 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 21.0 MBytes 176 Mbits/sec 51 225 KBytes
[ 7] 0.00-1.00 sec 10.8 MBytes 91.0 Mbits/sec 43 171 KBytes
[ 9] 0.00-1.00 sec 8.40 MBytes 70.4 Mbits/sec 28 85.4 KBytes
[ 11] 0.00-1.00 sec 8.12 MBytes 68.1 Mbits/sec 26 147 KBytes
[ 13] 0.00-1.00 sec 11.7 MBytes 98.1 Mbits/sec 29 256 KBytes
[ 15] 0.00-1.00 sec 7.97 MBytes 66.9 Mbits/sec 28 171 KBytes
[ 17] 0.00-1.00 sec 10.7 MBytes 89.5 Mbits/sec 26 171 KBytes
[ 19] 0.00-1.00 sec 10.5 MBytes 88.4 Mbits/sec 30 194 KBytes
[ 21] 0.00-1.00 sec 9.51 MBytes 79.8 Mbits/sec 30 186 KBytes
[ 23] 0.00-1.00 sec 7.94 MBytes 66.6 Mbits/sec 33 179 KBytes
[SUM] 0.00-1.00 sec 107 MBytes 895 Mbits/sec 324
- - - - - - - - - - - - - - - - - - - - - - - - -
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 9.00-10.00 sec 7.12 MBytes 59.8 Mbits/sec 5 140 KBytes
[ 7] 9.00-10.00 sec 10.4 MBytes 95.2 Mbits/sec 111 sender
[ 7] 0.00-10.02 sec 112 MBytes 93.8 Mbits/sec receiver
[ 9] 0.00-10.00 sec 87.5 MBytes 73.4 Mbits/sec 94 sender
[ 9] 0.00-10.02 sec 85.9 MBytes 71.9 Mbits/sec receiver
[ 11] 0.00-10.00 sec 94.2 MBytes 79.0 Mbits/sec 88 sender
[ 11] 0.00-10.02 sec 93.1 MBytes 77.9 Mbits/sec receiver
[ 13] 0.00-10.00 sec 101 MBytes 84.9 Mbits/sec 88 sender
[ 13] 0.00-10.02 sec 99.8 MBytes 83.5 Mbits/sec receiver
[ 15] 0.00-10.00 sec 84.9 MBytes 71.2 Mbits/sec 99 sender
[ 15] 0.00-10.02 sec 83.9 MBytes 70.2 Mbits/sec receiver
[ 17] 0.00-10.00 sec 96.3 MBytes 80.8 Mbits/sec 81 sender
[ 17] 0.00-10.02 sec 95.0 MBytes 79.5 Mbits/sec receiver
[ 19] 0.00-10.00 sec 96.0 MBytes 80.6 Mbits/sec 113 sender
[ 19] 0.00-10.02 sec 94.7 MBytes 79.2 Mbits/sec receiver
[ 21] 0.00-10.00 sec 9.51 MBytes 79.8 Mbits/sec 30 186 KBytes
[ 23] 0.00-10.02 sec 7.94 MBytes 66.6 Mbits/sec 33 179 KBytes
[SUM] 0.00-10.02 sec 957 MBytes 800 Mbits/sec receiver
iperf Done.
$ iperf3 --client 10.0.0.2 --parallel 10 --reverse --omit 10 --time 20
Connecting to host 10.0.0.2, port 5201
Reverse mode, remote host 10.0.0.2 is sending
[ 5] local 10.0.0.1 port 37494 connected to 10.0.0.2 port 5201
[ 7] local 10.0.0.1 port 37506 connected to 10.0.0.2 port 5201
[ 9] local 10.0.0.1 port 37518 connected to 10.0.0.2 port 5201
[ 11] local 10.0.0.1 port 37530 connected to 10.0.0.2 port 5201
[ 13] local 10.0.0.1 port 37534 connected to 10.0.0.2 port 5201
[ 15] local 10.0.0.1 port 37540 connected to 10.0.0.2 port 5201
[ 17] local 10.0.0.1 port 37550 connected
to 10.0.0.2 port 5201
[ 19] local 10.0.0.1 port 37554 connected to 10.0.0.2 port 5201
[ 21] local 10.0.0.1 port 37564 connected to 10.0.0.2 port 5201
[ 23] local 10.0.0.1 port 37572 connected to 10.0.0.2 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 5.45 MBytes 45.7 Mbits/sec
[ 7] 0.00-1.00 sec 6.23 MBytes 52.3 Mbits/sec
[ 9] 0.00-1.00 sec 4.09 MBytes 34.3 Mbits/sec
[ 11] 0.00-1.00 sec 6.37 MBytes 53.4 Mbits/sec
[ 13] 0.00-1.00 sec 5.84 MBytes 49.0 Mbits/sec
[ 15] 0.00-1.00 sec 2.58 MBytes 21.6 Mbits/sec
[ 17] 0.00-1.00 sec 3.60 MBytes 30.2 Mbits/sec
[ 19] 0.00-1.00 sec 4.68 MBytes 39.3 Mbits/sec
[ 21] 0.00-1.00 sec 3.14 MBytes 26.3 Mbits/sec
[ 23] 0.00-1.00 sec 5.37 MBytes 45.1 Mbits/sec
[SUM] 0.00-1.00 sec 47.4 MBytes 397 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 19.00-20.00 sec 9.37 MBytes 78.6 Mbits/sec
[ 7] 19.00-20.00 sec 3.81 MBytes 31.9 Mbits/sec
[ 9] 19.00-20.00 sec 5.42 MBytes 45.5 Mbits/sec
[ 11] 19.00-20.00 sec 6.81 MBytes 57.1 Mbits/sec
[ 13] 19.00-20.00 sec 7.72 MBytes 64.8 Mbits/sec
[ 15] 19.00-20.00 sec 4.66 MBytes 39.1 Mbits/sec
[ 17] 19.00-20.00 sec 4.79 MBytes 40.2 Mbits/sec
[ 19] 19.00-20.00 sec 4.68 MBytes 39.3 Mbits/sec
[ 21] 19.00-20.00 sec 5.00 MBytes 41.7 Mbits/sec
[ 23] 19.00-20.00 sec 4.73 MBytes 38.6 Mbits/sec
[SUM] 0.00-20.00 sec 1.13 GBytes 485 Mbits/sec 1324 sender
[SUM] 0.00-20.00 sec 1.13 GBytes 485 Mbits/sec receiver
```bash
iperf Done.
Ces 10 connexions ont géré environ 800 Mbits/sec de débit combiné lors de l’upload et 485 Mbits/sec lors du download.
Comme avec une Connexion Unique, nous voulons comparer cela au même nombre de connexions en cours d’exécution sans WireGuard. Pour ce faire, nous exécuterions les mêmes tests à l’aide de l’adresse IP publique du point de terminaison du serveur, plutôt que son adresse IP WireGuard :
$ iperf3 --client 203.0.113.2 --parallel 10
Connecting to host 203.0.113.2, port 5201
[ 5] local 192.168.1.11 port 34860 connected to 203.0.113.2 port 5201
[ 7] local 192.168.1.11 port 34864 connected to 203.0.113.2 port 5201
[ 9] local 192.168.1.11 port 34872 connected to 203.0.113.2 port 5201
[ 11] local 192.168.1.11 port 34884 connected to 203.0.113.2 port 5201
[ 13] local 192.168.1.11 port 34898 connected to 203.0.113.2 port 5201
[ 15] local 192.168.1.11 port 34914 connected to 203.0.113.2 port 5201
[ 17] local 192.168.1.11 port 34922 connected to 203.0.113.2 port 5201
[ 19] local 192.168.1.11 port 34928 connected to 203.0.113.2 port 5201
[ 21] local 192.168.1.11 port 34938 connected to 203.0.113.2 port 5201
[ 23] local 192.168.1.11 port 34954 connected to 203.0.113.2 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 5.45 MBytes 45.7 Mbits/sec
[ 7] 0.00-1.00 sec 6.23 MBytes 52.3 Mbits/sec
[ 9] 0.00-1.00 sec 4.09 MBytes 34.3 Mbits/sec
[ 11] 0.00-1.00 sec 6.37 MBytes 53.4 Mbits/sec
[ 13] 0.00-1.00 sec 5.84 MBytes 49.0 Mbits/sec
[ 15] 0.00-1.00 sec 2.58 MBytes 21.6 Mbits/sec
[ 17] 0.00-1.00 sec 3.60 MBytes 30.2 Mbits/sec
[ 19] 0.00-1.00 sec 4.68 MBytes 39.3 Mbits/sec
[ 21] 0.00-1.00 sec 3.14 MBytes 26.3 Mbits/sec
[ 23] 0.00-1.00 sec 5.37 MBytes 45.1 Mbits/sec
[SUM] 0.00-1.00 sec
110 MBytes 925 Mbits/sec 219
[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 151 MBytes 127 Mbits/sec 113 sender [ 5] 0.00-10.01 sec 149 MBytes 125 Mbits/sec receiver [ 7] 0.00-10.00 sec 114 MBytes 95.3 Mbits/sec 85 sender [ 7] 0.00-10.01 sec 111 MBytes 93.2 Mbits/sec receiver [ 9] 0.00-10.00 sec 123 MBytes 103 Mbits/sec 97 sender [ 9] 0.00-10.01 sec 121 MBytes 101 Mbits/sec receiver [ 11] 0.00-10.00 sec 122 MBytes 103 Mbits/sec 76 sender [ 11] 0.00-10.01 sec 121 MBytes 101 Mbits/sec receiver [ 13] 0.00-10.00 sec 89.7 MBytes 75.2 Mbits/sec 27 sender [ 13] 0.00-10.01 sec 88.4 MBytes 74.1 Mbits/sec receiver [ 15] 0.00-10.00 sec 132 MBytes 111 Mbits/sec 99 sender [ 15] 0.00-10.01 sec 130 MBytes 109 Mbits/sec receiver [ 17] 0.00-10.00 sec 63.0 MBytes 52.9 Mbits/sec 30 sender [ 17] 0.00-10.01 sec 61.9 MBytes 51.8 Mbits/sec receiver [ 19] 0.00-10.00 sec 89.0 MBytes 74.7 Mbits/sec 35 sender [ 19] 0.00-10.01 sec 88.0 MBytes 73.8 Mbits/sec receiver [ 21] 0.00-10.00 sec 93.6 MBytes 78.5 Mbits/sec 46 sender [ 21] 0.00-10.01 sec 92.6 MBytes 77.6 Mbits/sec receiver [ 23] 0.00-10.00 sec 118 MBytes 98.8 Mbits/sec 191 sender [ 23] 0.00-10.01 sec 115 MBytes 96.0 Mbits/sec receiver [SUM] 0.00-10.00 sec 1.07 GBytes 919 Mbits/sec 799 sender [SUM] 0.00-10.01 sec 1.05 GBytes 903 Mbits/sec receiver
iperf Done.
$ iperf3 --client 203.0.113.2 --parallel 10 --reverse --omit 10 --time 20
Connecting to host 203.0.113.2, port 5201
Reverse mode, remote host 203.0.113.2 is sending
[ 5] local 192.168.1.11 port 32818 connected to 203.0.113.2 port 5201
[ 7] local 192.168.1.11 port 32830 connected to 203.0.113.2 port 5201
[ 9] local 192.168.1.11 port 32832 connected to 203.0.113.2 port 5201
[ 11] local 192.168.1.11 port 32834 connected to 203.0.113.2 port 5201
[ 13] local 192.168.1.11 port 32850 connected to 203.0.113.2 port 5201
[ 15] local 192.168.1.11 port 32854 connected to 203.0.113.2 port 5201
[ 17] local 192.168.1.11 port 32856 connected to 203.0.113.2 port 5201
[ 19] local 192.168.1.11 port 32866 connected to 203.0.113.2 port 5201
[ 21] local 192.168.1.11 port 32880 connected to 203.0.113.2 port 5201
[ 23] local 192.168.1.11 port 32892 connected to 203.0.113.2 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 3.94 MBytes 33.0 Mbits/sec (omitted)
[ 7] 0.00-1.00 sec 5.30 MBytes 44.5 Mbits/sec (omitted)
[ 9] 0.00-1.00 sec 2.13 MBytes 17.8 Mbits/sec (omitted)
[ 11] 0.00-1.00 sec 4.10 MBytes 34.4 Mbits/sec (omitted)
[ 13] 0.00-1.00 sec 5.98 MBytes 50.2 Mbits/sec (omitted)
[ 15] 0.00-1.00 sec 4.69 MBytes 39.3 Mbits/sec (omitted)
[ 17] 0.00-1.00 sec 2.38 MBytes 20.0 Mbits/sec (omitted)
[ 19] 0.00-1.00 sec 3.54 MBytes 29.7 Mbits/sec (omitted)
[SUM] 0.00-1.00 sec 40.5 MBytes 340 Mbits/sec (omitted)
- - - - - - - - - - - - - - - - - - - - - - - - -
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 19.00-20.00 sec 4.21 MBytes 35.3 Mbits/sec
[ 7] 19.00-20.00 sec 3.53 MBytes 29.6 Mbits/sec
[ 9] 19.00-20.00 sec 95.6 MBytes 40.1 Mbits/sec 146 sender
[ 9] 19.00-20.00 sec 95.4 MBy
tes 40.0 Mbits/sec receiver
[ 11] 19.00-20.00 sec 114 MBytes 47.8 Mbits/sec 150 sender
[ 11] 19.00-20.00 sec 114 MBytes 47.8 Mbits/sec receiver
[ 13] 19.00-20.00 sec 97.3 MBytes 40.8 Mbits/sec 153 sender
[ 13] 19.00-20.00 sec 97.3 MBytes 40.8 Mbits/sec receiver
[ 15] 19.00-20.00 sec 91.3 MBytes 38.3 Mbits/sec 168 sender
[ 15] 19.00-20.00 sec 91.2 MBytes 38.2 Mbits/sec receiver
[ 17] 19.00-20.00 sec 92.3 MBytes 38.7 Mbits/sec 169 sender
[ 17] 19.00-20.00 sec 92.5 MBytes 38.8 Mbits/sec receiver
[ 19] 19.00-20.00 sec 92.4 MBytes 38.7 Mbits/sec 135 sender
[ 19] 19.00-20.00 sec 92.5 MBytes 38.8 Mbits/sec receiver
[ 21] 19.00-20.00 sec 95.1 MBytes 39.9 Mbits/sec 161 sender
[ 21] 19.00-20.00 sec 94.9 MBytes 39.8 Mbits/sec receiver
[ 23] 19.00-20.00 sec 108 MBytes 45.3 Mbits/sec 157 sender
[ 23] 19.00-20.00 sec 108 MBytes 45.2 Mbits/sec receiver
[SUM] 19.00-20.00 sec 955 MBytes 401 Mbits/sec 1579 sender
[SUM] 19.00-20.00 sec 955 MBytes 401 Mbits/sec receiver
```iperf Done.
Sans WireGuard, les tests montrent environ 900 MBits/sec en upload et 400 MBits/sec en download. C'est ce que vous pourriez attendre pour le débit d'upload (800 MBits/sec avec WireGuard contre 900 MBits/sec sans), mais surprenantement plus rapide avec WireGuard lors de la download (485 MBits/sec avec WireGuard contre 400 MBits/sec sans). Cela est probablement dû à une congestion TCP particulière sur le chemin de download.
Pour cet exemple particulier, aucune quantité de réglage spécifique à WireGuard ne devrait améliorer les performances avec 10 connexions simultanées. Il pourrait être une histoire différente avec 100 ou 1000 connexions simultanées, bien que ce soit important de tester avec un charge de travail réel (mais vous aurez probablement besoin d'au moins quelques machines clientes supplémentaires pour tester 100 connexions simultanées, et une douzaine ou plus pour tester 1000 connexions actuelles).
## Ajustements
Si vous obtenez des performances significativement inférieures avec WireGuard que ce que vous attendez sur vos tests, voici cinq domaines de problème à vérifier et essayer d'ajuster :
1. [CPU](#cpu)
2. [Contrôle de congestion TCP](#tcp-congestion-control)
3. [Fragmentation des paquets](#packet-fragmentation)
4. [Tamponnement des paquets](#packet-buffering)
5. [Suivi des connexions](#connection-tracking)
### CPU
La gestion du trafic WireGuard nécessite quelques cycles supplémentaires de CPU pour chiffrer et déchiffrer les paquets envoyés et reçus via le tunnel WireGuard. Cette surcharge est généralement minime, mais peut avoir un impact sur les systèmes peu puissants (comme une Raspberry Pi), ou sur les systèmes qui gèrent de nombreuses connexions WireGuard simultanées.
Tandis que vous exécutez des tests avec WireGuard, vérifiez l'utilisation du CPU de chaque point de terminaison ainsi que chaque hub ou passerelle WireGuard impliquée dans la connexion. L'observation visuelle de l'utilisation du CPU à l'aide d'un outil comme [htop](https://htop.dev/) ou un outil similaire qui affiche l'utilisation du CPU graphiquement est acceptable pour ce type de vérification. Si l'utilisation du CPU reste constamment supérieure à 90% lors d'un test sur l'un des systèmes, il est probable que le CPU du système limite le débit de WireGuard.
Malheureusement, la seule chose que vous pouvez faire pour corriger ce problème est de remplacer le système par un modèle ayant un processeur plus puissant.
### Contrôle de congestion TCP
L'algorithme d'assainissement de congestion TCP par défaut utilisé par la plupart des systèmes d'exploitation modernes, [CUBIC](https://www.rfc-editor.org/rfc/rfc9438), ne convient pas bien à WireGuard (o
u à tout autre protocole qui encapsule TCP dans UDP). L'algorithme [BBR](https://datatracker.ietf.org/doc/html/draft-cardwell-iccrg-bbr-congestion-control) est une meilleure correspondance, car il est moins sensible au perte de paquets et beaucoup plus agressif dans sa recherche de la fenêtre de congestion optimale. Si vos tests de performance montrent que la fenêtre de congestion TCP oscille (ou se réduit significativement après un ouverture rapide initiale), le contrôle de congestion TCP est probablement le problème — et le passage à l'algorithme BBR peut aider.
Le contrôle de congestion est géré sur le côté d'envoi de la connexion — le côté serveur pour les téléchargements, le côté client pour les téléversements. Il doit généralement être défini globalement pour l'hôte, donc soyez conscient que le changement de ce paramètre pour les connexions TCP envoyées via WireGuard modifiera également les connexions TCP *non envoyées* via WireGuard (ce qui pourrait leur causer des dommages).
Sur Linux, vous pouvez afficher l'algorithme d'assainissement de congestion TCP actuel en exécutant la commande suivante :
```bash
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
Et vous pouvez le changer en BBR (jusqu’au prochain redémarrage) avec la commande suivante :
$ sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
Pour l’appliquer automatiquement après un redémarrage du système, ajoutez la ligne suivante au fichier /etc/sysctl.conf (ou à tout fichier dans le répertoire /etc/sysctl.d/, comme /etc/sysctl.d/custom.conf) :
net.ipv4.tcp_congestion_control=bbr
|
Mise en garde
|
Pour les noyaux Linux antérieurs à la version 4.20, vous devriez également modifier le qdisc (discipline de file d'attente) pour vos interfaces réseau physiques afin d'utiliser le |
Sur FreeBSD, BBR est disponible depuis la version 13.0, mais vous devrez généralement compiler le noyau avec certaines options supplémentaires. Avec un noyau qui prend en charge BBR, vous pouvez l’activer en chargeant le module tcp_bbr et en définissant le paramètre de noyau net.inet.tcp.functions_default :
# kldload tcp_bbr
# sysctl net.inet.tcp.functions_default=bbr
Consultez la discussion Comment activer TCP BBR sur FreeBSD ? pour plus de détails.
Dans les dernières versions de Windows, vous pouvez afficher l’algorithme d’optimisation de congestion TCP actuel en exécutant la commande suivante :
> Get-NetTCPSetting | Select SettingName, CongestionProvider
SettingName CongestionProvider
----------- ------------------
Automatic
InternetCustom CUBIC
DatacenterCustom CUBIC
Compat CUBIC
Datacenter CUBIC
Internet CUBIC
Et vous pouvez le changer en BBR avec les commandes suivantes :
> netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2
> netsh int tcp set supplemental Template=Datacenter CongestionProvider=bbr2
> netsh int tcp set supplemental Template=Compat CongestionProvider=bbr2
> netsh int tcp set supplemental Template=DatacenterCustom CongestionProvider=bbr2
> netsh int tcp set supplemental Template=InternetCustom CongestionProvider=bbr2
Fragmentation de paquets
De nombreuses connexions Ethernet ont une taille maximale d'
Emission (MTU) de 1500 octets, ce qui signifie que chaque trame Ethernet peut transporter jusqu’à 1500 octets de contenu (sans inclure les en-têtes Ethernet eux-mêmes, mais y compris les en-têtes des paquets envoyés à l’intérieur de chaque trame). Cependant, d’autres tailles d’MTU sont courantes, comme 9000 ou plus pour les liens réseau au sein d’un datacenter, ou 1492 pour de nombreuses connexions PPPoE (Protocole de pont point-à-point sur Ethernet) entre les fournisseurs d’accès Internet (ISPs) et leurs abonnés.
Les paquets plus grands que la taille d’MTU d’une connexion Ethernet ne peuvent pas être transmis. Lorsque des paquets IPv4 trop grands sont rencontrés, le pile réseau du dispositif peut faire l’un de deux choses :
- Décourager le paquet et envoyer un paquet ICMP “Fragmentation nécessaire” au source du paquet original.
- Fragmenter le paquet en petits paquets qui correspondent à la taille d’MTU et les envoyer aux destinataires originaux.
(Avec IPv6, le paquet est toujours découragé et un paquet ICMPv6 “Paquet trop grand” est envoyé.)
Les deux options auront un effet négatif sur les performances, car elles entraîneront l’envoi et le traitement de paquets supplémentaires. De plus, lorsque la deuxième option est prise, le paquet ICMP (ou ICMPv6) peut jamais parvenir au source original, car une traduction d’adresse réseau (NAT) ou un pare-feu restrictif devant le source peut bloquer tous les paquets ICMP et ICMPv6. Si ces paquets sont bloqués, la connexion apparaîtra “figée” complètement, car le trafic du source original ne parviendra jamais à sa destination voulue sous quelque forme que ce soit.
La solution à ce problème est de définir manuellement la taille de l’MTU (Maximum Transmission Unit) sur la connexion WireGuard suffisamment basse pour que les paquets ne soient pas obligés d’être fragmentés. La taille de l’MTU de chaque interface WireGuard devrait être définie 60 octets inférieure à la taille de l’MTU du lien le plus étroit dans la connexion lorsque vous utilisez IPv4 (et 80 octets inférieure lorsque vous utilisez IPv6).
Une autre façon de déterminer la bonne taille d’MTU pour une interface WireGuard est de vérifier la taille négociée de l’MSS (Maximum Segment Size) d’une connexion TCP établie entre les deux points de terminaison en dehors du tunnel WireGuard (ceci ne fonctionne cependant que si les routeurs où les tailles d’MTU changent ont mis en œuvre “MSS clamping”). L’MSS est la taille maximale de charge utile qu’un paquet TCP peut transporter à travers la connexion (sans inclure les en-têtes du packet). L’MSS est effectivement l’MTU moins les en-têtes TCP/IP ; et les en-têtes combinés TCP/IP sont de 40 octets avec IPv4, et 60 octets avec IPv6 :
Figure 1. Taille d’MTU et MSS avec un paquet TCP IPv4 régulier
L’MTU sur une interface WireGuard devrait être de 60 octets inférieure à la taille de l’MTU de l’interface Ethernet par laquelle ses paquets tunnelés se déplacent (lorsque vous utilisez IPv4 pour transporter les paquets tunnelés ; 80 octets inférieure lorsque vous utilisez IPv6). Et l’MSS des paquets TCP tunnelés devrait être d’une autre 40 octets inférieure (lorsque les paquets eux-mêmes utilisent IPv4 ; 60 octets lorsque vous utilisez IPv6) :
Figure 2. Taille d’MTU et MSS avec un paquet TCP IPv4 tunnelé à travers WireGuard via un paquet UDP IPv4
Pour vérifier le MSS négocié, exécutez tcpdump sur chaque point de terminaison pour capturer les paquets SYN et SYN-ACK d’un échange de clés TCP. Au point de terminaison destinataire, le paquet SYN montrera le MSS ajusté par tout routeur sur le chemin vers le destinataire (tandis que sur le point de terminaison initiateur, le paquet SYN montrera le MSS comme demandé initialement). Sur le point de terminaison initiateur, le paquet SYN-ACK retourné montrera le MSS ajusté par tout routeur sur le chemin vers l'
initiateur (tandis que sur le point de terminaison destinataire, le SYN-ACK montrera le MSS comme demandé initialement).
Si la connexion a été routée à travers un chemin différent en direction du destinataire qu’en direction de l’initiateur, vous pourriez voir une valeur différente du MSS dans le paquet SYN au destinataire que celle que vous voyez dans le paquet SYN-ACK à l’initiateur ; mais généralement ils seront les mêmes.
Par exemple, si vous exécutez tcpdump avec une expression comme tcp[tcpflags] == tcp-syn or tcp[tcpflags] == tcp-syn|tcp-ack sur les deux points de terminaison, et que vous ouvrez une connexion SSH à partir d’un point de terminaison à l’autre en dehors de WireGuard, vous verrez une sortie de tcpdump comme celle-ci sur le côté initiateur de la connexion :
$ sudo tcpdump -ni eth0 'tcp[tcpflags] == tcp-syn or tcp[tcpflags] == tcp-syn|tcp-ack'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:16:55.656028 IP 192.168.1.11.19546 > 203.0.113.2.22: Flags [S], seq 3349242392, win 64240, options [mss 1460,sackOK,TS val 2936811543 ecr 0,nop,wscale 7], length 0
17:16:55.656089 IP 203.0.113.2.22 > 192.168.1.11.19546: Flags [S.], seq 735473634, ack 3349242393, win 62643, options [mss 1360,sackOK,TS val 3872048576 ecr 2936811543,nop,wscale 6], length 0
Et une sortie comme celle-ci sur le côté receveur de la connexion :
$ sudo tcpdump -ni eth0 'tcp[tcpflags] == tcp-syn or tcp[tcpflags] == tcp-syn|tcp-ack'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:16:55.656028 IP 198.51.100.11.19546 > 192.168.200.22.22: Flags [S], seq 3349242392, win 64240, options [mss 1360,sackOK,TS val 2936811543 ecr 0,nop,wscale 7], length 0
17:16:55.656089 IP 192.168.200.22.22 > 198.51.100.11.19546: Flags [S.], seq 735473634, ack 3349242393, win 62643, options [mss 8960,sackOK,TS val 3872048576 ecr 2936811543,nop,wscale 6], length 0
Cela montre que le point de terminaison initiateur a d’abord envoyé un paquet SYN avec une taille maximale segmentaire (MSS) de 1460 (indiquant un MTU de 1500 sur son interface Ethernet), mais au moment où il est arrivé au point de terminaison receveur, certains routeurs intermédiaires le long du chemin avaient réduit la taille maximale segmentaire à 1360. De même, le point de terminaison receveur avait d’abord envoyé son paquet SYN-ACK en retour avec une taille maximale segmentaire de 8960 (indiquant un MTU de 9000 sur son interface Ethernet), mais il avait été réduit à 1360 au moment où il était revenu à l’initiateur.
Comme cette connexion utilise IPv4, nous ajoutons 40 octets à la taille maximale segmentaire négociée de 1360 pour obtenir une taille MTU de 1400 pour le lien le plus étroit dans la connexion. Ensuite, nous soustrayons 60 octets de cette taille MTU du lien pour obtenir la taille MTU que nous devons définir pour une interface WireGuard utilisant cette connexion (100 octets inférieurs à ce que nous aurions généralement attendu).
Paquet trop grand
Avec IPv6, vous pouvez également utiliser tcpdump pour vérifier les messages ICMPv6 “Packet Too Big”, qui incluent la taille de l’MTU à laquelle les paquets doivent être réduits. Cependant, cela ne fonctionnera que si le point de terminaison source n’est pas derrière NAT66 ou un pare-feu restrictif bloquant les messages ICMPv6. De plus, vous devez vous assurer d’envoyer un message assez grand du côté initiateur (comme un téléchargement de fichier) pour obtenir un message “Packet Too Big” renvoyé à l’initiateur, ou un message assez grand du côté récepteur (comme un téléchargement de fichier) pour obtenir un message “Packet Too Big” renvoyé au récepteur. (Il se peut que vous deviez répéter le processus une ou plusieurs fois pour trouver enfin le point de congestion le plus petit.)
Par exemple, si vous exécutez tc
Voici le texte corrigé :
Utilisez pdump avec une expression comme icmp6[icmp6type] == icmp6-packettoobig sur un point de terminaison, et que vous essayez ensuite d’envoyer un paquet trop grand depuis celui-ci vers l’autre point de terminaison via IPv6, vous devriez voir une sortie similaire à celle-ci de tcpdump :
$ sudo tcpdump -ni eth0 'icmp6[icmp6type] == icmp6-packettoobig'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:13:47.908474 IP6 2001:db8:100::1 > 2001:db8:200::2: ICMP6, packet too big, mtu 1400, length 1240
Soustrayez 80 de la taille de l’MTU indiquée dans le message ICMPv6 (1400 dans l’exemple ci-dessus), et définissez cette valeur comme MTU pour votre interface WireGuard.
Restriction de la taille des segments (MSS Clamping)
Avec une connexion WireGuard site à site, une fois que vous avez déterminé la taille d’MTU appropriée pour les interfaces WireGuard sur chaque côté de la connexion, assurez-vous également d’ajouter une règle de restriction de la taille des segments (MSS clamping) au pare-feu sur un ou deux côtés. Une telle règle dirige le pare-feu à réécrire la valeur demandée de MSS dans les paquets TCP où la valeur MSS du paquet est supérieure à la calculée par le pare-feu (qui détermine cette valeur en utilisant l’MTU des interfaces réseau du pare-feu sur le chemin du paquet, et les tailles d’en-tête de la version TCP/IP utilisée).
Cela garantira que les connexions TCP entre deux points de terminaison qui ne connaissent pas eux-mêmes la réduction de l’MTU sur le tunnel WireGuard entre eux auront leur MSS ajusté automatiquement, sans nécessiter des messages ICMP supplémentaires ou en risquant une fragmentation des paquets.
La règle suivante iptables restreint tous les MSS de toutes les connexions TCP transmises par le pare-feu :
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Avec nftables, vous ajouteriez une règle similaire quelque part dans le hook forward d’une chaîne filter :
table inet filter {
...
chain forward {
type filter hook forward priority 0; policy drop;
...
tcp flags syn / syn,rst tcp option maxseg size set rt mtu
...
}
...
}
|
Tip
|
Voir le guide WireGuard avec Nftables pour un exemple qui effectue une restriction de MSS d'une manière légèrement plus ciblée, en restreignant simplement les paquets sortants du tunnel WireGuard à chaque site — ce qui évite de réaliser le travail de restriction si ce n'est pas nécessaire. |
Tamponnement des Paquets
Les paramètres réseau par défaut la plupart des systèmes d’exploitation modernes sont déjà bien calibrés pour gérer quelques dizaines de connexions réseau concurrentes. Cependant, si vous exécutez un hub WireGuard, une passerelle ou un point de terminaison de service qui gère centaines de connexions WireGuard concurrentes, il existe quelques paramètres sur celui-ci que vous pouvez ajuster qui pourraient améliorer les performances.
Sur Linux en particulier, il existe trois ensembles de paramètres du noyau liés au tampon des paquets qui peuvent être ajustés pour améliorer le débit de la connexion WireGuard. Effectuez vos tests de charge avant et après pour voir si vos modifications ont un effet. La méthode d’essai et d’erreur est la seule façon de déterminer la valeur optimale pour chaque paramètre ; une bonne règle de thumb est d’essayer de doubler la valeur actuelle du paramètre, et de voir s’il y a un effet.
Vous pouvez afficher la valeur actuelle d’un paramètre du noyau avec la commande sysctl :
$ sysctl net.core.netdev_budget
net.c
```markdown
ore.netdev_budget = 300
Et vous pouvez la modifier (jusqu'au prochain redémarrage) avec l'indicateur `-w` :
```bash
$ sudo sysctl -w net.core.netdev_budget=600
Pour appliquer vos paramètres personnalisés après un redémarrage du système, ajoutez-les au fichier /etc/sysctl.conf (ou à tout fichier dans le répertoire /etc/sysctl.d/, comme /etc/sysctl.d/custom.conf).
Taux de traitement des paquets
Sur un serveur avec un CPU puissant, vous pourriez être en mesure d’améliorer le débit en augmentant le nombre de paquets traités par cycle d’interrogation du pilote réseau, permettant au serveur de nettoyer les paquets tamponnés plus efficacement. Essayez d’ajuster ces paramètres du noyau :
net.core.netdev_budget- Nombre maximum de paquets qui peuvent être traités pendant un cycle d’interrogation. Le cycle est terminé lorsque cette valeur ou
net.core.netdev_budget_usecsest atteinte. net.core.netdev_budget_usecs- Nombre maximum de microsecondes qui peuvent s’écouler pendant un cycle d’interrogation.
net.core.dev_weight- Nombre maximum de paquets (par cœur CPU) à partir de la file d’attente en attente qui peuvent être traités pendant un cycle d’interrogation.
net.core.netdev_tstamp_prequeue- Définissez cette valeur à
0pour permettre une distribution plus équitable du traitement sur les coeurs CPU.
Buffers d’envoi et de réception UDP
Si le processeur de votre serveur est assez puissant pour nettoyer rapidement beaucoup de paquets, augmenter le nombre brut de paquets UDP qu’il peut tamponner peut également lui permettre de gérer un débit WireGuard plus élevé. Essayez d’ajuster ces paramètres du noyau :
net.core.rmem_default- Taille par défaut du tampon de réception d’un socket en octets. Lorsque vous augmentez cette valeur, assurez-vous également d’augmenter la taille de
net.core.rmem_maxpour qu’elle soit au moins aussi grande que celle-ci. Les paquets WireGuard seront ajoutés à un tampon de cette taille lorsqu’ils sont reçus — si le tampon (et la file d’attente de retraitement) est plein, les paquets entrants seront déchargés jusqu’à ce qu’espace puisse être libéré en traitant les paquets déjà dans le tampon. net.core.rmem_max- Taille maximale du tampon de réception d’un socket en octets. Généralement, il n’y a pas de raison de définir cette valeur plus grande que
net.core.rmem_default. net.core.wmem_default- Taille par défaut du tampon d’envoi d’un socket en octets. Lorsque vous augmentez cette valeur, assurez-vous également d’augmenter la taille de
net.core.wmem_maxpour qu’elle soit au moins aussi grande que celle-ci. Les paquets WireGuard seront ajoutés à un tampon de cette taille lorsqu’ils sont envoyés — si le tampon est plein, les paquets sortants seront déchargés jusqu’à ce qu’espace puisse être libéré en envoyant les paquets déjà dans le tampon. (Cela ne devrait pas être aussi grave qu’avec le tampon de réception.) net.core.wmem_max- Taille maximale du tampon d’envoi d’un socket en octets. Généralement, il n’y a pas de raison de définir cette valeur plus grande que
net.core.wmem_default. net.core.netdev_max_backlog- Nombre maximal de paquets (par cœur CPU) qui peuvent être tamponnés dans la file d’attente du pilote réseau avant qu’ils ne soient traités.
La file d'attente des paquets permet de tamponner temporairement les paquets jusqu'à ce qu'il y ait de l'espace pour les ajouter au tampon de réception approprié du socket.
Notez que les retours diminuent avec l'augmentation de ces valeurs, car à un certain point, vous atteindrez le stade où vous tamponnerez plus de paquets que le serveur ne peut traiter. Lorsque cela se produit, votre mesure de performance s'en dégradera rapidement par rapport au niveau précédent, car le serveur commencera à rejeter les paquets à nouveau — mais cette fois avec un délai plus important qui rend plus difficile pour les clients de réduire leur propre taux d'envoi — créant les conditions pour [le bloat de tampon](https://www.bufferbloat.net/).
#### Tampons TCP d'envoi/reception
Si vous essayez d'améliorer le rendement d'une application qui utilise TCP (comme une application web), et que cette application est hébergée sur un point de terminaison WireGuard, vous pourriez également vouloir essayer d'ajuster les paramètres du noyau liés au tampon TCP sur ce point de terminaison. En particulier, essayez d'ajuster ces paramètres :
`net.ipv4.tcp_rmem`
: Tailles des tampons de réception des sockets TCP en octets : minimum, par défaut et maximum. Le noyau peut ajuster automatiquement la taille du tampon réellement allouée pour un socket entre le minimum et le maximum.
`net.ipv4.tcp_wmem`
: Tailles des tampons d'envoi des sockets TCP en octets : minimum, par défaut et maximum. Le noyau peut ajuster automatiquement la taille du tampon réellement allouée pour un socket entre le minimum et le maximum.
`net.ipv4.tcp_adv_win_scale`
: Facteur d'échelle de la fenêtre TCP. Consultez l'article de Cloudflare [Optimizing TCP for high WAN throughput while preserving low latency](https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/) pour une explication excelente de comment cela fonctionne en conjonction avec `net.ipv4.tcp_rmem` et `net.ipv4.tcp_wmem`.
`net.core.somaxconn`
: Nombre maximum de paquets qui peuvent être tamponnés dans les files d'attente TCP. Consultez l'article de Cloudflare [Gestion des paquets SYN en production](https://blog.cloudflare.com/syn-packet-handling-in-the-wild/) pour une discussion détaillée sur la calibration de ce paramètre.
### Suivi des Connexions
Le suivi des connexions (appelé "conntrack" en anglais) permet à un pare-feu d'identifier et de regrouper tous les paquets individuels envoyés et reçus entre deux points de terminaison au sein d'une connexion bidirectionnelle continue entre ces deux points. En utilisant l'ensemble plus large d'une connexion continue, le pare-feu peut "se souvenir" des paquets qui passent dans un sens à travers la connexion afin qu'il puisse appliquer des règles spéciales aux paquets qui reviennent de l'autre côté. Les pare-feux ayant cette capacité sont appelés pare-feux étatifs.
Si vous exécutez vos connexions WireGuard à travers un pare-feu étatif, le système conntrack du pare-feu ajoutera une certaine surcharge de performance supplémentaire. L'impact de cela sera négligeable, cependant — sauf si vous exécutez centaines de connexions simultanées à travers celui-ci.
Le suivi des connexions est généralement utilisé pour des choses comme le NAT, la masquarade de connexion, le transfert de ports ou les connexions sortantes uniquement. Si vous ne utilisez aucune de ces fonctionnalités avec WireGuard, vous pouvez trouver que vous pouvez améliorer le débit en désactivant le suivi des connexions pour vos connexions WireGuard.
Par exemple, les règles iptables suivantes désactiveront le suivi des connexions pour le trafic envoyé ou reçu à l'intérieur d'un tunnel WireGuard (où l'interface WireGuard est nommée `wg0`):
```bash
iptables -t raw -A PREROUTING -i wg0 -j NOTRACK
iptables -t raw -A OUTPUT -o wg0 -j NOTRACK
Et les règles iptables suivantes feront la même chose pour le tunnel WireGuard lui-même (pour une interface WireGuard écoutant sur le port 51820):
iptables -t raw -A PREROUTING -p udp --dport 51820 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 51820 -j NOTRACK
Les règles équivalentes pour nftables ressembleraient à ceci :
table inet raw {
...
chain prerouting {
type filter hook prerouting priority -300; policy accept;
udp dport 51820 notrack
iifname "wg0" notrack
...
}
...
chain output {
type filter hook output priority -300; policy accept;
udp sport 51820 notrack
oifname "wg0" notrack
...
}
...
}
D’autre part, si vous utilisez le suivi des connexions sur un système Linux qui traite centaines ou mille de connexions simultanées, vous pourriez vouloir ajuster les paramètres suivants du noyau pour s’assurer que la table de hachage de suivi des connexions du système ne soit pas complètement remplie :
-
net.netfilter.nf_conntrack_buckets- Taille de la table de hachage de suivi des connexions.
-
net.netfilter.nf_conntrack_max- Nombre maximum d’entrées autorisées dans la table de hachage de suivi des connexions.
Vous pouvez utiliser la commande conntrack pour vérifier les statistiques de suivi des connexions (elle est disponible dans la plupart des distributions Linux via le paquet conntrack ou conntrack-tools). La commande conntrack -L affichera le contenu actuel de la table de hachage de suivi des connexions, et la commande conntrack -S montrera les statistiques cumulatives du suivi des connexions du système :
$ sudo conntrack -L
udp 17 19 src=192.168.200.22 dst=185.125.190.58 sport=60354 dport=123 src=185.125.190.58 dst=192.168.200.22 sport=123 dport=60354 mark=0 use=1
udp 17 21 src=192.168.200.22 dst=69.89.207.99 sport=46452 dport=123 src=69.89.207.99 dst=192.168.200.22 sport=123 dport=46452 mark=0 use=1
tcp 6 299 ESTABLISHED src=192.168.200.22 dst=5.180.19.95 sport=22 dport=28499 src=5.180.19.95 dst=192.168.200.22 sport=28499 dport=22 [ASSURED] mark=0 use=1
udp 17 25 src=192.168.200.22 dst=169.254.169.123 sport=56722 dport=123 src=169.254.169.123 dst=192.168.200.22 sport=123 dport=56722 mark=0 use=1
udp 17 29 src=127.0.0.1 dst=127.0.0.53 sport=51869 dport=53 src=127.0.0.53 dst=127.0.0.1 sport=53 dport=51869 mark=0 use=1
udp 17 25 src=192.168.200.22 dst=68.233.45.146 sport=59584 dport=123 src=68.233.45.146 dst=192.168.200.22 sport=123 dport=59584 mark=0 use=1
conntrack v1.4.6 (conntrack-tools): 6 flow entries have been shown.
$ sudo conntrack -S
cpu=0 found=3 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=5 (null)=0 (null)=0
cpu=1 found=2 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=3 (null)=0 (null)=0
De plus, si vous utilisez le suivi des connexions pour les connexions TCP transitant à travers votre réseau WireGuard, vous pouvez trouver que le système de suivi des connexions marquera occasionnellement les connexions TCP établies comme « invalides », en raison de paquets TCP manquants ou hors d’ordre. Si votre pare-feu supprime les flux de suivi des connexions invalides, ces connexions seront terminées brutalement. En changeant la valeur des deux paramètres du noyau suivants à 1, cela empêchera cela de se produire :
-
net.netfilter.nf_conntrack_be_liberal- Définissez cette valeur sur
1pour éviter de marquer les violations d’état TCP comme invalides (sauf pour les paquets RST hors fenêtre).
-
net.netfilter.nf_conntrack_ignore_invalid_rst- Définissez cette valeur sur
1pour éviter de marquer les paquets RST hors fenêtre comme invalides.
12/9/2022
(mis à jour 9/17/2023)
par Justin Ludwig
by Justin Ludwig translated by: Patrice Le Guyader