Service qui ne fonctionnent pas depuis VPN : timeout — routes parasites systemd-networkd
Symptôme
Client VPN (10.1.100.20) : montage NFS de cahute (192.168.1.9) en timeout.
Port 2049 ouvert (nc OK), mais mount.nfs4 bloque. Ping serveur KO.
Diagnostic
Aller correct (routé dans wg), retour perdu. tcpdump côté serveur : SYN reçus, aucun SYN-ACK.
tcpdump -ni enp3s0 host 10.1.100.20 # SYN entrants, 0 retour ip route get 10.1.100.20 from 192.168.1.9 → 10.1.100.20 ... dev veth6bb30cd # retour envoyé dans un veth Docker !
Cause racine : systemd-networkd gère les interfaces veth de Docker. À chaque conteneur, il tente un DHCP dessus, échoue, tombe en IPv4LL (169.254.x) et ajoute des routes default / 0.0.0.0 dev vethX parasites qui captent le trafic vers 10.1.100.0/24. Le veth « coupable » change à chaque redémarrage de conteneur.
ip route show | grep -E "veth|^0.0.0.0" 0.0.0.0 dev vethXXXX scope link default dev vethXXXX scope link 169.254.0.0/16 dev vethXXXX proto kernel scope link src 169.254.x.x systemctl is-active systemd-networkd # active
Correctif permanent
Exclure les interfaces virtuelles Docker de la gestion networkd :
# /etc/systemd/network/10-docker-veth-unmanaged.network [Match] Name=veth* docker* br-* [Link] Unmanaged=yes
systemctl restart systemd-networkd # purge des routes déjà posées (non rétroactif) : ip route flush dev vethXXXX # pour chaque veth concerné
Validation
ip route show | grep -E "veth|^0.0.0.0" # doit être vide
Le fichier .network est permanent → routes parasites plus jamais recréées.
À confirmer par un reboot (conteneurs relancés, table toujours propre).
Notes
- Le ping ICMP peut être filtré alors que NFS (TCP 2049) répond → tester le port, pas le ping.
- Rustine temporaire écartée :
ip route add 10.1.100.0/24 via 192.168.1.90 dev enp3s0.