WireGuard se bloque : une limite MTU ou une règle de transfert manquante ?

L’habitude est de baisser le MTU dès que WireGuard se comporte mal, et cette habitude masque un autre défaut. Une passerelle qui ne transfère pas et un chemin qui ne transporte pas les gros paquets produisent des schémas distincts : l’un échoue dans les deux sens et à toutes les tailles, l’autre survit aux petites requêtes et meurt sur les grandes. Identifiez la forme que vous avez avant de changer le moindre nombre. Le test est bon marché et il élimine la moitié des causes possibles.

Deux pannes, deux formes différentes

Un problème de transfert apparaît immédiatement après le serveur. La poignée de main réussit, l’adresse du tunnel répond, et rien derrière la passerelle n’est joignable, même avec une requête minuscule. Le paquet a atteint le serveur et n’a pas été transmis, ou la réponse n’avait pas de route de retour.

Un problème de taille n’apparaît qu’au-dessus d’un seuil. Le DNS, une poignée de main TCP et un petit appel d’API fonctionnent, tandis qu’un téléchargement de fichier ou une grande réponse se bloque. Les paquets qui tenaient ont voyagé de bout en bout, et ceux qui ne tenaient pas ont été abandonnés quelque part sans rapport utilisable.

Ces descriptions désignent des personnes différentes et des fichiers de configuration différents, c’est pourquoi mesurer la forme vaut mieux qu’une supposition. Un seul ping vers la passerelle ne peut pas les séparer.

Écartez le transfert avant de réduire quoi que ce soit

Testez une destination au-delà de la passerelle, pas la passerelle elle-même. Un ping vers l’adresse du tunnel du serveur prouve seulement que l’interface est active et que vous atteignez la machine qui termine le tunnel. Le trafic pour le réseau plus large dépend de l’activation du transfert IP sur cette machine et d’un pare-feu qui autorise le flux transféré. Les deux doivent être vrais, et si l’un est faux, il en résulte le même silence.

Le routage de retour compte tout autant. Si le réseau de destination ne sait pas comment atteindre l’adresse du tunnel du client, la requête arrive et la réponse disparaît, et le client signale un délai d’attente qui ressemble à un transfert abandonné.

Là où la conception utilise la traduction d’adresses, la règle de traduction fait partie de ce chemin de retour. La retirer en poursuivant un problème de MTU transforme une conception qui fonctionne en conception cassée, alors lisez les règles existantes avant de les modifier.

Mesurez où commence la rupture

Lisez d’abord l’état du transfert et les règles de filtrage. Ce sont des contrôles en lecture seule et ils répondent à la question bon marché :

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Ensuite, testez des tailles avec le bit don’t-fragment, depuis le client, vers un hôte au-delà de la passerelle :

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

Si la première sonde fonctionne et que la seconde échoue avec une erreur de fragmentation, le chemin vous indique sa taille utilisable. Si aucune ne fonctionne, vous regardez un transfert ou un routage, et le MTU n’est pas la variable à changer.

Réparez la couche que vous avez prouvée

Quand le transfert est la panne, la correction est une règle de transfert ou une route, exprimée aussi étroitement que la conception le permet. Quand la taille est la panne, la correction est un MTU qui tient compte de l’encapsulation sur ce chemin précis, appliqué à l’interface qui en a besoin plutôt qu’à chaque adaptateur du parc.

Dans tous les cas, répétez ensuite la même tâche vers la même destination. Si le transfert volumineux d’origine aboutit maintenant, le changement a traité la couche qui échouait. Si seule la petite sonde s’est améliorée, vous avez traité un symptôme et la vraie limite est toujours en place.

Notez quelle forme vous avez observée avant le changement. Cette seule ligne, consignée à côté du correctif, est ce qui empêche la personne suivante de baisser un MTU qui n’a jamais été le problème.