Deux VPN sur le même /24 : le full-tunnel éclipse ton mesh

Un git push vers un Gitea self-hosted accessible uniquement par le mesh WireGuard, et soudain : timeout. Le mesh « marchait » pourtant cinq minutes plus tôt. ping 10.8.0.1 répondait, à 20 ms. Mais les ports du serveur (Gitea, MinIO) étaient tous « filtrés ». Le coupable n’était pas le pare-feu : c’était la table de routage.

Le symptôme trompeur

$ ping -c1 10.8.0.1
64 bytes from 10.8.0.1: ... time=20.9 ms      # repond, l'air OK
$ git ls-remote origin                         # → hang puis timeout
$ for p in 222 3000 9100; do nc -zw3 10.8.0.1 $p; done
port 222: FILTERED ; 3000: FILTERED ; 9100: FILTERED

Le réflexe naturel : « le service est tombé », ou « le pare-feu bloque ». Les deux étaient faux — côté serveur, tout écoutait, le conteneur tournait depuis des semaines.

La vraie cause : collision de sous-réseau

$ ip route get 10.8.0.1
10.8.0.1 dev tun0 src 10.8.0.17 ...

tun0, pas wg0. Un second VPN (OpenVPN, pro) s’était connecté entre-temps, en full-tunnel (default via 10.8.0.1 dev tun0), et il utilisait le même plan d’adressage 10.8.0.0/24 que mon mesh WireGuard. Résultat : 10.8.0.1 ne désignait plus la gateway du mesh, mais celle de l’autre VPN — qui répond au ping (c’est une vraie gateway) mais n’héberge évidemment ni mon Gitea ni mon MinIO.

Le 10.8.0.1 qui répondait au ping et le 10.8.0.1 que je voulais joindre étaient deux machines différentes. Le ping ne ment pas — il dit juste à qui il parle, et ce n’était pas le bon.

Deux réseaux privés sur le même /24, et celui dont la route est la plus spécifique (ou le full-tunnel arrivé en dernier) gagne. Le mesh n’était pas cassé : il était éclipsé.

Le correctif (et le vrai correctif)

Immédiat : couper l’OpenVPN, relancer WireGuard, vérifier que la route repointe :

$ nmcli con down vpn-pro && nmcli con up wg-mesh
$ ip route get 10.8.0.1
10.8.0.1 dev wg-mesh src 10.8.0.2 ...           # à nouveau le mesh

Le vrai correctif est de renuméroter : 10.8.0.0/24 est une plage RFC1918 archi-courante, et tout VPN tiers (employeur, client, fournisseur) a une chance non négligeable de l’utiliser aussi. Un mesh perso a tout intérêt à se planquer dans un coin moins fréquenté — 10.97.x.0/24, 172.30.x.0/24 — pour ne jamais entrer en collision avec un full-tunnel imposé.

Lessons learned

• ping qui répond ne prouve pas que tu parles à la bonne machine. Sur un /24 partagé par deux VPN, l’IP est la même, l’hôte derrière ne l’est pas. Le premier geste de debug réseau, c’est ip route get <ip>, pas ping <ip>.
• Un full-tunnel arrivé en second éclipse silencieusement un mesh sur le même sous-réseau. Aucune erreur, aucun log : juste une route par défaut qui détourne tout. « Services filtrés » est ici un symptôme de routage, pas de firewall.
• Choisis un plan d’adressage exotique pour ton mesh perso. 10.8.0.0/24 et 192.168.1.0/24 sont des aimants à collision avec les VPN imposés. Un /24 improbable t’épargne la coexistence impossible.
• « Ça marchait il y a cinq minutes » = quelque chose a changé dans l’environnement, pas dans le service. Ici, l’activation d’un autre VPN. Cherche le changement de contexte avant de soupçonner la cible.

#sysadmin #networking #wireguard #vpn #routing #lessonslearned