WireGuard est lent : MTU, routage, CPU — Accélérez sans conjectures

novembre 16, 2025 • février 3, 2026 • Lecture : 34 min • Views: 10

Cet article vous a aidé ?

WireGuard « fonctionne », ce qui est l’état le plus dangereux pour un VPN. Vous pouvez faire un ping, SSH, peut‑être même ouvrir une page web — pourtant les transferts de fichiers rampent,
les sauvegardes dépassent leur fenêtre, et votre fibre « rapide » ressemble à une connexion Wi‑Fi de motel avec des problèmes d’engagement.

Voici le guide de terrain pour transformer « WireGuard est lent » en un goulot mesuré, une correction spécifique, et une méthode répétable. Pas de folklore. Pas
de numéros MTU tirés au hasard d’un post de forum de 2019. Nous allons tester, lire les compteurs et appliquer des changements que vous pourrez défendre dans un postmortem.

Le modèle mental : où WireGuard peut être lent

WireGuard n’est « que » une interface réseau et un transport UDP. Cette simplicité est ce qui le rend apprécié — et ce pourquoi les problèmes de performance viennent souvent
de tout ce qui l’entoure : MTU, routage, NAT, comportement du pilote NIC, files du noyau et ordonnancement CPU.

Il y a quatre modes de défaillance courants qui se manifestent par « lent » :

PMTU / trous noirs de fragmentation : les petits paquets fonctionnent, les gros transferts se bloquent ou oscillent.
Mauvaise route / mauvaise politique : le trafic fait des boucles, traverse le NAT deux fois, ou sort par la mauvaise interface.
Goulot CPU : un cœur monte à 100% pendant iperf ; le débit plafonne à une valeur rondement suspecte.
Pertes/queues sur UDP : TCP sur UDP réagit mal quand l’underlay perd ou réordonne des paquets.

Évitez de « tuner » tant que vous ne savez pas lequel vous avez. Le tuning aveugle produit une configuration qui ne marche que le mardi.

Voici la lentille opérationnelle : commencez par un flux unique reproductible (iperf3 convient). Confirmez si le goulot est l’hôte local,
l’hôte distant ou le chemin. Puis appliquez le plus petit changement qui déplace l’aiguille, et mesurez à nouveau.

Une citation à garder sur un post‑it : « L’espoir n’est pas une stratégie. » — Gene Kranz.

Blague n°1 : Si vous changez les valeurs MTU au hasard, vous ne tunez pas un VPN — vous faites de la numérologie avec des étapes en plus.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : prouver s’il s’agit de MTU/fragmentation

Exécutez un test PMTU type ping (ne devinez pas). Si les pings DF de grande taille échouent, vous avez un trou noir ou un décalage.
Vérifiez les compteurs pour fragmentation nécessaire / ICMP bloqué.
Si le PMTU est cassé, arrêtez et corrigez le MTU ou le clamp MSS avant de toucher autre chose.

Deuxième : prouver s’il s’agit d’un CPU

Exécutez iperf3 sur le tunnel en surveillant l’utilisation par cœur et la charge softirq.
Si un cœur est saturé (ou si ksoftirqd devient fou), vous êtes limité par le CPU/interruptions.
Corrigez en activant un chemin de chiffrement plus rapide (généralement déjà bon), en améliorant la distribution NIC/IRQ, ou en répartissant les flux/peers/hôtes.

Troisième : prouver la justesse du routage et du chemin

Vérifiez la route vers la destination (et la sélection de l’adresse source) depuis l’hôte émetteur.
Recherchez le routage asymétrique : un sens utilise le tunnel, l’autre utilise le WAN.
Confirmez que NAT et règles de pare‑feu ne réécrivent pas ou ne limitent pas le UDP.

Si les trois semblent sains, traitez‑le comme perte/queue UDP

Mesurez pertes/retransmissions via les stats TCP et les compteurs d’interface.
Vérifiez qdisc, shaping, bufferbloat et la santé du lien underlay.
Ce n’est qu’ensuite que vous envisagez un tuning avancé (buffers de socket, fq, pacing).

Faits et contexte intéressants (pourquoi ces problèmes existent)

WireGuard est entré dans le noyau Linux en 2020, ce qui a rendu les performances et le déploiement beaucoup plus prévisibles que les modules hors arbre.
Il repose sur UDP par conception, en partie pour éviter le meltdown TCP‑over‑TCP et en partie pour une traversée NAT plus simple — mais il hérite de la réalité « best effort » d’UDP.
Sa cryptographie utilise ChaCha20‑Poly1305, choisie pour de bonnes performances sur les systèmes sans accélération AES ; sur beaucoup de CPU c’est extrêmement rapide.
La découverte du Path MTU est fragile depuis des décennies parce qu’elle dépend des messages ICMP « fragmentation needed » que les pare‑feu aiment bloquer.
Le MTU classique Ethernet de 1500 est un artefact historique, pas une loi de la physique ; les tunnels ajoutent des en‑têtes et font de 1500 un piège.
Les offloads Linux (GSO/GRO/TSO) peuvent faire paraître les captures comme « incorrectes » et peuvent aussi cacher des problèmes de performance jusqu’à ce qu’un pilote change de comportement.
Les peers WireGuard sont identifiés par clés publiques, pas par IP ; les erreurs de routage se manifestent souvent par « ça se connecte mais c’est lent » quand le trafic correspond aux mauvaises AllowedIPs.
Les réseaux cloud encapsulent souvent déjà vos paquets (VXLAN/Geneve), donc votre tunnel est un tunnel dans un tunnel — MTU tué par mille en‑têtes.
L’effondrement du débit TCP peut venir de faibles taux de perte sur des réseaux long‑fat ; la surcharge VPN est rarement l’ennemi principal comparé à la perte et au RTT.

Tâches pratiques : commandes, sorties, décisions

Ci‑dessous des tâches pratiques à exécuter sur des hôtes Linux (ou dans des VM Linux) pour trouver le goulot. Chaque tâche inclut : la commande, ce que signifie une sortie typique,
et la décision que vous devez prendre ensuite. Faites‑les dans l’ordre si vous voulez de la vitesse sans superstition.

Task 1: Confirm you’re actually testing over WireGuard

cr0x@server:~$ ip route get 10.60.0.10
10.60.0.10 dev wg0 src 10.60.0.1 uid 1000
    cache

Sens : Le trafic vers 10.60.0.10 sort par wg0 avec la source 10.60.0.1.
Décision : Si vous ne voyez pas dev wg0, arrêtez. Corrigez le routage/AllowedIPs/le routage par politique d’abord ou vos tests seront faux.

Task 2: Inspect WireGuard peer health and whether you’re roaming endpoints

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 2r4...redacted...Kk=
  listening port: 51820

peer: q0D...redacted...xw=
  endpoint: 203.0.113.44:51820
  allowed ips: 10.60.0.10/32, 10.20.0.0/16
  latest handshake: 28 seconds ago
  transfer: 18.42 GiB received, 25.11 GiB sent
  persistent keepalive: every 25 seconds

Sens : Le handshake est récent ; l’endpoint est stable ; les compteurs de trafic évoluent.
Décision : Si latest handshake est ancien ou si l’endpoint change sans raison, suspectez des timeouts NAT, du roaming ou des problèmes d’état de pare‑feu — attendez des pertes et du jitter.

Task 3: Baseline the underlay (non-VPN) throughput and latency

cr0x@server:~$ ping -c 5 203.0.113.44
PING 203.0.113.44 (203.0.113.44) 56(84) bytes of data.
64 bytes from 203.0.113.44: icmp_seq=1 ttl=53 time=19.8 ms
64 bytes from 203.0.113.44: icmp_seq=2 ttl=53 time=20.4 ms
64 bytes from 203.0.113.44: icmp_seq=3 ttl=53 time=19.9 ms
64 bytes from 203.0.113.44: icmp_seq=4 ttl=53 time=62.1 ms
64 bytes from 203.0.113.44: icmp_seq=5 ttl=53 time=20.2 ms

--- 203.0.113.44 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 19.8/28.5/62.1/16.8 ms

Sens : L’underlay présente des spikes RTT (62 ms). Le VPN amplifiera cela en douleur pour le débit TCP.
Décision : Si l’underlay a jitter/perte, n’attendez pas de miracles des tweaks MTU ; vous aurez peut‑être besoin de gestion de file ou d’un meilleur chemin/fournisseur.

Task 4: Measure tunnel throughput with iperf3 (single flow)

cr0x@server:~$ iperf3 -c 10.60.0.10 -t 15
Connecting to host 10.60.0.10, port 5201
[  5] local 10.60.0.1 port 43144 connected to 10.60.0.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-1.00   sec  62.2 MBytes   522 Mbits/sec    0
[  5]   1.00-2.00   sec  61.8 MBytes   518 Mbits/sec    1
[  5]   2.00-3.00   sec  44.9 MBytes   377 Mbits/sec   12
[  5]   3.00-4.00   sec  58.2 MBytes   488 Mbits/sec    3
[  5]  14.00-15.00 sec  60.1 MBytes   504 Mbits/sec    2
- - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.00  sec   848 MBytes   474 Mbits/sec   44  sender
[  5]   0.00-15.00  sec   846 MBytes   473 Mbits/sec        receiver

Sens : Le débit est instable et il y a des retransmissions.
Décision : Les retransmissions sur un VPN signifient généralement trou noir MTU, perte/jitter de l’underlay, ou problèmes de buffering/queue. Ensuite : tests MTU et compteurs de perte.

Task 5: Measure with multiple parallel flows (to detect single-core limits)

cr0x@server:~$ iperf3 -c 10.60.0.10 -P 8 -t 15
[SUM]   0.00-15.00  sec  3.62 GBytes  2.07 Gbits/sec  81  sender
[SUM]   0.00-15.00  sec  3.61 GBytes  2.07 Gbits/sec      receiver

Sens : Le parallélisme a amélioré significativement le débit.
Décision : Si -P 8 est bien plus rapide que le flux unique, vous pouvez être limité par le CPU par flux, ou TCP lutte avec perte/RTT. Vérifiez le CPU et le qdisc ensuite.

Task 6: Check MTU on wg0 and the underlay interface

cr0x@server:~$ ip link show wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

cr0x@server:~$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Sens : wg0 a par défaut 1420, typique pour un underlay IPv4 avec MTU 1500.
Décision : Si l’underlay MTU est plus petit que vous ne le pensez (overlay cloud, PPPoE, etc.), 1420 peut encore être trop élevé. Ne devinez pas — testez le PMTU.

Task 7: PMTU test with DF ping through the tunnel

cr0x@server:~$ ping -M do -s 1372 -c 3 10.60.0.10
PING 10.60.0.10 (10.60.0.10) 1372(1400) bytes of data.
1380 bytes from 10.60.0.10: icmp_seq=1 ttl=64 time=23.4 ms
1380 bytes from 10.60.0.10: icmp_seq=2 ttl=64 time=23.1 ms
1380 bytes from 10.60.0.10: icmp_seq=3 ttl=64 time=23.3 ms

--- 10.60.0.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Sens : Payload 1372 (1400 sur le lien pour ICMP) fonctionne. Bon signe.
Décision : Augmentez jusqu’à ce que ça échoue ; le point d’échec indique le vrai PMTU. Si ça échoue de manière inattendue à une taille faible, vous avez probablement une encapsulation supplémentaire ou l’ICMP est bloqué.

cr0x@server:~$ ping -M do -s 1412 -c 3 10.60.0.10
PING 10.60.0.10 (10.60.0.10) 1412(1440) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 10.60.0.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2038ms

Sens : Votre MTU local wg0 vous bloque à 1420 — ce n’est pas encore un test de chemin, c’est une contrainte d’interface.
Décision : Si le PMTU réel du chemin est inférieur au MTU de wg0, vous verrez des échecs à des tailles plus petites aussi (ou des blocages bizarres). Continuez en testant près du MTU de wg0 et en surveillant la perte/retransmissions.

Task 8: Check whether ICMP “frag needed” is being received (PMTU working)

cr0x@server:~$ sudo ip -s -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9012345678 8123456      0    1452       0  120345
    TX:  bytes packets errors dropped carrier collsns
    8123456789 7012345      0       0       0       0

Sens : Il y a des drops RX (1452). Cela peut être congestion, overflow des anneaux, ou policing en amont.
Décision : Si les drops augmentent pendant iperf, traitez‑les comme une pression sur la voie de réception de l’underlay ou de l’hôte. Examinez les anneaux NIC/interrupts/qdisc et le shaping en amont.

Task 9: Observe TCP health (retransmits, congestion) during a transfer

cr0x@server:~$ ss -ti dst 10.60.0.10
ESTAB 0 0 10.60.0.1:43144 10.60.0.10:5201
	 cubic wscale:7,7 rto:204 rtt:24.1/2.1 ato:40 mss:1360 pmtu:1420 rcvmss:1360 advmss:1360 cwnd:64 bytes_acked:8123456 segs_out:6021 segs_in:5844 send 1.9Gbps lastsnd:8 lastrcv:8 lastack:8 pacing_rate 3.8Gbps delivery_rate 1.7Gbps retrans:12/44

Sens : MSS 1360, PMTU 1420. Il y a des retransmissions.
Décision : Retrans + PMTU stable suggèrent perte/jitter/queueing, pas seulement mismatch MTU. Si MSS/PMTU semblent incorrects (trop hauts), corrigez le MTU / MSS clamp en premier.

Task 10: Check CPU saturation and softirq during load

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server) 	12/27/2025 	_x86_64_	(8 CPU)

12:10:01 AM  CPU   %usr %nice  %sys %iowait  %irq %soft  %steal  %idle
12:10:02 AM  all   22.1  0.0   18.4   0.0    0.0  20.9    0.0   38.6
12:10:02 AM    0   12.0  0.0   10.1   0.0    0.0  62.3    0.0   15.6
12:10:02 AM    1   28.4  0.0   21.0   0.0    0.0   8.2    0.0   42.4
12:10:02 AM    2   30.1  0.0   25.7   0.0    0.0   5.9    0.0   38.3
12:10:02 AM    3   29.8  0.0   19.4   0.0    0.0   6.1    0.0   44.6
12:10:02 AM    4   18.0  0.0   15.2   0.0    0.0  28.0    0.0   38.8
12:10:02 AM    5   20.5  0.0   17.1   0.0    0.0  26.4    0.0   36.0
12:10:02 AM    6   19.7  0.0   15.9   0.0    0.0  25.1    0.0   39.3
12:10:02 AM    7   17.6  0.0   13.4   0.0    0.0  29.0    0.0   40.0

Sens : CPU0 est fortement chargé en %soft (softirq). C’est souvent le traitement réseau en réception et peut limiter le débit.
Décision : Si un CPU a un softirq dominant, vous devez probablement améliorer la distribution des IRQ (RSS/RPS), tuner les files NIC, ou déplacer la charge hors d’une petite VM.

Task 11: Check WireGuard and UDP socket buffer pressure

cr0x@server:~$ netstat -su
Udp:
    2212345 packets received
    0 packets to unknown port received
    0 packet receive errors
    1832 packets sent
    0 receive buffer errors
    412 send buffer errors
UdpLite:
IpExt:
    InNoRoutes: 0
    InBcastPkts: 0

Sens : send buffer errors suggère que l’hôte n’a pas pu mettre en file le UDP assez vite (ou que le qdisc/NIC est congestionné).
Décision : Examinez le qdisc, les files TX NIC, et augmentez éventuellement les buffers de socket (avec prudence, et en mesurant). Vérifiez aussi le policing en sortie.

Task 12: Check qdisc (queue discipline) and whether you’re using something sensible

cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn

Sens : fq_codel est généralement un bon défaut pour la latence et l’équité.
Décision : Si vous voyez pfifo_fast ou un énorme backlog fq ailleurs, envisagez de passer à fq_codel ou cake (si disponible) sur l’egress qui compte.

Task 13: Verify policy routing (common in split tunnel setups)

cr0x@server:~$ ip rule show
0:	from all lookup local
1000:	from 10.60.0.0/24 lookup 100
32766:	from all lookup main
32767:	from all lookup default

cr0x@server:~$ ip route show table 100
default dev wg0 scope link

Sens : Le trafic issu de 10.60.0.0/24 utilise la table 100 et par défaut va vers wg0.
Décision : Si les réponses n’utilisent pas la même politique, vous aurez de l’asymétrie, des blocages bizarres, et « seules certaines applis sont lentes ». Corrigez les règles pour que les deux sens soient cohérents.

Task 14: Look for conntrack/NAT issues that punish UDP

cr0x@server:~$ sudo conntrack -S
cpu=0 found=912345 invalid=12 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=120
cpu=1 found=901234 invalid=8 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=98

Sens : invalid existe mais n’est pas fou ; search_restart peut indiquer une pression sur la table.
Décision : Si invalid monte rapidement sous charge VPN, vérifiez les règles NAT, les timeouts UDP, et si des middleboxes réécrivent ou expirent l’état trop agressivement.

Task 15: Verify offloads and whether the NIC driver is doing something “creative”

cr0x@server:~$ sudo ethtool -k eth0 | egrep 'gro|gso|tso|tx-checksum|rx-checksum'
rx-checksumming: on
tx-checksumming: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Sens : Les offloads sont activés. En général c’est bon. Parfois c’est désastreux avec certaines NIC virtuelles ou pilotes bogués.
Décision : Si vous observez un CPU élevé, un comportement étrange des captures, ou un effondrement du débit du tunnel après une mise à jour noyau/pilote, testez la désactivation de GRO sur wg0 ou sur l’underlay en expérience contrôlée — puis revenez en arrière si ça n’aide pas.

Task 16: Capture evidence without lying to yourself (tcpdump with clarity)

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:12:01.123456 IP 198.51.100.10.51820 > 203.0.113.44.51820: UDP, length 148
01:12:01.143211 IP 203.0.113.44.51820 > 198.51.100.10.51820: UDP, length 92
01:12:01.163001 IP 198.51.100.10.51820 > 203.0.113.44.51820: UDP, length 1200
01:12:01.182992 IP 198.51.100.10.51820 > 203.0.113.44.51820: UDP, length 1200
01:12:01.203114 IP 203.0.113.44.51820 > 198.51.100.10.51820: UDP, length 92
5 packets captured

Sens : Vous voyez du trafic UDP bidirectionnel sur le port WireGuard. Bien.
Décision : Si le trafic est unidirectionnel, les problèmes de performance sont secondaires — vous avez une défaillance de chemin/pare‑feu/NAT dans un sens.

MTU et fragmentation : le mensonge le plus courant « tout va bien »

Quand WireGuard est lent, le MTU est souvent coupable au point qu’il faut le suspecter par défaut — mais pas le corriger par défaut. L’approche correcte est :
déterminer le path MTU effectif, puis définir le MTU de wg0 (ou clamping MSS) pour que votre trafic ne dépende jamais de la livraison fiable de paquets fragmentés.

Ce qui se passe réellement

WireGuard encapsule vos paquets dans UDP. Cela ajoute des en‑têtes. Si votre paquet interne est dimensionné pour un chemin de 1500 octets, le paquet externe peut
dépasser 1500 et soit :

être fragmenté (meilleur cas : les fragments arrivent ; pire cas : les fragments sont perdus), ou
être rejeté avec un ICMP « fragmentation needed » (si PMTUD fonctionne), ou
être silencieusement supprimé (trou noir PMTUD, le classique).

Les motifs d’échec sont distinctifs :

Les petits paquets OK, les gros échouent : SSH fonctionne, copie de fichiers se fige, pages web chargent partiellement.
Débits en dents de scie : TCP monte, atteint un mur, s’effondre, recommence.
« Ça se répare » sur d’autres réseaux : car le PMTU varie selon les chemins et les politiques de filtrage ICMP.

Ne vénérez pas 1420

1420 est un défaut raisonnable pour un underlay IPv4 avec MTU 1500. Mais :

Si vous exécutez WireGuard sur un underlay IPv6, l’overhead diffère.
Si votre lien « 1500 MTU » est en réalité un overlay (SDN cloud) ou PPPoE, vous avez moins.
S’il y a IPSec, GRE, VXLAN, ou des middleboxes « utiles », vous avez moins.

Deux stratégies solides

Définir le MTU de wg0 à une valeur sûre connue.
Cela affecte tout le trafic, y compris les applications UDP. C’est brutal mais fiable.
Clamper le MSS TCP à l’ingress/egress du tunnel.
Cela n’affecte que TCP et peut préserver un MTU plus grand pour les flux UDP qui tolèrent la fragmentation (ou n’envoient pas de gros payloads).

Flux de travail MTU pratique et défendable

Exécutez des pings DF vers l’IP lointaine du tunnel (Task 7), trouvez la plus grande charge utile qui passe de manière fiable.
Soustrayez l’overhead correct si vous testez différentes couches (soyez cohérent).
Réglez le MTU de wg0 sur une valeur qui laisse de la marge, pas une valeur qui « passe à peine les bons jours ».
Relancez iperf3 et comparez les retransmissions et la stabilité, pas seulement le débit maximal.

Exemple : définir le MTU en toute sécurité

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380
cr0x@server:~$ ip link show wg0
7: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Sens : Le MTU de wg0 est maintenant 1380.
Décision : Si les performances se stabilisent (moins de retransmissions, débit plus cohérent), conservez‑le et documentez la base PMTU mesurée. Si rien ne change, le MTU n’était pas votre goulot principal.

Exemple : clamp MSS (iptables)

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 2
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j TCPMSS --clamp-mss-to-pmtu

Sens : Les paquets SYN TCP sortant par wg0 auront le MSS clampé.
Décision : Utilisez ceci quand vous ne pouvez pas contrôler le MTU de bout en bout (multi‑peers, clients en roaming), ou quand vous voyez seulement des problèmes TCP. Validez avec ss -ti que MSS/PMTU correspondent.

Routage et routage par politique : quand les paquets prennent la route touristique

Les erreurs de routage ne cassent pas toujours la connectivité. Elles la dégradent de façons qui ressemblent à « VPN lent » alors que la cause est « les paquets font du tourisme ». On voit ça surtout dans les configurations split‑tunnel, serveurs multi‑homés, et environnements avec des routes par défaut changeantes (bonjour les laptops).

AllowedIPs est du routage, pas du contrôle d’accès

Le champ AllowedIPs de WireGuard est malin et multi‑usage : il indique au noyau quelles destinations doivent être routées vers ce peer, et il
agit aussi comme une table de routage par clé crypto. L’essentiel : si vous le définissez mal, le trafic peut être envoyé au mauvais peer, ou ne pas être envoyé
dans le tunnel du tout, ou être envoyé avec la mauvaise adresse source.

Routage asymétrique : le tueur silencieux du débit

Votre trafic sortant peut traverser WireGuard, mais les réponses peuvent revenir via l’underlay, ou via un autre tunnel, ou via un chemin NAT qui casse l’état. TCP déteste l’asymétrie. UDP aussi, il est juste moins bruyant.

Comment attraper vite les mensonges du routage

Utilisez ip route get pour la destination depuis l’émetteur (Task 1).
Utilisez ip rule et ip route show table X quand le routage par politique est en jeu (Task 13).
Vérifiez le reverse path filtering (rp_filter) si vous avez plusieurs interfaces et du routage par politique.

Reverse path filtering : « fonctionnalité de sécurité » devenue bug de disponibilité

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter net.ipv4.conf.wg0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.wg0.rp_filter = 0

Sens : rp_filter strict est activé globalement et sur eth0. Dans des configs de routage par politique, cela peut laisser tomber des réponses asymétriques légitimes.
Décision : Si vous observez des drops inexpliqués et de l’asymétrie, mettez rp_filter à 2 (loose) sur les interfaces concernées ou désactivez‑le où approprié — puis vérifiez avec les compteurs de paquets.

cr0x@server:~$ sudo sysctl -w net.ipv4.conf.all.rp_filter=2
net.ipv4.conf.all.rp_filter = 2

Sens : Mode loose. Fournit quand même quelques vérifications sans casser le routage par politique.
Décision : Rendre persistent seulement après avoir confirmé que cela résout le problème et que cela n’enfreint pas votre modèle de menace.

CPU et crypto : quand votre nombre de cœurs limite le débit

WireGuard est rapide. Mais « rapide » n’est pas « gratuit », et l’underlay peut être assez rapide pour exposer le CPU comme plafond. Sur de petites instances cloud, de vieux Xeon, des hyperviseurs occupés, ou des hôtes faisant beaucoup de travail conntrack/pare‑feu, vous pouvez absolument bloquer un cœur et arrêter l’extensibilité.

À quoi ressemble un goulot CPU

iperf3 plafonne à un bitrate stable, indépendamment de la capacité du lien.
Un cœur est coincé en %soft ou %sys tandis que les autres sont en grande partie inactifs.
Les flux iperf3 parallèles augmentent le débit plus que prévu.
Le temps système augmente avec le taux de paquets, pas avec les octets transférés.

Distinguer le coût crypto du coût de traitement des paquets

On aime blâmer la crypto parce que ça sonne sophistiqué. Souvent, le vrai problème est le coût de traitement des paquets : interruptions, softirq, comportement GRO/GSO,
conntrack, et qdisc. La crypto WireGuard est efficace ; le chemin réseau de votre hôte peut ne pas l’être.

Vérifiez le temps noyau et le softirq

cr0x@server:~$ top -b -n 1 | head -n 15
top - 01:20:11 up 16 days,  3:12,  1 user,  load average: 3.21, 2.88, 2.44
Tasks: 213 total,   2 running, 211 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.2 us,  0.0 ni, 27.6 sy,  0.0 id,  0.0 wa,  0.0 hi, 54.2 si,  0.0 st
MiB Mem :  16000.0 total,   2200.0 free,   4100.0 used,   9700.0 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  11200.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  934 root      20   0       0      0      0 S  62.0   0.0  31:22.11 ksoftirqd/0
 2112 root      20   0       0      0      0 S  18.0   0.0  12:04.22 ksoftirqd/4

Sens : Les threads softirq consomment du CPU. C’est le traitement réseau.
Décision : Examinez l’affinité IRQ, le nombre de queues NIC, RPS/XPS, et si votre VM est bridé ou affectée par un noisy neighbor.

Distribution des interruptions et mise en file

cr0x@server:~$ grep -E 'eth0|wg0' /proc/interrupts | head
  24:  8123456        0        0        0        0        0        0        0   PCI-MSI 327680-edge      virtio0-input.0
  25:        0  7012345        0        0        0        0        0        0   PCI-MSI 327681-edge      virtio0-output.0

Sens : Les interruptions sont concentrées sur certains CPU.
Décision : Si la plupart des interruptions arrivent sur un CPU, configurez l’affinité IRQ et assurez‑vous que le multi‑queue est activé. L’objectif : répartir le traitement des paquets sur les cœurs sans causer de chaos cache.

Réalité de l’accélération crypto

ChaCha20 de WireGuard performe bien sur beaucoup de CPU, y compris ceux sans AES‑NI. Mais l’histoire de performance change avec :

Des débits très élevés en nombre de paquets (petits paquets) : overhead dominé par le coût par paquet.
Des VMs avec peu de vCPU et un mauvais tuning virtio.
Des pare‑feu lourds faisant beaucoup de conntrack sur le même hôte.

Si votre plafond est le CPU : augmentez l’instance, déchargez le firewalling, ou terminez le tunnel sur une machine conçue pour pousser des paquets. La « solution » consiste parfois à acheter une VM plus grande. Ce n’est pas honteux ; c’est moins cher que du temps ingénieur.

Offloads NIC, bizarreries de checksum et la taxe VM

WireGuard vit dans le noyau, ce qui est bien. Mais il dépend toujours des pilotes NIC et de la pile réseau Linux. Les offloads (GRO/GSO/TSO) améliorent généralement le débit et réduisent le CPU. Parfois ils interagissent mal avec les tunnels, les NIC virtuelles ou les filtres de paquets.

Syndromes qui sentent l’offload

Les captures montrent des paquets « géants » qui n’existent pas sur le fil.
Les performances changent radicalement après une mise à jour du noyau, sans changement de config.
Le débit est correct dans un sens mais affreux dans l’autre.
CPU softirq élevé plus des drops inexpliqués sur l’hôte.

Expérience contrôlée : désactiver GRO sur `wg0`

cr0x@server:~$ sudo ethtool -K wg0 gro off
Cannot get device settings: Operation not supported

Sens : L’interface WireGuard ne supporte pas les toggles ethtool standards de la même manière qu’une NIC physique.
Décision : Utilisez des sysctls et concentrez‑vous sur les offloads de l’underlay. Pour WireGuard lui‑même, focalisez‑vous sur MTU, routage et comportement CPU/IRQ de l’hôte.

Plus pertinent : toggles d’offload de l’underlay (tester, ne pas commettre aveuglément)

cr0x@server:~$ sudo ethtool -K eth0 gro off gso off tso off
cr0x@server:~$ sudo ethtool -k eth0 | egrep 'gro|gso|tso'
tcp-segmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off

Sens : Les offloads sont désactivés. L’utilisation CPU va augmenter ; le taux de paquets va monter.
Décision : Si désactiver les offloads corrige la stabilité du débit du tunnel (rare, mais réel), vous avez probablement un problème de pilote/virtualisation. Conservez le workaround à court terme ; planifiez une correction noyau/driver/hyperviseur.

La taxe VM

Sur beaucoup d’hyperviseurs, un endpoint VPN dans une VM paie un surcoût :

Les drivers virtio/netfront et le vSwitch ajoutent latence et coût CPU.
L’agrégation d’interruptions et l’ordonnancement des vCPU peuvent créer des livraisons en rafales.
Les fournisseurs cloud peuvent limiter/mesurer l’UDP ou le déprioriser sous congestion.

Si vous essayez de pousser plusieurs gigabits à travers une petite VM, elle ne deviendra pas grosse par pensée positive.

Réalités UDP : pertes, jitter, buffers et shaping

WireGuard utilise UDP. C’est une fonctionnalité, mais cela signifie que vous héritez du comportement de l’underlay sans couche de retransmission intégrée. Si l’underlay
perd ou réordonne, le tunnel ne « répare » pas ça. TCP à l’intérieur du tunnel le remarquera et vous punira avec des fenêtres de congestion réduites et des retransmissions.

Que mesurer quand « c’est juste parfois lent »

Pertes : drops d’interface, erreurs UDP, retransmissions TCP.
Jitter : variance de ping et timings applicatifs.
Queueing : stats qdisc, symptômes de bufferbloat (pics de latence sous charge).
Policing : shaping egress cloud ou rate limits de middleboxes (souvent sévères sur les rafales UDP).

Vérifier les stats qdisc pour drops/overlimits

cr0x@server:~$ tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
 Sent 912345678 bytes 701234 packets (dropped 123, overlimits 0 requeues 12)
 backlog 0b 0p requeues 12

Sens : Des drops sont survenus au niveau du qdisc. C’est de la congestion locale ou du shaping.
Décision : Si les drops corrèlent avec les ralentissements, traitez l’egress queueing : assurez‑vous d’avoir fq_codel/cake, réduisez la charge offerte, ou corrigez le shaping amont au lieu de blâmer WireGuard.

Buffers de socket : seulement après avoir vu des erreurs de buffer

On aime tous monter rmem_max et wmem_max. Parfois ça aide ; souvent ça augmente seulement la latence et l’usage mémoire pendant que le vrai problème est l’uplink congestionné.

cr0x@server:~$ sysctl net.core.rmem_max net.core.wmem_max
net.core.rmem_max = 212992
net.core.wmem_max = 212992

Sens : Buffers max par défaut.
Décision : N’augmentez que si vous avez des preuves d’erreurs de buffer (netstat -su) et que vous savez où la mise en file va se déplacer. Mesurez après chaque changement.

cr0x@server:~$ sudo sysctl -w net.core.rmem_max=8388608
net.core.rmem_max = 8388608
cr0x@server:~$ sudo sysctl -w net.core.wmem_max=8388608
net.core.wmem_max = 8388608

Sens : Autorise des buffers max plus grands.
Décision : Relancez iperf3 et vérifiez netstat -su. Si les erreurs chutent et le débit se stabilise sans explosion de latence, conservez ; sinon revenez en arrière et regardez la congestion de l’underlay.

Blague n°2 : UDP, c’est comme le commérage de bureau — rapide, léger, et si quelque chose se perd, personne ne revient corriger le récit.

Trois mini‑histoires d’entreprise venues du terrain

Incident causé par une fausse hypothèse : « MTU est toujours 1500 dans le cloud »

Une entreprise moyenne exploitait une flotte de gateways WireGuard dans un grand fournisseur cloud. En staging, tout semblait bien. En production, chaque dump
de base de données nocturne via le tunnel se « bloquait parfois ». Pas d’échec — un blocage. Les opérateurs voyaient la progression se figer pendant des minutes puis reprendre.

La première réaction fut prévisible : blâmer la base de données, puis l’outil de backup, puis le stockage. Quelqu’un a suggéré « peut‑être WireGuard est lent ».
Ils ont baissé le MTU à 1280 parce qu’ils l’avaient vu sur un blog. Ça a légèrement amélioré, puis régresser la semaine suivante après un changement de chemin réseau cloud.

L’erreur était de supposer que l’underlay était un Ethernet simple à 1500 octets. Ce n’était pas le cas. L’overlay du fournisseur ajoutait de l’encapsulation,
et le PMTU effectif différait entre zones de disponibilité. Le PMTUD aurait dû gérer ça, mais les messages ICMP « frag needed » étaient filtrés par un appliance de sécurité qui avait été installé « temporairement » puis devenu permanent — comme beaucoup de choses en entreprise.

La correction fut ennuyeuse : autoriser les types ICMP pertinents, définir le MTU de wg0 basé sur le PMTU mesuré pour le pire chemin, et clamper MSS par sécurité. Les backups nocturnes devinrent stables, et l’équipe a arrêté de réveiller les ingénieurs stockage pour un problème réseau déguisé en problème stockage.

La leçon : si vous n’avez pas mesuré le PMTU bout‑à‑bout, vous n’avez pas un MTU. Vous avez un système de croyances.

Une optimisation qui a échoué : « Désactiver le qdisc pour réduire l’overhead »

Une équipe plateforme interne voulait le maximum de débit entre deux datacenters. Ils ont lu que les disciplines de queue ajoutent de l’overhead et ont décidé de « simplifier » en passant l’egress à un FIFO basique et en gonflant les buffers. Les graphes aimaient ça au début : débit pic plus élevé en labo.

Puis la production est arrivée. En journée, un gros transfert provoquait des pics de latence sur des services sans rapport. Le tunnel était partagé par plusieurs applis, et la file FIFO s’est transformée en canon à latence. Les timeouts RPC ont monté. Les retries ont augmenté la charge. La tempête auto‑infligée classique.

Les ingénieurs ont essayé de blâmer WireGuard. Mais la perte de paquets n’était pas le problème principal ; c’était la mise en file (queueing) et la latence. Le VPN n’était que le lieu de convergence du trafic, donc il a été blâmé comme la seule personne portant une chemise voyante.

Le rollback vers fq_codel a stabilisé la latence et amélioré le débit effectif pour les flux interactifs. Le débit pic du gros transfert a légèrement baissé. Personne ne s’en est soucié, car l’entreprise se souciait que « les systèmes restent disponibles », pas qu’un benchmark ait l’air joli.

La leçon : si vous optimisez le débit sans contrôler la mise en file, vous construisez un mécanisme de déni de service et appelez ça de la performance.

Une pratique ennuyeuse mais correcte qui a sauvé la mise : « Mesurer, enregistrer et retester après chaque changement »

Une société avec un contrôle de changement strict exploitait WireGuard entre on‑prem et cloud. Ils avaient une plainte récurrente : « le VPN est lent ». Au lieu de sauter sur le tuning, un SRE a écrit un petit runbook : un test iperf3, un test MTU, une vérification du routage, une vérification CPU. Les résultats allaient dans un ticket.

En quelques semaines, des motifs sont apparus. Les ralentissements coïncidaient avec un chemin de peering ISP spécifique et un jitter underlay augmenté. Un autre sous‑ensemble d’incidents corrélait avec une taille de VM particulière utilisée pour la gateway : le steal CPU était élevé aux heures de pointe.

Quand un ralentissement majeur a frappé pendant une release, l’équipe n’a pas argumenté. Ils ont exécuté les mêmes tests. Le ping underlay montrait du jitter. iperf3 montrait des retransmissions. Le CPU était OK. Le routage était correct. Cela a éliminé la moitié des spéculations habituelles en cinq minutes.

Ils ont temporairement rerouté le trafic via une autre gateway sur un meilleur chemin et déposé une escalation ISP avec des preuves propres. Le VPN n’a pas été « fixé » par un sysctl magique. Il a été fixé en sachant où se trouvait le problème.

La leçon : la discipline de mesure ennuyeuse est un multiplicateur de force. Ce n’est pas héroïque, mais ça empêche des suppositions coûteuses.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: SSH works, large downloads stall or hang

Cause racine : trou noir PMTU ou mismatch MTU ; fragmentation supprimée ; ICMP bloqué.

Correction : Mesurez le PMTU avec des pings DF ; baissez le MTU de wg0 ; clamp MSS TCP ; autorisez ICMP « frag needed » sur le chemin.

2) Symptom: Throughput is fine with iperf3 -P 8 but bad with single flow

Cause racine : Le flux unique TCP est limité par le RTT/la perte ou le CPU par flux ; la fenêtre de congestion ne peut pas croître.

Correction : Vérifiez les retransmissions et le jitter ; corrigez MTU/pertes d’abord ; si limité par le CPU, améliorez la distribution IRQ ou scalez la gateway.

3) Symptom: Tunnel is slow only from one site / one ASN / one Wi‑Fi

Cause racine : chemin underlay avec perte/jitter ou shaping du fournisseur ; parfois UDP mal traité.

Correction : Baseline ping/jitter de l’underlay ; comparez depuis plusieurs réseaux ; envisagez de changer le port d’endpoint, mais seulement après avoir vérifié MTU et routage.

4) Symptom: Fast for minutes, then collapses, then recovers

Cause racine : queueing/bufferbloat, ou pertes transitoires ; parfois basculement d’état NAT sans keepalive.

Correction : Utilisez fq_codel/cake sur l’egress ; surveillez les drops qdisc ; définissez PersistentKeepalive pour les peers en roaming/NATés ; vérifiez conntrack.

5) Symptom: One direction is much slower than the other

Cause racine : routage asymétrique, policing egress, ou comportement MTU/PMTU différent sur chaque chemin.

Correction : Exécutez les vérifications de routage sur les deux bouts ; vérifiez le routage par politique et rp_filter ; comparez les stats qdisc et les drops d’interface par direction.

6) Symptom: Performance got worse after kernel/driver/hypervisor update

Cause racine : comportement d’offload changé ; régression du pilote virtio ou NIC ; modulation d’interruption différente.

Correction : Testez les toggles d’offload en contournement temporaire ; ajustez l’affinité IRQ ; planifiez une mise à jour/rollback avec preuves.

7) Symptom: “WireGuard is slow” only on a gateway that also does firewalling

Cause racine : conntrack et règles iptables/nft ajoutent du coût CPU ; pression softirq ; contention sur les tables.

Correction : Réduisez le conntrack pour le trafic du tunnel où c’est sûr, simplifiez les règles, augmentez le CPU, ou séparez les rôles (VPN endpoint vs pare‑feu stateful).

8) Symptom: Latency spikes under load, even when throughput is acceptable

Cause racine : mauvais qdisc (FIFO), buffers trop grands, ou shaping sans AQM.

Correction : Utilisez fq_codel/cake ; évitez « juste augmenter les buffers » ; mesurez le ping sous charge.

Checklists / plan étape par étape (sûr, ennuyeux, efficace)

Checklist A: One-hour diagnosis on a production incident

Confirmer le routage : ip route get vers l’IP distante du tunnel. Si ce n’est pas wg0, corrigez AllowedIPs / routage par politique d’abord.
Confirmer la santé du tunnel : wg show pour la fraîcheur des handshakes et l’évolution des compteurs.
Exécuter iperf3 : flux unique et -P 8. Notez retransmissions et stabilité.
Test MTU : pings DF vers l’IP peer ; cherchez des trous noirs.
Vérification CPU/softirq : mpstat / top. Si un cœur est pincé, considérez la limite hôte.
Pertes et queueing : ip -s link drops ; tc -s qdisc drops/overlimits.
Sanity NAT/conntrack : stats conntrack, compteurs pare‑feu si disponibles.
Décision : correction MTU/MSS, correction routage, monter le CPU de la gateway, ou escalade du fournisseur underlay avec preuves.

Checklist B: Hardening a WireGuard deployment for predictable performance

Choisir une stratégie MTU cible : définir le MTU de wg0 basé sur le PMTU mesuré pire cas, et/ou clamper MSS pour TCP.
Standardiser le qdisc : fq_codel sur l’egress WAN ; éviter FIFO sauf si vous aimez les incidents de latence.
Planifier la capacité CPU : benchmark iperf3 et mesurer softirq par cœur avant de déclarer « c’est ok ».
Documenter l’intention de routage : AllowedIPs, règles politiques, routage basé sur la source ; inclure la raison dans les commentaires de config.
Décider de la politique keepalive : les clients en roaming et les chemins NATés ont besoin de PersistentKeepalive ; les serveurs sur liens stables souvent pas.
Instrumenter : exporter drops d’interface, drops qdisc, softirq CPU, et âge des handshakes ; alerter sur des tendances, pas sur des spikes isolés.

Checklist C: Change plan for a suspected MTU issue (with rollback)

Mesurez la baseline iperf3 et les retransmits via ss -ti.
Mesurez le payload maximal DF ping qui passe de manière fiable.
Baissez le MTU de wg0 d’un petit pas justifié (ex. 20–40 octets) ou implémentez le MSS clamp.
Re‑testez iperf3 et observez le changement des retransmits.
Revenez en arrière si aucune amélioration ; le MTU n’était pas le goulot.
Notez le PMTU mesuré et la valeur choisie pour éviter que quelqu’un « optimise » plus tard.

FAQ

1) Quel débit devrais‑je attendre de WireGuard ?

Sur du matériel moderne, WireGuard peut atteindre le multi‑gigabit. En pratique, votre plafond est souvent le CPU, le comportement NIC/driver, et la perte/jitter de l’underlay.
Mesurez avec iperf3 et surveillez le softirq par cœur.

2) 1420 est‑il toujours le bon MTU pour `wg0` ?

Non. C’est un défaut raisonnable pour un underlay IPv4 à 1500. Les overlays cloud, PPPoE et tunnels imbriqués peuvent exiger des MTU plus faibles. Mesurez le PMTU et définissez le MTU sur des preuves.

3) Dois‑je utiliser le clamp MSS ou définir le MTU ?

Si le problème est surtout TCP et que vous avez des clients/chemins divers, le clamp MSS est souvent la correction la moins perturbatrice. Si vous transportez beaucoup d’UDP (VoIP, jeux, workloads QUIC) et que le PMTU est peu fiable, définir le MTU de wg0 sur une valeur sûre est plus propre.

4) Pourquoi iperf3 -P 8 a l’air super mais le flux unique est médiocre ?

Les flux parallèles cachent les limites du flux unique (RTT, sensibilité à la perte, comportement du contrôle de congestion) et peuvent répartir le coût CPU. Si votre trafic métier est mono‑flux (sauvegardes, téléchargements d’objets), optimisez pour cela : corrigez perte/MTU et réduisez le queueing.

5) Les règles de pare‑feu peuvent‑elles rendre WireGuard lent ?

Absolument. Le filtrage stateful et conntrack ajoutent du coût CPU et peuvent dropper des paquets sous charge. De plus, les pare‑feu qui bloquent ICMP « frag needed » peuvent casser la PMTUD et causer le classique « petits paquets OK, gros paquets meurent ».

6) WireGuard est‑il plus lent qu’OpenVPN ?

Souvent il est plus rapide, surtout en mode noyau. Mais si votre goulot est un trou noir MTU, une asymétrie de routage, ou une perte underlay, changer de VPN ne résoudra pas la physique ni la politique. Diagnostiquez d’abord.

7) Changer le port WireGuard aide‑t‑il les performances ?

Parfois, mais ce n’est pas un remède de première ligne. Changer de port peut contourner des rate limits stupides ou des middleboxes défaillants. Faites les vérifs MTU/routage/CPU d’abord pour ne pas « réparer » le mauvais problème par accident.

8) Pourquoi WireGuard est‑il lent seulement sur un réseau de laptop ?

Probablement PMTU/filtrage ICMP sur ce réseau, ou shaping/perte UDP sur ce chemin. Les clients en roaming derrière NAT peuvent aussi souffrir si PersistentKeepalive n’est pas défini. Comparez les pings DF et observez la stabilité des handshakes.

9) Dois‑je augmenter les buffers de socket Linux pour WireGuard ?

Seulement si vous voyez des preuves comme des erreurs de buffer UDP. Des buffers plus grands peuvent augmenter la latence et masquer la congestion. Corrigez le queueing et la perte d’abord ; tunez les buffers ensuite.

Étapes suivantes que vous pouvez exécuter cette semaine

Choisissez un test reproductible (iperf3 flux unique + -P 8) et enregistrez le débit de base, les retransmissions et le CPU.
Exécutez des tests PMTU DF ping à travers le tunnel et décidez du MTU ou du clamp MSS basé sur la plus grande taille fiable, pas sur des impressions.
Validez le routage de façon déterministe avec ip route get et ip rule sur les deux extrémités ; chassez l’asymétrie.
Surveillez le softirq pendant la charge ; si un cœur est pincé, corrigez la distribution IRQ ou montez la capacité de l’endpoint VPN.
Vérifiez les drops qdisc et passez à fq_codel quand approprié ; arrêtez d’utiliser FIFO si la latence compte (et elle compte toujours).
Rédigez un runbook d’une page contenant les commandes exactes exécutées aujourd’hui et le « si la sortie ressemble à X, faites Y ».

WireGuard n’est pas « lent ». Votre chemin, votre MTU, votre routage, ou votre CPU est lent. La bonne nouvelle : ce sont des choses diagnostiquables avec une poignée de commandes et un refus de deviner.