==== 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.

<code>
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 !
</code>

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.

<code>
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
</code>

=== Correctif permanent ===
Exclure les interfaces virtuelles Docker de la gestion networkd :

<code>
# /etc/systemd/network/10-docker-veth-unmanaged.network
[Match]
Name=veth* docker* br-*

[Link]
Unmanaged=yes
</code>

<code>
systemctl restart systemd-networkd
# purge des routes déjà posées (non rétroactif) :
ip route flush dev vethXXXX   # pour chaque veth concerné
</code>

=== Validation ===
<code>
ip route show | grep -E "veth|^0.0.0.0"   # doit être vide
</code>
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''.