HTTP sur ZeroTier est-il chiffré ? Vérifiez où s'arrête l'overlay

Suivez ces vérifications dans l'ordre et arrêtez-vous à la première qui échoue, car chaque réponse change ce que signifie l'étape suivante. La vraie question est étroite : le HTTP simple sur un réseau ZeroTier circule-t-il en clair sur internet ? Entre deux pairs ZeroTier, généralement non, car l'overlay chiffre ce saut. Mais cela concerne deux extrémités, pas chaque segment traversé par une requête. Un routeur, un pont ou un proxy inverse déplace l'extrémité, et le texte en clair reprend de l'autre côté.

Vérification 1 : trouvez l'adresse que le navigateur joint

Comparez l'URL à ce que la machine possède réellement. ip -brief addr show liste l'interface zt et l'adresse overlay attribuée par le contrôleur réseau ; si l'URL utilise cette adresse, la socket du navigateur entre dans l'overlay.

Quand le nom se résout plutôt vers une adresse LAN, l'overlay peut n'avoir aucun rôle, quoi qu'en suggère l'indicateur d'état du client. ip route get 10.147.20.5 affiche l'interface et l'adresse source que le noyau choisirait, donc une interface zt à cet endroit signifie que le paquet entre dans l'overlay, et le nom de votre carte réseau physique signifie qu'il n'y entre pas. Les noms ajoutent une couche : un enregistrement pointant vers une adresse overlay se comporte différemment d'un enregistrement pointant vers une adresse LAN, et un suffixe de recherche ou une entrée du fichier hosts peut décider en silence laquelle vous obtenez.

Vérification 2 : confirmez que les deux extrémités sont des pairs, pas un relais qui déchiffre

ZeroTier chiffre entre pairs, et là où aucun chemin direct n'existe, les paquets transitent par une racine qui les transmet toujours chiffrés. zerotier-cli peers marque le chemin de chaque pair comme DIRECT ou RELAY avec une latence. Un chemin relayé coûte des allers-retours, pas la confidentialité.

Ce qui change vraiment la réponse, c'est un membre qui n'est pas réellement une extrémité. Quand l'autre côté est un membre ZeroTier qui route ou pont vers un LAN physique, l'overlay s'arrête à ce membre et le saut suivant est de l'Ethernet ordinaire.

Vérification 3 : regardez où la requête devient lisible

Sur l'hôte que vous croyez servir la page, capturez l'interface overlay pendant le rechargement : sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. Une ligne de requête lisible dans cette sortie prouve que le trafic est arrivé déchiffré sur cet hôte, et c'est la frontière que vous cherchez.

Capturez ensuite sur l'interface tournée vers le reste du LAN. Si la même requête y apparaît en clair, elle a quitté l'overlay avant d'atteindre l'application et tout appareil de ce segment peut la lire. Si rien n'apparaît côté LAN et que la page se charge quand même, l'application se termine sur l'hôte ZeroTier lui-même.

Capturer le loopback compte aussi quand un proxy inverse se trouve devant, car un proxy qui accepte HTTPS et transmet HTTP déplace la frontière vers son propre backend.

Vérification 4 : comptez chaque saut derrière un routeur ou un pont

Un membre configuré pour router entre l'overlay et un LAN est un choix ordinaire et l'endroit où la plupart de ces hypothèses se brisent. L'overlay protège le segment du navigateur au routeur et rien après. Un pont raconte la même histoire par un autre mécanisme : l'overlay et le segment physique forment un seul domaine de diffusion, si bien qu'une requête venue d'un portable ponté traverse de l'Ethernet ordinaire alors même que ce portable est sur le réseau ZeroTier.

Tracez-le au lieu de le supposer. traceroute du client vers l'adresse du service, plus la table de routage sur le membre passerelle, montrent si le dernier saut est zt ou eth.

ZeroTier propose aussi un mode de chemin de confiance qui peut abandonner la sécurité du transport sur des chemins locaux désignés pour la performance. Un réseau qui l'utilise n'hérite pas de l'hypothèse habituelle de chemin chiffré, alors lisez la configuration du réseau avant d'en citer un. La documentation du protocole décrit à la fois le chiffrement entre pairs et cette exception.

Vérification 5 : décidez ce que l'application doit encore faire

L'appartenance à l'overlay authentifie un appareil auprès d'un réseau et ne dit rien sur le fait que le service d'en face soit celui que vous vouliez joindre. HTTPS répond à une autre question en liant un nom d'hôte à une clé, si bien que les deux protections se recouvrent sans se remplacer. Un pair autorisé peut toujours être le mauvais service, et une extrémité compromise lit la requête avant le chiffrement comme après le déchiffrement. Aucun des deux mécanismes n'audite ce que l'application enregistre.

Pour tout ce qui a une session réutilisable ou un mot de passe, terminez TLS dans l'application ou dans un proxy que vous contrôlez et laissez la validation des certificats active. Là où un service ancien doit rester en HTTP simple, notez le chemin exact d'hôte à hôte qu'il peut emprunter, qui peut l'atteindre et quel segment reste non protégé ; cette note est ce dont un futur relecteur aura besoin.

"Le VPN est connecté" n'est pas une évaluation de tout cela. La version honnête nomme les deux extrémités, le chemin entre elles et le premier saut qui n'est pas couvert.

Gardez la sortie de capture et la liste des pairs à côté de la documentation du service, pour que quiconque change une route ou ajoute un pont voie quelle hypothèse il est sur le point de briser.