Le nœud de sortie ZeroTier ne fonctionne pas ? Vérifiez la route, le NAT et le client

La table de routage affiche une route par défaut via l’interface ZeroTier, le réseau se déclare en ligne et le navigateur sort toujours par l’adresse locale du fournisseur. Cette combinaison est courante et ce n’est pas un bug du client. Une route par défaut indique seulement où les paquets doivent aller ; quelque chose doit les transmettre et les traduire à l’autre bout. Trois parties distinctes doivent être vraies avant qu’un nœud de sortie fonctionne.

La route existe mais rien ne sort

Vérifiez d’abord la table de routage du client. Une ligne comme default via 10.147.20.5 dev zt0 prouve que la route a été installée, pas que la destination acceptera le trafic. Le prochain saut doit être un membre disposé et capable de la transmettre.

Si la même requête sort encore par l’interface physique, le client n’a pas installé la route, ou l’a installée avec une métrique qui a perdu contre la route par défaut locale. Si la requête disparaît après l’installation de la route, le membre de sortie reçoit les paquets et échoue à les transmettre ou à les traduire. Un client qui conserve la route par défaut physique n’envoie aucun paquet à la sortie.

Cette distinction décide où travailler. Comparer une adresse publique avant et après la modification sépare une route jamais utilisée d’une route utilisée puis rejetée, et ne demande qu’une commande au lieu d’une revue de toute la configuration. Faites la comparaison avant de changer autre chose, afin que les deux résultats partent du même état initial.

Trois parties qui doivent toutes être vraies

Une sortie est une chaîne, et le maillon le plus faible détermine le symptôme. Le tableau ci-dessous liste les maillons dans l’ordre où ils échouent habituellement.

La première ligne est celle que le nom de l’option cache. Un membre ne devient une sortie que lorsque son noyau transmet des paquets entre l’interface ZeroTier et l’interface tournée vers Internet, et lorsque le chemin de retour est traduit vers le tunnel. Sans cette transmission, le membre est un pair, pas une passerelle.

La ligne du contrôleur est une autorisation, pas une configuration. Annoncer 0.0.0.0/0 via un membre indique à chaque client où se trouve la sortie ; cela ne rend pas ce membre capable de porter le trafic. Cela ne vérifie pas non plus que le membre dispose d’un chemin fonctionnel vers Internet. La documentation ZeroTier sur le nœud de sortie couvre la même séparation entre nœud, route et client.

Configurez le nœud de sortie pour transmettre et traduire

Activez la transmission IPv4 de façon persistante, puis ajoutez un NAT source pour le trafic quittant l’interface WAN. Les règles de filtrage doivent autoriser le flux transmis dans les deux sens, car la transmission et la traduction sont distinctes de l’autorisation :

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i zt0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o zt0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Remplacez zt0 et eth0 par les noms de l’hôte ; une règle enregistrée pour une interface d’exemple ne suit pas les paquets sur une interface réelle. Rendez les changements persistants via le gestionnaire de pare-feu qui possède les règles, car une commande dans un shell interactif disparaît au prochain redémarrage.

Si l’hôte exécute un gestionnaire de pare-feu comme UFW ou firewalld, ajoutez les règles via ce gestionnaire au lieu d’empiler des lignes iptables à côté. Deux propriétaires qui modifient les mêmes chaînes produisent une politique qui dépend de l’ordre de démarrage. L’ordre compte lorsque le gestionnaire génère ses propres chaînes. Testez depuis un client après avoir rechargé le gestionnaire, pas avant.

Annoncez la route et acceptez-la sur le client

Sur le contrôleur réseau, ajoutez une route gérée pour 0.0.0.0/0 dont le prochain saut est l’adresse ZeroTier du membre de sortie. Puis, sur le membre qui doit l’utiliser, autorisez le contournement pour ce réseau. L’autorisation est locale : elle ne reconfigure pas les autres membres et ne change pas le contrôleur.

zerotier-cli listnetworks
zerotier-cli set <network-id> allowDefault=1
ip route get 1.1.1.1

La dernière commande doit signaler l’interface ZeroTier et l’adresse du membre de sortie. Si elle signale encore l’interface physique, la route manque ou une route par défaut concurrente a une meilleure métrique.

Gardez le réglage limité au réseau qui en a besoin. Activer l’acceptation de la route par défaut globalement, ou sur un réseau qui ne doit fournir qu’un sous-réseau privé, envoie le trafic par une sortie qui n’a jamais été dimensionnée pour cela.

Vérifiez la sortie et contrôlez les autres familles d’adresses

Demandez une adresse publique à un service qui indique la source, et comparez-la à l’adresse WAN du nœud de sortie. Chargez ensuite un site nommé pour confirmer que le DNS résout encore, et testez une application importante plutôt qu’un simple navigateur.

Un client double pile peut continuer d’utiliser son chemin IPv6 natif pendant qu’IPv4 sort par ZeroTier. Si l’objectif est de masquer ou de contrôler tout le trafic, une route ::/0 séparée et la transmission IPv6 sur la sortie sont nécessaires, et un test IPv4 n’en dit rien.

Le filtrage de chemin inversé de Linux peut aussi rejeter du trafic de sortie valide sur le client. ZeroTier documente une considération rp_filter pour les membres participants ; modifiez ce réglage délibérément et seulement après confirmation de la route et du NAT, pas comme première expérience.

Si le besoin est l’accès à un NAS ou à un sous-réseau de bureau, une route gérée pour ce préfixe est un changement plus petit et plus sûr qu’une sortie complète. Faire passer toute la navigation par un autre appareil est une décision différente d’atteindre une ressource privée, et elle mérite une revue distincte.