La Fin du Relais Public : Migration vers des Tunnels Localhost Zero-Trust

Arrêtez de diffuser vos APIs locales non authentifiées sur Internet. Découvrez comment les fabrics de tunneling Zero-Trust exigent des vérifications d’identité cryptographiques avant qu’un paquet n’atteigne votre machine.

---

Depuis plus d’une décennie, les développeurs et ingénieurs réseau utilisent des outils de relais publics pour contourner les pare-feu stricts, le Carrier-Grade NAT (CGNAT) et les restrictions réseau locales. Si vous deviez montrer une application web locale à un client, tester un webhook d’un fournisseur de paiement tiers, ou collaborer sur une base de données locale, le workflow était simple : lancer un outil comme ngrok, récupérer l’URL publique aléatoire, et partager.

Cependant, à l’aube de 2026, l’époque où l’on envoyait une URL publique aléatoire à un client ou une suite de tests touche à sa fin. Le paysage numérique est devenu trop hostile, et les surfaces d’attaque automatisées sont devenues trop sophistiquées pour se fier à la sécurité par l’obscurité. Le paradigme legacy d’ouvrir un trou depuis Internet directement vers localhost est remplacé par des réseaux Zero Trust basés sur l’identité.

Dans ce guide, nous explorerons pourquoi le relais public est en voie de disparition, plongerons dans le fonctionnement du tunneling Zero-Trust, examinerons pourquoi les outils basés sur OpenZiti (comme Zrok) deviennent la alternative définitive à ngrok, et montrerons comment le partage privé de localhost redéfinit les workflows des développeurs.

---

1. L’anatomie d’un relais public (et pourquoi il est obsolète)

Pour comprendre la révolution, il faut d’abord connaître le système legacy. Les outils de tunneling traditionnels fonctionnent selon une architecture de “Relais Public”.

Lorsqu’un développeur exécute une commande pour exposer un port local (par exemple, le port 8080), un agent léger sur sa machine initie une connexion TCP sortante vers un serveur cloud centralisé géré par le fournisseur de tunneling. Ce dernier génère alors un sous-domaine accessible publiquement (comme random-string.tunnel-provider.com) et le lie à cette connexion. Tout le trafic atteignant cette URL publique est redirigé via le tunnel établi directement vers la machine locale du développeur.

La fallacie de la sécurité par l’obscurité

Historiquement, les développeurs pensaient que, puisque l’URL était une chaîne aléatoire, elle était pratiquement impossible à deviner et donc sécurisée. En 2026, c’est une erreur dangereuse.

Les cybercriminels modernes déploient des botnets de scan distribués qui surveillent en temps réel les logs de Certificate Transparency (CT). Les logs CT sont accessibles publiquement, enregistrements en mode append-only de tous les certificats SSL/TLS émis par des autorités de certification de confiance — un système initialement conçu pour la responsabilité des certificats, mais de plus en plus exploité comme outil de reconnaissance. Fin 2025, Let’s Encrypt émettait seul dix millions de certificats par jour, protégeant plus de 550 millions de sites, faisant des logs CT une source extrêmement riche d’intelligence de menace et de découverte de surface d’attaque. Dès qu’un fournisseur de tunneling legacy fournit un certificat SSL/TLS pour un nouveau sous-domaine aléatoire, des bots automatisés peuvent scraper l’URL et commencer à la sonder pour des vulnérabilités courantes — souvent dans les minutes suivant la mise en ligne du tunnel.

En 2026, avec plus de 8,2 milliards de certificats enregistrés dans divers systèmes CT, ces bases de données offrent aux attaquants une fenêtre sans précédent sur l’infrastructure numérique de toute organisation, bien au-delà de l’énumération traditionnelle de sous-domaines. Si vous exposez une base de données de développement non authentifiée, une interface de débogage avec exécution de code à distance (RCE) activée, ou une API sans limitation de débit, la fenêtre d’exposition commence dès que votre tunnel est provisionné.

La question de confiance

De plus, les tunnels traditionnels fonctionnent sur une confiance centrée sur le réseau. Le pare-feu est totalement contourné. La frontière du réseau — le point où le trafic est accepté ou rejeté — se trouve sur Internet public, sur les serveurs du fournisseur, et non sur votre machine. Lorsqu’un payload malveillant atteint localhost, il a déjà contourné vos défenses périmétriques.

---

2. Entrée dans le tunneling Zero-Trust

La réponse de l’industrie de la cybersécurité à cette vulnérabilité est l’adoption massive de l’architecture Zero Trust. Si Zero Trust a été un mot à la mode pour remplacer les VPN d’entreprise depuis des années, 2026 marque son entrée complète dans l’écosystème des outils pour développeurs, sous forme de tunneling Zero-Trust pour les workflows quotidiens.

Déplacer le périmètre vers l’identité

Dans un réseau Zero Trust, il n’existe pas d’URL publique. Il n’y a pas de port ouvert sur Internet. Le concept de “connexion à un réseau” est entièrement remplacé par “connexion à une identité.”

Au lieu de générer un relais public accessible à tous, un tunnel Zero-Trust crée une superposition privée en mesh. Pour partager un service local, vous ne recevez pas une URL ; vous recevez un jeton d’authentification cryptographique. L’utilisateur ou le service distant doit utiliser un agent propre, fournissant ce jeton, pour prouver mathématiquement son identité avant même de pouvoir faire transiter un paquet via le réseau en superposition.

Si un scanner non autorisé tente de sonder le service, il ne reçoit rien — pas d’erreur 403 Forbidden, rien du tout. Le service est pratiquement invisible sur Internet. C’est ce qu’on appelle “Dark Infrastructure.” Zéro port d’écoute signifie zéro surface d’attaque. Les clients autorisés se connectent via la superposition ; tous les autres ne voient rien.

---

3. OpenZiti : La toile des réseaux d’identité-native

Au cœur de cette transformation se trouve OpenZiti, une plateforme open-source de réseautage Zero Trust créée et soutenue par NetFoundry. Sous licence Apache 2.0, OpenZiti n’est pas seulement un outil de tunneling ; c’est un réseau en superposition programmable qui rend les services invisibles aux utilisateurs non autorisés.

Chaque connexion dans un réseau OpenZiti — qu’il s’agisse d’un utilisateur humain, d’un microservice ou d’un appareil IoT — est authentifiée via une identité cryptographique, autorisée par un contrôleur de politique centralisé, et chiffrée de bout en bout selon des standards modernes incluant le mTLS (Mutual Transport Layer Security).

OpenZiti fonctionne avec des applications existantes utilisant des tunnelers légers (aucun changement de code requis) et avec de nouvelles applications intégrant des SDK pour le modèle Zero Trust le plus robuste. Cela le rend pratique aussi bien pour des environnements legacy que pour du développement greenfield. En 2026, l’adoption croît car le zero trust passe du langage de politique d’entreprise à la conception d’infrastructure contrôlée par les développeurs : équipes distribuées, infrastructure hybride, et trafic machine-à-machine rendent la sécurité périmétrique moins efficace que jamais.

Les trois piliers du déploiement OpenZiti

OpenZiti supporte les organisations à travers trois phases distinctes d’adoption du zero-trust :

ZTNA (Zero Trust Network Access) : Le modèle le plus traditionnel. Un routeur Edge OpenZiti est placé dans une zone de réseau de confiance. Les utilisateurs se connectent au routeur via la superposition Zero-Trust, qui redirige le trafic vers le LAN interne. Mieux qu’un VPN, la confiance reste sur le segment réseau local.

ZTHA (Zero Trust Host Access) : Dans ce modèle, un tunneler OpenZiti fonctionne directement sur la machine hôte du service. Le pare-feu de l’OS de l’hôte est configuré pour refuser par défaut tout trafic entrant. Le service n’est accessible que via localhost, et le tunneler intercepte et route le trafic autorisé de la superposition directement vers lui. Cela élimine la mobilité latérale east-west sur le réseau. Pour le tunneling développeur, ce modèle offre le meilleur compromis entre sécurité et simplicité sans modification de code.

ZTAA (Zero Trust Application Access) : Le saint Graal du réseautage sécurisé. En intégrant un SDK OpenZiti (disponible en Go, Python, C, Java, Node.js, et plus) directement dans le code de l’application, celle-ci détient l’identité cryptographique. Elle ne se lie à aucun port réseau — même pas localhost. La communication de l’application se fait entièrement dans l’espace mémoire Zero Trust.

Le plan de gestion se cuisine lui-même

Une avancée majeure début 2026 : à partir d’OpenZiti 1.8, les API du contrôleur peuvent elles-mêmes se lier en tant que services OpenZiti. Le même zéro-trust intégré à l’application qui sécurise vos applications sécurise désormais aussi le plan de gestion. C’est une étape architecturale importante — cela signifie que le canal de contrôle régissant tout le réseau en superposition est soumis à la même vérification d’identité cryptographique que les charges de travail qu’il gère, fermant une classe de vecteurs d’attaque qui nécessitaient auparavant un durcissement séparé.

---

4. Zrok : L’outil de tunneling OpenZiti-native pour développeurs

Alors qu’OpenZiti fournit la base de niveau entreprise, la mise en place d’une superposition complète nécessite une infrastructure. C’est ici qu’intervient Zrok. Construit directement sur la toile OpenZiti et développé par NetFoundry, Zrok est conçu spécifiquement pour être l’outil de tunneling incontournable pour les développeurs dans ce nouveau paradigme.

Zrok prend les capacités complexes et puissantes d’OpenZiti et les emballe dans une expérience CLI simple et fluide, adaptée aux développeurs, testeurs, et équipes opérationnelles.

Partages publics vs. Partages privés

Zrok reconnaît qu’il y a des moments où vous devez avoir une URL publique — par exemple, lorsqu’un fournisseur de webhook tiers comme GitHub, Stripe ou Twilio requiert un endpoint HTTPS standard. Pour ces scénarios, Zrok propose zrok share public, qui provisionne une URL publique sécurisée et éphémère. La backbone OpenZiti de Zrok garantit que pour les partages privés, aucun endpoint public n’est créé : la connexion n’existe qu’entre participants authentifiés dans la superposition.

Mais la vraie force de Zrok réside dans sa fonctionnalité phare : le partage privé de localhost.

Mécanique du partage privé de localhost

Lorsqu’un développeur initie un partage privé :

zrok share private localhost:8080

Zrok n’expose pas le service à Internet. À la place, l’agent local Zrok établit une connexion sortante à la superposition OpenZiti et génère un jeton de partage cryptographique unique (par exemple, share_token_xyz123).

Le développeur transmet ce jeton en toute sécurité au destinataire prévu, qui exécute :

zrok access private share_token_xyz123

Son agent local s’authentifie auprès du réseau en utilisant le jeton, lie dynamiquement un port local sur sa machine (par exemple, localhost:9191), et établit une connexion chiffrée de bout en bout avec la machine du développeur d’origine. Lorsqu’il navigue vers http://localhost:9191, le trafic est routé de manière transparente via la superposition Zero-Trust.

Le résultat :

• Aucun port de pare-feu n’a été ouvert
• Aucun enregistrement DNS public n’a été créé
• Aucun scanner automatisé ne peut détecter la transaction
• La surface d’attaque est pratiquement nulle

Modes backend

Le partage privé de Zrok supporte plusieurs modes backend pour différents workflows :

• tcpTunnel — tunnelise des ports TCP spécifiques entre hôtes ; idéal pour accéder à un service précis sur une machine distante (ex : SSH : zrok share private --backend-mode tcpTunnel localhost:22)
• udpTunnel — tunnel UDP complet pour applications en temps réel
• socks — crée un proxy SOCKS5 pour le forwarding dynamique de ports vers plusieurs destinations via un seul partage, utile pour accéder à plusieurs services sur un réseau distant
• drive — transforme n’importe quel répertoire local en un serveur de fichiers sécurisé et partageable via la superposition Zero-Trust ; partagez logs, binaires, ou assets directement depuis votre disque dur sans stockage cloud

22 Note sur le mode VPN :** Une ancienne fonctionnalité --backend-mode vpn a été introduite pour le tunneling VPN hôte-à-hôte, mais a été retirée dans la version v1.1.11 à cause de conflits de dépendances avec les librairies principales de zrok. L’équipe Zrok explore une réintroduction de la fonctionnalité VPN sous forme d’outil autonome (zrok-vpn). En attendant, les modes tcpTunnel et socks couvrent la majorité des cas d’usage que le mode VPN adressait.

Domaines personnalisés

Zrok supporte désormais les domaines personnalisés, permettant aux organisations de provisionner des partages sous leur propre nom de domaine (<token>.your.domain.co) plutôt qu’un sous-domaine générique du fournisseur. Cela est crucial pour les équipes nécessitant des endpoints cohérents et brandés pour les tests d’intégration tout en conservant la sécurité Zero-Trust.

---

5. Au-delà de HTTP : Tunnels éphémères et Protocoles avancés

Les tunnels legacy étaient fortement optimisés pour le trafic web HTTP/HTTPS. En 2026, le développement moderne exige beaucoup plus de flexibilité.

Support natif TCP et UDP

Le tunneling TCP et UDP natif de Zrok constitue un avantage pratique pour plusieurs disciplines :

Jeux et médias en temps réel : La prise en charge UDP permet de partager en privé des serveurs de jeux, applications VoIP, et flux WebRTC avec une latence ultra-faible, sans se battre avec des configurations complexes de port forwarding.

Administration de bases de données : Un administrateur peut partager en toute sécurité un flux TCP brut d’une instance locale PostgreSQL ou Redis avec un data scientist distant, en utilisant un jeton privé. Les données restent entièrement chiffrées de bout en bout, respectant des normes comme HIPAA ou SOC2.

IoT et développement Edge : Des outils comme le NVIDIA Jetson Orin Nano (offrant 40 TOPS de performance AI dans un module compact) sont courants en développement AI et robotique en edge — mais le développement nécessite traditionnellement une proximité physique. Zrok apporte une identité cryptographique à chaque appareil sur le tunnel : si un capteur est compromis, vous pouvez révoquer son accès instantanément sans toucher à la configuration réseau.

Éphémérité et réduction du rayon d’attaque

En cybersécurité moderne, la permanence est l’ennemi. Plus un tunnel reste actif longtemps, plus le risque est élevé. Zrok adopte l’éphémérité par conception. Les partages privés ne doivent exister que pour la durée précise d’une tâche. Une fois un webhook testé ou une revue de code terminée, le tunnel est détruit. Le jeton cryptographique devient inutilisable, coupant instantanément la connexion et minimisant le rayon d’attaque potentiel.

---

6. Workflows avancés : Pentesting et hacking éthique

Le passage au partage privé de localhost a profondément impacté la communauté cybersécurité, notamment les Red Teams et pentesters.

Lors d’une mission autorisée, les hackers éthiques doivent souvent capter des reverse shells ou recevoir des callbacks via des frameworks comme Metasploit ou BeEF. Historiquement, ils devaient ouvrir des ports entrants sur leur infrastructure d’attaque ou utiliser des relais publics — exposant leur écouteur de reverse à des parties non autorisées sur Internet.

Avec Zrok, un hacker éthique peut lier son écouteur à 127.0.0.1, créer un partage privé, et générer un jeton temporaire. Cela leur permet de recevoir des callbacks via un réseau en superposition sécurisé et authentifié, contournant totalement les règles strictes de pare-feu sortant sur le réseau cible, tout en empêchant toute tierce partie de prendre le contrôle de leur infrastructure C2. L’écouteur reste invisible sur Internet pendant toute la durée de l’engagement.

---

7. Connectivité des agents IA : un cas d’usage émergent

Une des évolutions les plus intéressantes de 2026 dans l’écosystème OpenZiti est l’émergence de connectivité Zero-Trust pour les workloads d’agents IA. NetFoundry a publié un ziti-mcp-server — un serveur MCP (Model Context Protocol) exposant plus de 200 outils de gestion Ziti. Cela permet aux agents IA de gérer identités, services, routeurs, et politiques dans un réseau OpenZiti via les mêmes primitives Zero-Trust que pour tout le reste.

OpenZiti a aussi publié une passerelle Zero-Trust pour LLM : un proxy compatible OpenAI avec routage sémantique et équilibrage de charge entre OpenAI, Anthropic, Ollama, vLLM, et autres backends. L’accès basé sur l’identité, les clés API virtuelles, et le chiffrement de bout en bout sont appliqués via OpenZiti, rendant même le trafic d’inférence IA opaque à Internet. Cela indique une tendance plus large : à mesure que les workloads IA communiquent de plus en plus via des API entre machines distribuées, les mêmes principes Zero-Trust qui régissent le tunneling pour développeurs régiront la connectivité IA machine-à-machine.

---

8. Souveraineté des données et auto-hébergement

Alors qu’une version SaaS gérée de Zrok est proposée par NetFoundry sur zrok.io avec un généreux niveau gratuit, la priorité pour les organisations en industries réglementées est la souveraineté des données.

Parce que Zrok et sa toile OpenZiti sont entièrement open-source (licence Apache 2.0), les organisations peuvent héberger elles-mêmes la plateforme via Docker. En déployant leurs propres routeurs Edge OpenZiti et contrôleurs Zrok dans leur infrastructure cloud ou data center local, elles conservent la propriété complète des métadonnées de routage, clés cryptographiques, et identités utilisateur. L’auto-hébergement via Docker avec Caddy permet le renouvellement automatique des certificats wildcard et protège l’API Zrok et les partages publics avec TLS — sans dépendre d’un relais tiers.

Le déploiement auto-hébergé n’impose aucune limite de bande passante ou de calcul, et aucune tierce partie n’a accès à vos données. Cette capacité est essentielle pour les organisations en finance, santé, et défense qui sont légalement interdites de faire transiter leur trafic interne par un relais cloud multi-locataires.

---

9. Naviguer sur le marché alternatif 2026

La demande pour un tunneling sécurisé a stimulé une compétition intense. Voici une comparaison honnête de la position de chaque outil :

Cloudflare Tunnels (cloudflared) : Un service de tunneling HTTP performant, intégré à la plateforme Zero Trust de Cloudflare pour la gestion des accès, la journalisation, et la protection DDoS — et c’est gratuit sans limite de bande. Cependant, il nécessite que votre domaine soit dans l’écosystème DNS de Cloudflare, ne supporte pas UDP, limite la taille des corps de requête, et est uniquement TCP sur plans payants.

ngrok : Le géant legacy. Très abouti, avec d’excellentes fonctionnalités d’inspection de webhook. Reste principalement un outil basé sur URL publique, cible privilégiée des scanners automatisés. Son modèle tarifaire pour les fonctionnalités professionnelles (SSO, etc.) est élevé, et l’architecture de relais public expose au problème des logs CT.

Tailscale / WireGuard : Parfaits pour connecter des appareils connus et permanents en mesh VPN. Mais ce sont des solutions lourdes, peu adaptées aux workflows éphémères et ad-hoc “partagez ce port pendant cinq minutes”. Ils nécessitent aussi l’installation d’un client sur chaque pair à l’avance.

Bore : Strictement TCP, minimaliste, open-source, sans dépendance d’infrastructure. Bon pour des cas simples mais sans fonctionnalités HTTP, authentification, ou UDP.

Zrok (OpenZiti) : Comble le gap. Il offre la commodité éphémère et ad-hoc d’ngrok, mais avec le modèle de sécurité Zero-Trust basé sur l’identité d’un réseau mesh complet comme Tailscale — tout en restant open-source, capable de gérer UDP/TCP et le partage de fichiers, et auto-héritable. La difficulté initiale est plus grande comparée à ngrok http 8080, surtout en auto-hébergement complet de l’infrastructure OpenZiti.

---

Conclusion : Cessez de diffuser, commencez à authentifier

L’internet a changé fondamentalement. La période où l’on considérait les réseaux internes comme “de confiance” et l’extérieur comme “non fiable” est révolue. La confiance n’est plus une propriété géographique ou réseau — elle doit être prouvée cryptographiquement par l’identité du demandeur.

En migrant vers des plateformes de tunneling Zero-Trust comme Zrok, les développeurs adoptent le futur de la collaboration sécurisée. La transition des URLs publiques aléatoires vers un partage privé et authentifié de localhost neutralise efficacement le paysage de menace automatisé : pas d’URL publique à scanner, pas de port à sonder, pas d’entrée dans les logs CT à récolter. La décision d’OpenZiti 1.8 de mettre le plan de gestion sous contrôle Zero-Trust indique que l’écosystème mûrit, dépassant la simple commodité pour devenir une infrastructure prête pour la production.

Alors que les workloads IA, les appareils en edge, et les équipes distribuées rendent la frontière du réseau de plus en plus abstraite, la leçon reste la même : fermez vos ports entrants, adoptez le dark network, et assurez-vous que chaque paquet touchant votre machine soit cryptographiquement vérifié avant même d’atteindre votre application.

---

Sources : OpenZiti Tech Blog ; Documentation NetFoundry ; Better Stack Community ; Startupik ; Have I Been Squatted CT Log Analysis (mars 2026) ; Secybers OSINT Guide (mars 2026) ; fxTunnel Blog (février 2026) ; GitHub — openziti/zrok ; GitHub — openziti/ziti.