Qui choisit la MTU de WireGuard : wg-quick, le noyau ou vous
WireGuard ne négocie aucune MTU. L’outil de configuration, un gestionnaire de réseau ou votre ligne de configuration décide, et la valeur par défaut est une supposition sur le chemin, pas une mesure.
WireGuard ne dispose d’aucune négociation de MTU. Il chiffre tout ce que l’interface lui remet et envoie le résultat, et si le paquet encapsulé dépasse le chemin, il est abandonné ou fragmenté quelque part que vous ne pouvez pas voir. Quelqu’un doit choisir la MTU de l’interface, et ce quelqu’un est l’outil qui a monté l’interface.
Il existe trois candidats, et ils sont faciles à confondre.
Trois endroits d’où la valeur peut venir
La valeur peut être définie explicitement dans la configuration de l’interface, calculée par l’outil de configuration à partir des informations de route, ou fixée par le gestionnaire de réseau qui possède l’interface. Un appel ordinaire à wg ne fait rien de tout cela, car wg ne gère que les clés et les pairs. La MTU vit sur l’interface réseau, et c’est pourquoi ip link show wg0 est l’endroit où vous la lisez.
Si vous ne savez pas quel cas s’applique, lisez d’abord la MTU, puis découvrez qui a démarré l’interface.
Décidez selon qui exploite l’interface
Si wg-quick la démarre, une ligne MTU explicite l’emporte, sinon il calcule une valeur. Si un gestionnaire de réseau la démarre, le profil de ce gestionnaire décide. Si un environnement d’exécution de conteneurs ou un client de fournisseur la démarre, lisez leur documentation au lieu de supposer le comportement de wg-quick.
La décision n’est pas quel nombre est le meilleur dans l’absolu. Elle est quel composant vous pouvez réellement configurer.
Ce que fait le calcul par défaut
wg-quick recherche la route vers le point de terminaison du pair, prend la MTU de cette interface sortante et soustrait la surcharge d’encapsulation. Avec un en-tête externe IPv4, cela fait environ 60 octets ; avec IPv6, environ 80. Le résultat est plafonné pour qu’un chemin de 1500 octets donne 1420 plutôt qu’une valeur qui ne fonctionne que sur une seule famille d’adresses. C’est une valeur par défaut raisonnable, pas une mesure de votre chemin.
Il ne peut rien savoir d’un tunnel ultérieur, d’une liaison mobile ou d’un chemin ICMP filtré.
Le plafond cache une vraie question. Si votre chemin fait réellement 9000 octets de bout en bout, 1420 laisse de la performance sur la table, et si le chemin fait 1400, 1420 est déjà trop grand. La valeur par défaut est un compromis, et elle doit être traitée comme tel.
Quand le chemin change sous vos pieds
Un portable qui passe de l’Ethernet au Wi-Fi puis au partage de connexion d’un téléphone conserve la MTU de l’interface avec laquelle il a démarré. Le chemin extérieur est peut-être désormais plus petit, et rien ne renégocie. Les tunnels imbriqués empirent les choses, car chaque couche soustrait sa propre surcharge du même budget. La valeur qui fonctionnait au bureau n’est pas celle qui fonctionne à l’aéroport.
Une poignée de main récente prouve que les clés fonctionnent. Elle ne prouve rien sur le fait que les gros paquets passent.
Testez un nombre à la fois
Gardez la même application et la même destination, changez une valeur et mesurez. ping -M do -s 1372 teste un paquet de 1400 octets avec le bit DF activé, et c’est la forme de test que vous voulez. Si les petites requêtes passent et que les grosses calent, vous avez un problème de taille et non de routage.
Ne changez que la MTU. Ajuster plusieurs options de paquet en même temps ne vous dit pas laquelle comptait.
Et n’attendez pas qu’un changement de MTU corrige une route de retour manquante, une règle de transfert ou une panne DNS. Ces problèmes produisent aussi des symptômes d’absence de trafic, et ils ont leurs propres tests. Le manuel de wg-quick documente la sélection automatique.