Nuage

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
==== Routes parasites Docker : ConnMan — services injoignables depuis l'extérieur ====

=== Symptômes ===
  * Gitea SSH (port 8329) injoignable depuis le WAN, web OK. Précédemment : NFS via WireGuard en timeout.
  * ''tcpdump'' côté serveur : SYN reçus, **aucun SYN-ACK renvoyé** — le retour part dans le vide.
  * Symptôme générique : tout trafic retour vers une destination **hors LAN** (IP publiques, réseau VPN) est détourné.

&lt;code&gt;
ip route get &lt;IP_client_externe&gt;
  → ... dev veth3b7619a src 169.254.x.x    # retour envoyé dans un veth Docker !

ip route show | grep -E "veth|^0.0.0.0"
  0.0.0.0 dev vethXXXX scope link
  default dev vethXXXX scope link          # métriques énormes (429496xxxx)
  169.254.0.0/16 dev vethXXXX proto kernel scope link src 169.254.x.x
&lt;/code&gt;

=== Cause racine ===
**Quatre gestionnaires réseau cohabitaient** : ifupdown (le légitime, dhclient sur ''enp3s0''), NetworkManager (inactif sur les veth), systemd-networkd (réveillé par socket), et **ConnMan** — le vrai coupable.

ConnMan « adopte » chaque veth Docker à sa création, tente un DHCP dessus, échoue, retombe en IPv4LL (''169.254.x'') et pose des routes ''default''/''0.0.0.0'' parasites qui captent le trafic retour. Identification via le journal :

&lt;code&gt;
journalctl -b | grep -i vethXXXX
  → connmand[...]: Adding interface vethXXXX [ ethernet ]
&lt;/code&gt;

Fausse piste initiale : systemd-networkd (fichier ''10-docker-veth-unmanaged.network'' créé, sans effet — les veth étaient déjà ''unmanaged'' côté networkd).

=== Solution ===
Vérifier **avant** que ifupdown tient bien l'interface (crucial en remote) :
&lt;code&gt;
systemctl is-active networking          # active
ps aux | grep dhclient                  # dhclient ... enp3s0
&lt;/code&gt;

Puis neutraliser ConnMan **avec filet de sécurité** (relance auto si perte de main) :
&lt;code&gt;
# Filet : relance ConnMan dans 300 s quoi qu'il arrive
systemd-run --on-active=300 systemctl start connman

# Bascule : stop ConnMan + reprise de l'interface par ifupdown
systemctl stop connman; sleep 2; ifdown enp3s0; ifup enp3s0

# Si la main est conservée : annuler le filet (nom affiché par systemd-run)
systemctl stop run-XXXX.timer

# Rendre permanent
systemctl disable --now connman &amp;&amp; systemctl mask connman
&lt;/code&gt;

De même pour systemd-networkd (redondant, socket-activated) :
&lt;code&gt;
systemctl disable --now systemd-networkd.socket systemd-networkd.service
systemctl mask systemd-networkd.socket systemd-networkd.service
&lt;/code&gt;

=== Validation (après reboot) ===
&lt;code&gt;
ip route show | grep -E "veth|^0.0.0.0"   # vide
ip route show | head -1                    # default via 192.168.1.90 dev enp3s0
git fetch                                  # depuis l'extérieur, via Gitea SSH
&lt;/code&gt;

=== Pièges rencontrés ===
  * ''systemctl stop connman'' **à chaud sans ifup derrière** : ConnMan flushe l'IP de ''enp3s0'' en mourant → serveur injoignable (reset électrique nécessaire).
  * Les routes parasites déjà posées ne partent pas seules : ''ip route flush dev vethXXXX''.
  * **Attention au flush** : il peut aussi emporter la route par défaut si elle avait été posée par le gestionnaire fautif → vérifier ''ip route show'' juste après.