ZeroTier : créer un réseau privé et résoudre le problème « impossible de pinguer »

Ce qu’est réellement ZeroTier (et ce que ce n’est pas)

ZeroTier est un réseau en superposition : il crée une interface virtuelle de type Ethernet sur chaque nœud et utilise un transport pair-à-pair chiffré
lorsque c’est possible. Quand le pair‑à‑pair est impossible (NAT strict, UDP bloqué, etc.), il peut relayer.
Pensez‑y comme à un « LAN défini par logiciel sur Internet », sauf qu’il se comporte plutôt comme un hybride :
parfois proche du L2, souvent proche du L3, et toujours dépendant de vos conditions réseau réelles.

Implication pratique : quand vous ne pouvez pas pinguer, ce n’est rarement « ZeroTier est en panne ».
C’est généralement l’une des cinq choses suivantes :
autorisation, adressage, politique de pare‑feu de l’OS, routage/chevauchement ou MTU/fragmentation.
Le reste de cet article explique comment prouver laquelle, rapidement.

Ce que ZeroTier n’est pas : ce n’est pas une échappatoire magique aux politiques de sortie d’entreprise, et ce n’est pas un substitut à
la compréhension des routes. De plus, il ne fera pas répondre un hôte Windows à l’ICMP si Windows Firewall dit « non ».
Si vous lisez ceci parce que « ça affiche ONLINE mais je ne peux pas pinguer », bienvenue au club.

Faits et contexte qui facilitent le dépannage

Un peu d’histoire et quelques mécanismes importent parce qu’ils expliquent les modes de défaillance. Voici neuf points concrets à connaître.

1. ZeroTier utilise UDP par défaut (souvent le port 9993). Si la sortie UDP est bloquée, vous pouvez obtenir des relays ou rien du tout.
2. Les nœuds ont une identité à 10 chiffres dérivée de clés cryptographiques. Cette identité persiste ; changer d’IP ne change pas l’identité du nœud.
3. Les réseaux sont identifiés par un ID réseau à 16 chiffres. Rejoindre le mauvais réseau est une erreur classique où « tout semble OK ».
4. « ONLINE » ne veut pas dire « joignable ». Cela signifie souvent « le contrôleur connaît ce nœud », pas « l’ICMP fonctionnera de bout en bout ».
5. Le pair‑à‑pair est opportuniste. Le NAT traversal réussit ou échoue selon le comportement réel du NAT, le support du hairpin et le mappage des ports.
6. Les relays sont normaux. Quand vous voyez « RELAY », la latence augmente et le débit diminue. Cela peut casser des applis sensibles au RTT ou à la MTU.
7. Les routes gérées sont une politique côté contrôleur. Si vous attendez une connectivité site‑à‑site sans annoncer les routes, vous serez déçu à répétition.
8. Le bridging est puissant et risqué. Le bridging peut transformer une superposition propre en une foire aux broadcasts. Utile pour certains cas legacy, terrible pour « pourquoi c’est lent ? »
9. Les chevauchements de sous‑réseau sont du poison. Si votre réseau ZeroTier utilise 192.168.1.0/24 et que le routeur domestique de quelqu’un aussi, les paquets prendront le chemin le plus stupide possible.

Construire un réseau privé qui se comporte

Choisir un plan d’adressage qui n’entrera pas en collision avec la réalité

N’utilisez pas 192.168.0.0/24 ou 10.0.0.0/24 à moins que votre hobby soit de déboguer des routages en split‑brain.
Utilisez quelque chose d’ennuyeux et improbable : une tranche dédiée dans 10/8 (mais pas les suspects habituels), ou si votre environnement le permet,
utilisez IPv6 à l’intérieur de ZeroTier.

Un choix simple et à faible collision : 10.147.0.0/16 pour la superposition, puis découpez des /24 si vous avez besoin de faire des ponts entre sites.
La plage exacte importe peu ; l’absence de chevauchement, oui.

Décider : routage ou bridging (ne faites pas « un peu » des deux)

Le routage est presque toujours la bonne réponse pour la connectivité site‑à‑site. Le bridging sert quand vous avez réellement besoin d’une adjacency L2
(un protocole de découverte ancien, des hypothèses non routables d’une appli, ou un appareil vendeur qui pense que les routeurs sont une conspiration).

Le bridging augmente le rayon d’impact. Broadcast et multicast peuvent se répandre dans la superposition, et c’est comme ça que vous obtenez des pics de latence bizarres.
Si votre objectif est « SSH vers des serveurs et atteindre quelques sous‑réseaux », routez‑le.

Plan de contrôle vs plan de données : l’autorisation n’est pas optionnelle

Un réseau privé exige l’autorisation des membres. Si vous oubliez d’autoriser, le nœud peut apparaître mais ne passera pas le trafic.
Ce n’est pas un problème subtil ; c’est un problème « je jure qu’il est connecté ».

Établir une base : le ping n’est pas le premier test

L’ICMP est utile, mais il est souvent bloqué. Votre première base devrait être :
(1) les nœuds peuvent‑ils se voir en tant que peers, et (2) pouvez‑vous transmettre du TCP vers un port ouvert connu (SSH, HTTPS, ou un écouteur netcat temporaire).

Blague n°1 : Le ping est comme un détecteur de fumée — quand il est silencieux, soit vous êtes en sécurité, soit la pile est morte depuis des mois et personne ne vous a prévenu.

Mode opératoire de diagnostic rapide (vérifier dans cet ordre)

Quand vous êtes en astreinte, vous ne gagnez pas de points pour la créativité. Vous gagnez des points pour la rapidité et la certitude.
Voici l’ordre qui identifie le goulot avec le moins d’allers‑retours.

1) Confirmer l’adhésion et l’autorisation

• Le nœud a‑t‑il rejoint le bon network ID ?
• Est‑il autorisé sur le contrôleur ?
• A‑t‑il une IP ZeroTier assignée ?

2) Confirmer l’interface locale et les routes

• L’interface ZeroTier existe‑t‑elle et a‑t‑elle une IP ?
• La table de routage envoie‑t‑elle le trafic vers l’interface ZeroTier, ou vers la mauvaise gateway par défaut à cause d’un chevauchement ?

3) Confirmer la qualité du chemin peer (DIRECT vs RELAY) et la reachabilité UDP

• Les peers sont‑ils « DIRECT » ou « RELAY » ?
• Le port UDP 9993 est‑il bloqué en sortie/entrée ?
• Êtes‑vous derrière un NAT symétrique qui tue le P2P ?

4) Vérifier les pare‑feux hôtes et la politique ICMP

• Le pare‑feu de l’OS autorise‑t‑il l’ICMP et les ports TCP cibles ?
• La politique diffère‑t‑elle selon les profils « Public » vs « Private » (Windows) ?

5) Vérifier MTU/fragmentation quand les petits paquets fonctionnent et les gros pas

• Pouvez‑vous pinguer avec une petite charge mais pas une grosse ?
• Voyez‑vous des PMTUD blackholes à cause d’ICMP fragmentation‑needed bloqués ?

6) Ensuite seulement : sophistiquer

• Boucles de bridging, mauvaise configuration de routes gérées, routage basé sur la politique, bizarreries de namespaces conteneurs, moons, etc.

Tâches pratiques : commandes, sorties et décisions

Les tâches suivantes sont volontairement opérationnelles. Chacune inclut une commande, une sortie réaliste, ce que cela signifie,
et la décision suivante à prendre. Exécutez‑les aux deux extrémités (source et destination) sauf si la tâche est explicitement côté contrôleur.

Task 1: Verify ZeroTier service is running (Linux systemd)

cr0x@server:~$ systemctl status zerotier-one --no-pager
● zerotier-one.service - ZeroTier One
     Loaded: loaded (/lib/systemd/system/zerotier-one.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 09:11:42 UTC; 2h 13min ago
   Main PID: 1178 (zerotier-one)
      Tasks: 24 (limit: 19070)
     Memory: 38.6M
        CPU: 1min 22.413s
     CGroup: /system.slice/zerotier-one.service
             └─1178 /usr/sbin/zerotier-one

Signification : Le démon est vivant. S’il est inactive/failed, rien d’autre n’a d’importance.

Décision : S’il ne tourne pas, démarrez‑le et vérifiez les logs avant de toucher aux routes/pare‑feux.

Task 2: Confirm you joined the intended network ID

cr0x@server:~$ sudo zerotier-cli listnetworks
200 listnetworks <nwid> <name> <mac> <status> <type> <dev> <ZT assigned ips>
200 listnetworks a84ac5c10a1b2c3d corp-overlay 5e:33:aa:9d:01:10 OK PRIVATE zt7nn3p3kq 10.147.10.23/16

Signification : Vous êtes joint, statut OK, et vous avez une IP de superposition assignée.

Décision : Si le statut est ACCESS_DENIED ou qu’il n’y a pas d’IP assignée, corrigez l’autorisation ou l’affectation d’IP d’abord.

Task 3: Check node identity (useful for controller authorization)

cr0x@server:~$ sudo zerotier-cli info
200 info 9f3c1a2b3c 1.14.2 ONLINE

Signification : L’ID du nœud est 9f3c1a2b3c. Vous l’utiliserez sur le contrôleur pour autoriser et faire correspondre l’adhésion.

Décision : S’il n’est pas ONLINE, vous pouvez avoir des problèmes de reachabilité UDP, des problèmes DNS ou un décalage horaire qui casse la confiance.

Task 4: List peers and see DIRECT vs RELAY

cr0x@server:~$ sudo zerotier-cli listpeers
200 listpeers <ztaddr> <path> <latency> <version> <role>
200 listpeers 62f865ae71 203.0.113.19/9993;2684 34 1.14.2 LEAF
200 listpeers 9d219039f7 198.51.100.8/9993;58421 41 1.14.2 LEAF
200 listpeers 35c192ce9b - 0 1.14.2 PLANET

Signification : Vous avez des chemins directs vers des peers (IP publique/port affichés). Si vous voyez RELAY ou un tiret pour le chemin, attendez‑vous à des problèmes.

Décision : Si relié et que la performance est critique, dépannez le NAT/UDP ou ajoutez une moon dans un emplacement accessible.

Task 5: Confirm the ZeroTier interface and IP address

cr0x@server:~$ ip -brief addr show | grep -E 'zt|zerotier'
zt7nn3p3kq         UP             10.147.10.23/16 fe80::5c33:aaff:fe9d:110/64

Signification : L’interface existe, elle est up, et possède l’IP de superposition attendue.

Décision : Si l’interface est absente/down, votre join a probablement échoué ou le service n’est pas lancé.

Task 6: Check routing table for overlap or wrong next hop

cr0x@server:~$ ip route show
default via 192.168.50.1 dev eth0
10.147.0.0/16 dev zt7nn3p3kq proto kernel scope link src 10.147.10.23
192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.20

Signification : Le sous‑réseau de la superposition routé vers l’interface ZeroTier. Bien.

Décision : Si le sous‑réseau de la superposition chevauche un sous‑réseau local, vous verrez des routes concurrentes. Corrigez en changeant la plage ou en utilisant prudemment les routes gérées.

Task 7: Try TCP connectivity instead of ping (netcat)

cr0x@server:~$ nc -vz 10.147.10.50 22
Connection to 10.147.10.50 22 port [tcp/ssh] succeeded!

Signification : Même si le ping échoue, le TCP fonctionne. Cela signifie souvent que l’ICMP est bloqué, pas que ZeroTier est cassé.

Décision : Arrêtez de perdre du temps sur le ping. Corrigez la politique de pare‑feu si vous avez vraiment besoin d’ICMP ; sinon, poursuivez avec votre appli.

Task 8: Confirm ICMP is blocked locally (Linux firewall: nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    iifname "zt7nn3p3kq" tcp dport { 22, 443 } accept
  }
}

Signification : Drop par défaut sur input, et seuls TCP 22/443 sont autorisés sur l’interface ZeroTier. L’ICMP n’est pas autorisé.

Décision : Ajoutez un accept explicite pour l’ICMP sur l’interface ZeroTier si le ping est requis, ou documentez « le ping ne fonctionnera pas » et passez à autre chose.

Task 9: Check Windows Firewall profile mismatch (PowerShell)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetConnectionProfile | Format-Table Name,InterfaceAlias,NetworkCategory"
Name              InterfaceAlias           NetworkCategory
corp-wifi          Wi-Fi                    Public
ZeroTier One [a84ac5c10a1b2c3d]  ZeroTier One Virtual Port Private

Signification : L’interface ZeroTier est « Private », mais d’autres interfaces peuvent être « Public ». Les règles peuvent ne pas s’appliquer où vous le pensez.

Décision : Assurez‑vous que les règles entrantes sont liées à l’interface ZeroTier ou au bon profil ; ne supposez pas que « Private » veut dire « autorisé ».

Task 10: Test MTU quickly (Linux ping with DF)

cr0x@server:~$ ping -c 2 -M do -s 1472 10.147.10.50
PING 10.147.10.50 (10.147.10.50) 1472(1500) bytes of data.
ping: local error: message too long, mtu=280
ping: local error: message too long, mtu=280

--- 10.147.10.50 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1015ms

Signification : Le MTU du chemin est bien inférieur à Ethernet 1500. Quelque chose encapsule dans quelque chose d’autre (VPN sur VPN, PPPoE ou PMTUD cassée).

Décision : Réduisez le MTU de ZeroTier (ou corrigez le chemin sous‑jacent) et retestez avec des tailles plus petites jusqu’à réussite.

Task 11: Inspect ZeroTier local config and networks directory

cr0x@server:~$ sudo ls -al /var/lib/zerotier-one
total 64
drwxr-xr-x  5 root root  4096 Dec 27 09:11 .
drwxr-xr-x 38 root root  4096 Dec 27 09:11 ..
-rw-r--r--  1 root root    64 Dec 27 09:11 identity.public
-rw-------  1 root root   256 Dec 27 09:11 identity.secret
drwxr-xr-x  2 root root  4096 Dec 27 09:11 networks.d
-rw-r--r--  1 root root  1254 Dec 27 09:11 zerotier-one.port

Signification : L’identité existe ; les configs d’adhésion vivent sous networks.d.

Décision : Si les fichiers d’identité manquent ou si les permissions sont incorrectes, l’identité du nœud change ou le démon plante de façon étrange. Corrigez le système de fichiers/permissions avant le réseau.

Task 12: Validate that UDP 9993 is reachable from the host’s network

cr0x@server:~$ sudo ss -uapn | grep 9993
UNCONN 0      0          0.0.0.0:9993      0.0.0.0:*    users:(("zerotier-one",pid=1178,fd=25))
UNCONN 0      0             [::]:9993         [::]:*    users:(("zerotier-one",pid=1178,fd=26))

Signification : ZeroTier écoute sur UDP 9993. C’est nécessaire mais pas suffisant.

Décision : S’il n’écoute pas, vérifiez la configuration ou que le démon est bien lié. S’il écoute mais que les peers relaient, suspectez un pare‑feu/NAT en amont.

Task 13: Quick packet capture on the ZeroTier interface

cr0x@server:~$ sudo tcpdump -ni zt7nn3p3kq icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on zt7nn3p3kq, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:45:11.203812 IP 10.147.10.23 > 10.147.10.50: ICMP echo request, id 1789, seq 1, length 64
10:45:12.210914 IP 10.147.10.23 > 10.147.10.50: ICMP echo request, id 1789, seq 2, length 64

Signification : Les requêtes sortent. Si vous ne voyez pas de réponses, le problème est en aval : pare‑feu de la destination, route de retour ou perte de paquets.

Décision : Lancez tcpdump aussi sur la destination. Si la destination ne voit jamais les requêtes, vous avez un problème de routage/chemin ZeroTier. Si elle les voit et ne répond pas, c’est une politique d’hôte.

Task 14: Check reverse path and policy routing traps

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.zt7nn3p3kq.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.zt7nn3p3kq.rp_filter = 1

Signification : Le reverse path filtering strict est activé. Sur des hôtes multi‑homés, cela peut dropper du trafic valide si Linux pense que le chemin de retour est « incorrect ».

Décision : Si vous faites du routage entre interfaces ou du policy routing, envisagez de mettre rp_filter en loose (2) sur les interfaces concernées.

Task 15: Verify IP forwarding if this node is meant to route traffic

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Signification : Cet hôte ne routage pas les paquets entre interfaces.

Décision : Si cette machine est votre gateway ZeroTier pour une route site‑à‑site, activez le forwarding et ajoutez les règles de pare‑feu pour le forwarding/NAT si nécessaire.

Task 16: Check for subnet overlap that steals traffic (classic “can’t ping”)

cr0x@server:~$ ip route get 10.147.10.50
10.147.10.50 dev zt7nn3p3kq src 10.147.10.23 uid 1000
    cache

Signification : Le kernel enverra le trafic sur l’interface ZeroTier. S’il choisit à la place eth0, vous avez un chevauchement ou une route plus spécifique.

Décision : Corrigez le plan d’adressage ou la priorité de routage. Ne « contrez » pas le chevauchement avec des rustines à moins d’aimer les incidents récurrents.

Analyse approfondie du problème « impossible de pinguer » : où les paquets meurent

Zone de défaillance 1 : vous n’êtes pas réellement autorisé (ou vous avez rejoint le mauvais réseau)

Le contrôleur est le videur. Si vous n’avez pas reçu le tampon d’autorisation, vous n’entrez pas.
Un nœud peut apparaître dans la liste des membres mais rester non autorisé. Selon l’UI/politique du contrôleur, vous pouvez encore voir des indicateurs « connectés »
qui vous mettent en confiance à tort.

Règle opérationnelle : considérez « a une IP ZeroTier et peut échanger des paquets » comme la vraie définition de l’adhésion, pas « je le vois dans l’UI web ».

Zone de défaillance 2 : l’ICMP est bloqué et vous poursuivez le mauvais problème

Le ping est de l’ICMP echo. Beaucoup d’environnements bloquent l’ICMP entrant par défaut, surtout les hôtes Windows et les serveurs Linux durcis.
Si SSH fonctionne et que le ping ne fonctionne pas, ce n’est pas « ZeroTier ne peut pas pinguer ». C’est « l’ICMP est bloqué ».

Si votre supervision utilise le ping, autorisez‑le explicitement sur l’interface ZeroTier ou passez la supervision à des checks TCP.
Les checks TCP sont généralement plus proches de ce qui compte réellement : l’application.

Zone de défaillance 3 : asymétrie de route et « le trafic de retour va ailleurs »

Les réseaux en superposition reposent toujours sur des décisions de routage. Si l’hôte A envoie des paquets à l’hôte B via ZeroTier,
l’hôte B doit renvoyer les réponses via ZeroTier (ou au moins vers A de manière cohérente).
Si l’hôte B pense que A est sur une autre interface à cause d’un chevauchement ou d’un policy routing, les réponses se perdent.

Cela se manifeste ainsi : tcpdump sur A montre des requêtes echo sortantes, tcpdump sur B montre leur arrivée,
mais B ne répond jamais (ou répond par la mauvaise interface). Le reverse path filtering peut aussi dropper ces réponses.

Zone de défaillance 4 : chevauchement de sous‑réseau avec des réseaux domestiques/bureau

Le chevauchement est le tueur silencieux car il est intermittent. Votre bureau peut utiliser 10.0.0.0/8 massivement,
votre superposition utilise 10.0.0.0/24 parce que « c’est privé », et le réseau local d’un utilisateur distant correspond par hasard.
Certaines machines fonctionnent, d’autres pas, et vous commencez à accuser ZeroTier comme s’il était hanté.

Corrigez le chevauchement en choisissant une plage dédiée et en vous y tenant. Si vous avez déjà expédié un chevauchement,
migrez délibérément et dans une direction. Les routes chevauchantes « temporaires » sont la recette du chaos permanent.

Zone de défaillance 5 : NAT traversal vs relays (DIRECT compte)

Quand le NAT traversal réussit, les peers communiquent directement. Quand il échoue, ils peuvent relayer via l’infrastructure.
Les relays conviennent pour le trafic d’administration ; ils peuvent être brutaux pour les transferts en masse, les bases de données et tout ce qui a des timeouts serrés.
Parfois le ping fonctionne mais votre appli time‑out à cause de la latence/jitter du relay.

Vous pouvez souvent améliorer la connectivité directe en autorisant la sortie UDP, en évitant les middleboxes « UDP helper » qui altèrent le trafic,
ou en plaçant une moon dans un endroit accessible par les deux côtés.

Zone de défaillance 6 : MTU et PMTUD black holes

Vous verrez ça quand « les petites choses fonctionnent, les grosses plantent ». Peut‑être que le ping marche avec la taille par défaut mais échoue avec de gros paquets,
ou SSH se connecte mais les transferts de fichiers s’arrêtent, ou les handshakes TLS se bloquent mystérieusement.

L’encapsulation de la superposition ajoute de l’overhead. Si le chemin sous‑jacent a un MTU réduit (PPPoE, réseaux mobiles, tunnels imbriqués),
vous pouvez le dépasser. Un PMTUD correct nécessite les messages ICMP « fragmentation needed » ; beaucoup de réseaux les bloquent, créant un black hole.

Zone de défaillance 7 : bridging et tempêtes de broadcast (ou simplement des réseaux bruyants)

Le bridging peut faire ressembler un « impossible de pinguer » à un « parfois ça marche, parfois non » parce que vous avez introduit du bruit L2.
Broadcast et multicast peuvent saturer le lien, surtout sur des liens contraints.
La solution est généralement d’arrêter le bridging et de router à la place.

Une citation sur la fiabilité, parce que c’est approprié

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

En termes d’exploitation : arrêtez d’espérer que le ping se mette à marcher et commencez à collecter des preuves par couches.

Blague n°2 : Le NAT est le middle manager corporatif du réseau : il ajoute des réunions, perd des messages, et prend quand même le crédit quand ça fonctionne.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une fausse supposition

Une entreprise moyenne a déployé ZeroTier pour connecter quelques postes d’administration à des serveurs de test dans un labo.
Un développeur a dit : « Une fois que ça affiche ONLINE, on peut pinguer tout. » Cette supposition est allée directement dans un runbook.
La supervision était basée sur le ping, parce que c’était facile et que ça ressemblait à du réseau.

Le premier week‑end, un hôte jump Windows a été patché et redémarré. Il est revenu ONLINE dans le contrôleur.
Les checks ping ont échoué. Les alertes ont sonné. L’astreinte a passé une heure à chasser les peers ZeroTier et le NAT traversal.
Finalement quelqu’un a essayé nc vers le port 3389 et ça a fonctionné. RDP fonctionnait. Seul le ping échouait.

Cause racine : Windows Firewall avait basculé vers une politique ICMP entrante plus stricte sur l’adaptateur ZeroTier après un changement de profil.
Le système de supervision a interprété « pas d’ICMP » comme « hôte down », et le rapport d’incident a blâmé la superposition.
La superposition était innocente ; la supposition coupable.

La correction a été ennuyeuse et efficace : changer la supervision pour des checks TCP sur le service réel (RDP/SSH/HTTPS),
et autoriser explicitement l’ICMP seulement là où c’était nécessaire. Le runbook a été mis à jour avec « ONLINE n’est pas la joignabilité ».
Cette phrase a sauvé plusieurs futurs samedis.

Mini‑histoire 2 : L’optimisation qui a échoué

Une autre organisation voulait « de meilleures performances » sur ZeroTier, alors elle a décidé de faire du bridging de deux LAN de bureau
dans la superposition. La rationale semblait bonne : « Si c’est un grand LAN, les protocoles de découverte marcheront et les applis n’auront pas besoin de changements. »
Ils ont activé le bridging sur quelques gateways Linux et ont déclaré victoire après quelques pings réussis.

Le lundi après‑midi, les plaintes ont commencé : les appels vidéo bégayaient, les partages de fichiers se figeaient, et des dispositifs aléatoires sur un site
ont commencé à afficher des avertissements d’IP dupliquées. Le helpdesk a blâmé l’ISP. L’équipe réseau a blâmé le Wi‑Fi.
L’SRE d’astreinte a fait l’impopulaire : capturer le trafic sur l’interface ZeroTier et compter les trames broadcast.

Il s’est avéré qu’ils avaient effectivement étendu des domaines de broadcast sur une superposition Internet avec latence et jitter variables,
et qu’ils transportaient beaucoup de trafic L2 bavard (y compris des choses qui n’étaient jamais censées quitter un bâtiment).
Certains appareils n’ont pas supporté la nouvelle topologie « LAN ». Le comportement ARP est devenu étrange. Les broadcasts DHCP, un cauchemar.

Le rollback a été immédiat. Ils ont remplacé le bridging par du routage, ajouté quelques routes gérées pour les sous‑réseaux requis,
et utilisé la configuration applicative pour la découverte quand c’était possible.
Les performances se sont améliorées, parce qu’ils ont arrêté d’essayer de faire ressembler Internet à un switch.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise régulée utilisait ZeroTier pour une petite flotte d’agents de build répartis chez plusieurs fournisseurs.
Ils traitaient la superposition comme un réseau de production : plan d’adressage cohérent, routes gérées documentées,
et un baseline de pare‑feu hôte qui autorisait explicitement les ports requis sur l’interface ZeroTier.
Pas d’héroïsme, pas de « on s’en souviendra plus tard ».

Un jour, un fournisseur cloud a changé quelque chose sur son chemin réseau et un sous‑ensemble de nœuds a commencé à relayer.
La latence a augmenté ; quelques jobs de build ont commencé à time‑outer lors de l’upload d’artifacts. Personne n’a paniqué.
L’astreinte a utilisé la même checklist à chaque fois : peers (DIRECT vs RELAY), tables de routage, puis tests MTU.

Ils ont trouvé des problèmes de PMTUD sur le chemin d’un fournisseur. Parce que leur baseline incluait un test de validation MTU et un bouton documenté
pour réduire le MTU sur les nœuds affectés, ils ont déployé temporairement un MTU inférieur pour les nœuds de ce fournisseur pendant qu’ils escaladaient en amont.
Les builds se sont stabilisés en une heure. Pas besoin d’appel d’incident.

La leçon : des valeurs par défaut ennuyeuses et des vérifications reproductibles sont une caractéristique de performance. Elles réduisent le temps pour obtenir la vérité.
En production, c’est ce que vous voulez vraiment.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “Node is ONLINE but has no ZeroTier IP”

Cause racine : Membre non autorisé, auto‑assign d’IP désactivé, ou le nœud a rejoint le mauvais network ID.

Correction : Autorisez le membre et assurez‑vous que le réseau a une pool d’assignation IPv4/IPv6. Re‑vérifiez zerotier-cli listnetworks.

2) Symptom: “Ping fails, SSH works”

Cause racine : ICMP bloqué par le pare‑feu de l’hôte ou la politique de l’OS.

Correction : Autorisez l’ICMP sur l’interface/profil ZeroTier, ou cessez d’utiliser le ping comme test principal de joignabilité.

3) Symptom: “Can ping by ZeroTier IP, but can’t reach remote LAN subnet”

Cause racine : Route gérée manquante, IP forwarding manquant, ou règles de NAT/forward manquantes sur la gateway.

Correction : Ajoutez des routes gérées sur le contrôleur ; activez net.ipv4.ip_forward=1 ; ajoutez des règles de forwarding (et NAT si nécessaire).

4) Symptom: “Some users can ping, others can’t (especially from home)”

Cause racine : Chevauchement de sous‑réseau avec les plages de routeur domestique, ou DNS split envoyant le trafic ailleurs.

Correction : Changez la plage de la superposition pour une plage à faible collision ; évitez les plages RFC1918 courantes ; vérifiez ip route get.

5) Symptom: “Intermittent packet loss, jittery performance, ‘RELAY’ peers”

Cause racine : Échec du NAT traversal ou UDP bloqué ; le trafic est relayed.

Correction : Autorisez la sortie UDP ; évitez des réseaux egress restrictifs ; envisagez une moon dans un environnement accessible ; re‑vérifiez listpeers.

6) Symptom: “Small requests work; large transfers hang”

Cause racine : MTU/PMTUD black hole ; ICMP fragmentation‑needed bloqué quelque part.

Correction : Diminuez le MTU sur l’interface de superposition et/ou corrigez le traitement ICMP en amont ; validez avec ping -M do.

7) Symptom: “After enabling bridging, everything got weird and slow”

Cause racine : Amplification broadcast/multicast sur la superposition ; extension L2 accidentelle.

Correction : Arrêtez le bridging ; routez à la place ; restreignez le trafic et les sous‑réseaux autorisés ; confirmez que vous avez vraiment besoin du L2.

8) Symptom: “It works until we run containers”

Cause racine : Namespaces réseau des conteneurs et règles de pare‑feu n’incluent pas l’interface ZeroTier ; routage asymétrique via docker0.

Correction : Décidez si les conteneurs doivent binder l’IP ZeroTier de l’hôte, ou exécutez un jeu de règles de routage/NAT dédié pour les sous‑réseaux conteneurs.

Listes de contrôle / plan étape par étape

Checklist A: New ZeroTier network rollout (small org)

1. Choisissez un sous‑réseau de superposition qui n’entrera pas en conflit avec les plages bureau/maison (évitez 192.168.0.0/16 et des 10.0.0.0/24 courants).
2. Décidez routage vs bridging. Par défaut, routez.
3. Joignez 2–3 nœuds pilotes et autorisez‑les.
4. Vérifiez que zerotier-cli listnetworks affiche OK et des IP assignées.
5. Vérifiez que zerotier-cli listpeers montre des chemins directs quand possible.
6. Définissez la politique de pare‑feu hôte : n’autorisez que les ports requis sur l’interface ZeroTier.
7. Choisissez un test de connectivité réel : TCP vers le port de service, plus ping seulement si vous autorisez explicitement l’ICMP.
8. Documentez les routes gérées et les propriétaires (qui ajoute les routes, qui approuve).
9. Exécutez une validation MTU et enregistrez la taille de charge utile fonctionnelle de base.

Checklist B: Site-to-site connectivity (route remote subnet into ZeroTier)

1. Choisissez un nœud gateway sur le site distant avec uptime stable et propriété claire du pare‑feu.
2. Activez l’IP forwarding sur la gateway (net.ipv4.ip_forward=1).
3. Ajoutez une route gérée pour le sous‑réseau distant pointant vers l’IP ZeroTier de la gateway.
4. Assurez‑vous que le sous‑réseau distant dispose d’une route de retour vers la superposition (via la gateway ou NAT).
5. Validez avec une approche de type traceroute : hôte → IP ZeroTier gateway → IP LAN distante.
6. Verrouillez les règles de forwarding pour que la superposition n’atteigne que ce qu’elle doit atteindre.

Checklist C: “Can’t ping” incident response

1. Confirmer join + autorisation (Task 2).
2. Confirmer interface up + IP de superposition (Task 5).
3. Vérifier la sélection de route (Task 6 et Task 16).
4. Vérifier le chemin peer (Task 4).
5. Essayer le TCP vers un port connu (Task 7).
6. Vérifier les règles de pare‑feu hôte (Task 8 / vérifications de profil Windows).
7. Capturer sur les deux extrémités (Task 13) pour voir si les requêtes arrivent et si les réponses partent.
8. Si les symptômes le suggèrent : test MTU (Task 10).
9. Ensuite seulement, escalader vers moons/bridging/changements de policy routing.

FAQ

1) Why does ZeroTier show “ONLINE” but I can’t ping?

« ONLINE » n’est pas une garantie de reachabilité ICMP. Causes courantes : membre non autorisé, ICMP bloqué par le pare‑feu hôte,
chevauchement de sous‑réseau ou routage asymétrique. Utilisez des tests TCP et des captures pour prouver où les paquets s’arrêtent.

2) Is ping required to prove ZeroTier works?

Non. Le ping teste l’ICMP echo ; beaucoup de systèmes le bloquent. Un meilleur test « ça marche » est le TCP vers un port ouvert connu,
ou un check applicatif. Autorisez l’ICMP seulement si vous avez un besoin opérationnel explicite.

3) What does DIRECT vs RELAY mean in listpeers?

DIRECT signifie que des peers ont trouvé un chemin pair‑à‑pair (généralement meilleure latence et débit). RELAY signifie que le trafic passe par un relay
à cause d’un échec de NAT traversal ou d’UDP bloqué. RELAY convient pour l’administration, moins pour le trafic lourd.

4) Which subnet should I use for my ZeroTier network?

Utilisez un sous‑réseau qui ne chevauchera pas les réseaux réels des utilisateurs. Évitez les plages domestiques courantes.
Choisissez quelque chose d’inhabituel dans 10/8, ou utilisez IPv6. La cohérence vaut mieux que l’ingéniosité.

5) How do managed routes work?

Les routes gérées disent aux membres ZeroTier : « pour atteindre ce sous‑réseau, envoyez le trafic à ce membre en tant que gateway. »
Elles n’activent pas magiquement le forwarding ; votre gateway doit avoir le forwarding IP activé et des règles de pare‑feu pour forwarder le trafic.

6) Do I need a moon?

Pas toujours. Une moon peut aider quand de nombreux nœuds sont derrière des NAT restrictifs ou quand vous voulez une reachabilité plus prévisible.
Si la plupart des peers sont RELAY et que la performance compte, une moon dans un environnement accessible vaut le coup.

7) Why does SSH connect but file transfer stalls?

Ce schéma indique souvent MTU/PMTUD. SSH peut établir une session avec de petits paquets, puis bloquer lorsque des paquets plus gros ou
des segments TCP différents rencontrent un black hole MTU. Testez avec ping -M do et réduisez le MTU si besoin.

8) Can I bridge my LAN into ZeroTier?

Vous pouvez, mais vous ne devriez probablement pas. Le bridging étend les domaines de broadcast et peut causer du trafic bruyant,
des comportements ARP/DHCP étranges et des problèmes de performance. Routez sauf si vous avez une exigence L2 que vous pouvez justifier en post‑mortem.

9) Why can’t I reach a device on the remote LAN from a ZeroTier client?

Généralement absence de chemin de retour. Vous avez ajouté une route gérée, mais l’appareil LAN distant ne sait pas comment répondre au sous‑réseau de la superposition.
Corrigez avec une route de retour sur le routeur LAN, ou NAT sur la gateway (en connaissant les implications pour l’auditabilité et le dépannage).

10) Is UDP 9993 always required?

Le comportement courant de ZeroTier repose sur UDP. Si UDP est bloqué, vous pouvez voir une connectivité dégradée ou nulle.
Parfois vous pouvez vous débrouiller via des relays, mais sur un réseau qui bloque massivement l’UDP sortant, attendez‑vous à des problèmes.

Prochaines étapes à réaliser aujourd’hui

1. Cessez de prendre le ping pour l’oracle. Décidez ce que « up » signifie pour votre service, et testez cela.
2. Standardisez votre plan d’adressage de superposition. Si vous avez déjà des chevauchements, planifiez une migration avant qu’elle ne vous soit imposée.
3. Mettez en base la santé des peers. Enregistrez combien de peers sont DIRECT vs RELAY en fonctionnement normal.
4. Notez votre ordre de « diagnostic rapide ». Mettez‑le dans le runbook d’astreinte, pas dans la tête de quelqu’un.
5. Rendez explicite la politique de pare‑feu. Autorisez ce dont vous avez besoin sur l’interface ZeroTier ; refusez le reste ; documentez l’intention.
6. Ajoutez un test MTU à votre boîte à outils. La plupart des équipes découvrent les problèmes MTU seulement après avoir perdu une journée. Soyez meilleurs que ça.

Si vous faites ces six choses, « impossible de pinguer » devient un problème de classification en deux minutes au lieu d’une spirale de trois heures pour trouver des coupables.
C’est la différence entre une superposition soignée et un hobby coûteux.