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