ZeroTier vers un LAN : des règles de route UFW, pas une autorisation de port

Atteindre une imprimante du LAN du bureau via un membre ZeroTier ressemble à une seule règle, et c’est en réalité trois décisions à trois endroits différents. La superposition doit savoir où se trouve le LAN, l’hôte Linux doit accepter de transférer les paquets, et le LAN doit savoir comment renvoyer la réponse. Une règle entrante qui ouvre un port sur la passerelle ne touche à aucune de ces choses. C’est le mauvais outil appliqué au bon hôte.

Trois tâches, trois responsables

La route gérée appartient à la configuration du réseau ZeroTier. Elle indique aux membres qu’un préfixe est joignable via l’adresse d’un membre donné.

Le transfert appartient au noyau Linux et à ce qui possède sa politique de pare-feu. Il décide si un paquet arrivant sur la superposition ressort par l’interface physique. Un hôte qui ne transfère pas ignorera silencieusement le paquet après l’avoir accepté. L’émetteur voit un délai dépassé et rien n’apparaît dans le journal du service.

Le chemin de retour appartient au LAN. Ses hôtes et son routeur doivent savoir que le préfixe de superposition est joignable via l’adresse LAN de votre passerelle, ou bien quelque chose doit traduire le trafic pour que la question ne se pose jamais.

Chacune de ces parties peut être correcte alors que les autres échouent, et c’est pourquoi un test qui ne fait que pinguer la passerelle ne prouve rien sur le service derrière elle.

Pointez la route gérée vers le membre

Ajoutez une route pour le préfixe LAN voulu via l’adresse de superposition de la passerelle, et non via son adresse LAN. L’adresse de superposition est celle que les autres membres peuvent joindre ; l’adresse LAN n’a de sens que sur le câble.

Les membres doivent accepter les routes gérées pour que la conception fonctionne, et leurs propres réseaux locaux ne doivent pas déjà utiliser le préfixe que vous annoncez. Un portable distant qui se trouve chez lui sur 192.168.60.0/24 ne peut pas non plus router 192.168.60.0/24 via la superposition.

Gardez le préfixe annoncé aussi étroit que la tâche le permet. Annoncer un agrégat plus large pour influencer la préférence peut aussi revendiquer un espace d’adressage que vous ne possédez pas, et le conflit qui en résulte apparaît sur les appareils connectés aux deux réseaux. Cela peut aussi amener un membre à préférer un chemin qui ne mène nulle part. Gardez la route honnête et laissez la politique faire le reste.

Écrivez le préfixe et l’adresse du membre dans la même note que les règles de pare-feu, car la panne la plus courante est une route pointant vers le mauvais membre.

Activez le transit dans le noyau

Lisez la valeur de transfert en cours avant de changer quoi que ce soit, puis rendez le réglage permanent via le mécanisme que votre système utilise déjà, et non via une commande ponctuelle qui disparaît au redémarrage.

Si UFW possède la politique, ses règles de route expriment le transfert pour un couple de source, de destination et d’interface. Elles sont distinctes des règles entrantes qui ouvrent un service sur la passerelle elle-même :

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

Le nom de l’interface est le périphérique de superposition réel sur cet hôte, que vous pouvez lire avec ip link ; ce n’est pas une chaîne fixe d’une installation à l’autre. Si l’hôte transfère par défaut et qu’UFW n’est pas sur le chemin, la règle de route sera ignorée et ce sont les réglages du noyau qui comptent.

Choisissez comment les réponses reviennent

Avec la préservation de la source, le service du LAN voit la véritable adresse de superposition et y répond. Cela exige une route sur l’hôte du LAN ou sur son routeur pointant le préfixe de superposition vers votre passerelle, et c’est un changement hors de la machine Linux.

Quand cette route ne peut pas être ajoutée, une traduction de source limitée fait ressembler la requête à une requête venant de la passerelle sur le LAN. Les réponses reviennent alors localement et aucun changement de routage du LAN n’est nécessaire, au prix de la perte de la source d’origine dans les journaux du service.

Limitez la traduction à la source de superposition et à la destination LAN précise. Traduire tout ce qui quitte l’interface LAN est la version large qui surprend ensuite quiconque lit les règles, et elle masque aussi du trafic qui aurait dû être bloqué.

Aucun des deux choix n’accorde un accès non sollicité depuis le LAN vers des membres de superposition arbitraires. Si cela est souhaité, c’est une règle séparée avec sa propre revue.

Testez depuis un vrai membre

Connectez-vous depuis un autre membre, pas depuis la passerelle, et demandez un service autorisé. Essayez ensuite un service qui doit rester fermé, et répétez les deux tests après une reconnexion et après un redémarrage de la passerelle.

Un membre qui signale ONLINE, ou un ping réussi vers l’adresse de superposition de la passerelle, ne valide ni la route, ni la règle de transfert, ni le chemin de retour :

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

La deuxième commande montre quelle interface le paquet utiliserait pour l’hôte du LAN, et la troisième si la règle de route existe sous la forme que vous vouliez. Si les deux semblent corrects et que le service expire encore, le chemin de retour est le suspect restant.