Depuis mon précédent article sur ce sujet, j’ai eu de fréquentes micro-coupures réseau. Après moult essais, on a réussi à contourner le problème.

Symptôme

Pendant 10 à 25 secondes, plus aucun trafic réseau (ni entrant, ni sortant), puis tout revient comme si de rien n’était.

Et cela se produisait toutes les 15 à 30 minutes environ.

C’est surtout en visioconférence que c’était visible, et vraiment gênant (surtout en cette période de covid).

Épisode 1: d’où ça vient?

Ca se produisait indifféremment en filaire et en WiFi, sur différents services de visio, et sur différents ordinateurs/OS.

Ca n’était pas lié au protocole réseau utilisé : le ping était coupé également, par exemple.

Et si je configurais la « VPN routing policy » de mon Turris pour sortir directement sur Internet (sans passer par le VPN Wireguard, voir mon précédent article de blog), le problème ne se produisait pas (ça a d’ailleurs été ma solution de contournement chaque fois que j’avais une visio importante).

Bref, j’en ai conclus que ça venait bien du VPN Wireguard, et j’ai contacté mon fournisseur https://www.illyse.net/.

Épisode 2: la malédiction du /5

Les gens d’Illyse ont été très réactifs. Il m’ont mis en relation avec un autre utilisateur de routeur Turris, qui avait le même problème que moi. Et on a investigué tous ensemble.

On s’est rendu compte que, lorsque le problème apparaissait, le ping était coupé non seulement vers l’extérieur, mais aussi vers le routeur Turris lui-même. Les logs du Turris indiquaient effectivement que l’interface du réseau local passait down, puis up à nouveau (mais pas plus d’indications). Cela nous a donc orienté vers un problème spécifique à notre routeur.

En laissant tourner des pings, on s’est rendu compte que les coupures apparaissaient systématiquement sur un « /5 » (c’est-à-dire à une heure dont les minutes sont un multiple de 5). Ca nous a fait penser à une tâche programmée (type cron).

On a suspecté et testé pas mal de choses sur nos Turris, mais sans succès : désactivation de crontabs, de services etc. Les mises à jour de Turris OS n’ont rien changé.

Épisode 3: le Turris n’aime pas le syncconf

Notre interlocuteur de chez Illyse a réalisé qu’il y avait de leur côté un cron qui s’exécutait en /5 : un « syncconf » pour mettre à jour leur serveur Wireguard en fonction des ajout/modification/retrait de VPN de leurs abonnés.

Bien qu’il nous paraissait à tous très improbable que ça vienne de là, il a passé le /5 en /6 : bing, nos micro-coupures sont passées en /6. Ce script était bien la cause indirecte de nos problèmes.

Pourtant, aucun autre utilisateur du Wireguard d’Illyse n’avait ce problème. Pourquoi est-ce que notre Turris est perturbé par le syncconf?

On aurait aimé avoir des logs plus détaillées du client wireguard côté Turris, en s’appuyant sur https://gist.github.com/artizirk/5bc87e345f850a8a0724929e0436ef84, mais pas simple de le faire sur notre Turris. Le module de kernel DEBUG_FS y est bien activé, mais il n’y a pas de répertoire dynamic_debug dans /sys/kernel/debug/. Il aurait fallu compiler notre propre image : https://forum.openwrt.org/t/wireguard-debug-log-info/90241.

Chez l’autre personne affectée par le problème, un contournement qui a semblé fonctionner a été de modifier la configuration du firewall du Turris pour que les paquets sortant du LAN ne soient envoyables que vers le VPN (et non pas vers le VPN OU vers le WAN). L’hypothèse étant que, lors du syncconf, le Turris essaie quelques secondes de basculer le traffic vers le WAN.

Sauf que cela obligeait à toujours faire passer le trafic par le VPN. Or la configuration de mon article précédent apportait plein d’avantages, notamment la possibilité de sortir directement sur Internet si besoin (pour avoir toute la bande passante, ou autre raison)

Épilogue

Au final, Illyse a modifié ses scripts pour que le syncconf Wireguard ne soit plus exécuté à intervalle régulier (/5 ou /6), mais uniquement en cas de modification de la config.

Ce n’est pas vraiment une solution (le problème sous-jacent est certainement toujours là), mais cela limite tellement sa fréquence d’apparition qu’on s’en est contentés.

Je n’ai plus constaté le problème depuis.

Merci aux personnes qui ont creusé ce sujet avec moi (pendant 6 mois, quand même!)