Contrôle complet des données : tunnels en auto-hébergement avec frp, Zrok et Inlets

1. L’impératif de souveraineté des données dans le DevOps moderne

La souveraineté des données signifie que les données numériques sont soumises aux lois et structures de gouvernance de la juridiction où elles sont collectées et traitées. Pour les reverse proxies et tunnels réseau, cela implique de garder le contrôle sur les chemins physiques et virtuels que prennent vos données.

Le problème avec les tunnels SaaS. Les services de tunneling commerciaux installent un client léger sur votre machine, qui ouvre une connexion sortante vers un relais centralisé, appartenant au fournisseur. Ce dernier vous fournit une URL publique qui route le trafic via leur infrastructure vers votre service local. C’est pratique, mais cela comporte des compromis pour les équipes réglementées :

• Exposition des métadonnées : même avec un chiffrement de bout en bout, les métadonnées de connexion (IPs, timing, tailles de payload) sont visibles par le fournisseur.
• Risque de conformité : les secteurs de la santé, de la finance ou gouvernementaux ne peuvent souvent pas légalement faire transiter des données internes via une infrastructure multi-locataires tierce.
• Dépendance au fournisseur : vos pipelines dépendent de la disponibilité et des limites du fournisseur.

Les alternatives en auto-hébergement inversent cette logique : vous possédez le client, le relais, et les clés de chiffrement.

2. frp : Le reverse proxy open-source haute performance

frp (Fast Reverse Proxy) est généralement le premier outil vers lequel se tournent les équipes pour une alternative à ngrok auto-hébergée, très configurable. Écrit en Go, multiplateforme, il se compose de deux composants : frps (le serveur, déployé sur une machine publique que vous contrôlez) et frpc (le client, tournant dans votre réseau privé). Le projet compte environ 108 000 étoiles sur GitHub et reste en développement actif, avec la dernière version stable (v0.70.0) sortie en juillet 2026.

Support des protocoles et transports. frp gère TCP, UDP, HTTP, HTTPS nativement, permettant de tunneliser SSH, RDP, MySQL ou des flux TCP bruts, en plus du trafic web. Entre frpc et frps, vous pouvez choisir le protocole de transport — TCP standard, KCP (UDP basé, échange un peu de surcharge pour plus de résilience sur des connexions instables), ou QUIC (transport multiplexé moderne basé sur UDP) — important pour des équipes réparties globalement sur des réseaux peu fiables.

Une correction de configuration importante : frp a abandonné l’ancien format frps.ini / frpc.ini. Depuis la v0.52.0, la configuration supporte TOML (ainsi que YAML et JSON), INI est déprécié, et les nouvelles fonctionnalités ne sont disponibles que dans ces formats modernes. Exemple de config actuel :

# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

TLS activé par défaut. Les anciennes descriptions (et le brouillon de cet article) mentionnaient manuellement tls_enable = true. Depuis la v0.50.0, transport.tls.enable est par défaut à true, donc le trafic frpc-vers-frps est chiffré dès l’origine ; cette option est surtout utile si vous souhaitez explicitement le désactiver ou forcer transport.tls.force = true sur le serveur pour rejeter les clients non chiffrés.

Mode P2P (XTCP), plus précisément. La capacité P2P de frp est du type proxy xtcp, pas un “mode” séparé. Il utilise la technique NAT hole punching basée sur STUN, de sorte qu’une fois un chemin direct établi entre deux clients, le flux de données bypass le frps et seule la négociation initiale passe par le serveur. Cela ne fonctionne pas avec tous les types NAT, mais frp permet de configurer un visiteur fallbackTo STCP qui prend le relais si le hole punching échoue dans un délai — une image plus fidèle que “le serveur ne voit jamais les données,” puisque frps reste impliqué dans la négociation.

Dashboard et API. Le dashboard de frps a connu des investissements réguliers : la version de juillet 2026 a étendu l’API v2 pour les clients, proxies, aperçu du serveur, et vues détaillées, avec listes paginées, historique du trafic, infos système, et filtrage par type de proxy — utile pour la journalisation en environnement réglementé.

Une refonte v2 en cours, lentement. Le mainteneur travaille sur une frp v2, décrite comme un core proxy L4/L7 modernisé, à la manière d’Envoy, incompatible avec v1. Depuis mi-2026, le développement est actif mais lent, le scope étant plus large que prévu, avec des fragments de temps. Pas de date de sortie annoncée, ne planifiez pas de migration en production pour l’instant.

3. Zrok : La superposition réseau Zero-Trust

Alors que frp est un reverse proxy point-à-point, beaucoup d’architectures d’entreprise se tournent vers Zero Trust Network Access (ZTNA). C’est là que Zrok intervient.

Basé sur OpenZiti. Zrok est une plateforme open-source de partage et tunneling de NetFoundry, construite sur OpenZiti, un overlay réseau zero-trust open-source. Plutôt que de simplement transférer des ports, Zrok ne suppose aucune confiance implicite : l’accès est basé sur l’identité, pas l’IP, et même les serveurs relais ne peuvent déchiffrer le trafic, car le chiffrement est de bout en bout via OpenZiti.

Modes de partage. Zrok supporte deux modes principaux :

• Partage public : génère une URL HTTPS accessible à tous — comparable à ngrok.
• Partage privé : crée une connexion tokenisée entre deux clients Zrok authentifiés, sans point d’accès public. Selon le mode backend choisi, il peut proxy HTTP, transférer des payloads TCP/UDP (tcpTunnel/udpTunnel), exposer un proxy SOCKS5 dynamique, ou établir un tunnel VPN hôte-à-hôte via OpenZiti.

Pas de ports entrants, jamais. Toutes les connexions Zrok s’établissent en sortie vers l’overlay, sans modification de firewall, port forwarding ou IP public.

Une étape clé en 2026 : à partir d’OpenZiti 1.8, les API du contrôleur peuvent s’inscrire comme services OpenZiti — la gestion du réseau est ainsi soumise à la même vérification cryptographique que les workloads, renforçant la sécurité.

Version stable. La version stable actuelle est zrok v1.x (v1.1.11 début 2026). Un “zrok2” en développement, non recommandé en prod pour l’instant, est à connaître si vous voyez des références.

Cas d’usage émergent : tunnels zero-trust pour IA. En 2026, des projets communautaires construisent des gateways zero-trust pour IA, incluant MCP (Model Context Protocol) et gateways LLM, avec isolation par client et mTLS, pour routeurs entre fournisseurs. Si votre infrastructure touche à l’IA ou MCP, c’est un domaine à suivre.

Auto-hébergeable. Zrok et OpenZiti sont sous licence Apache 2.0, permettant de déployer votre propre contrôleur et instance Zrok, sans frais récurrents, pour respecter la conformité, distinct du service géré zrok.io de NetFoundry.

4. Tunneling local Kubernetes : l’approche cloud-native

Avec la containerisation, une question revient : comment exposer un service local à un cluster Kubernetes distant, ou le faire accéder en sécurité à un service interne ?

Les ressources internes (API de staging, dashboard privé) se configurent souvent via Ingress, LoadBalancer, DNS. Pour déboguer rapidement, kubectl port-forward est fragile pour long terme ou partage externe. C’est là que frp (avec manifests Kubernetes manuels) et des outils comme Inlets tentent de combler le vide.

5. Inlets vs. frp : choisir le bon tunnel — et une correction

Comparer les options de tunnels Kubernetes auto-hébergés revient souvent : “inlets vs frp”. Les deux évitent NAT et SaaS, mais leur modèle économique diverge.

Correction : le projet open-source “inlets” (version OSS gratuite) a été abandonné et n’est plus mis à jour — le code reste accessible sur GitHub, mais non maintenu. Il a été remplacé par inlets Pro, une version commerciale. Il n’y a plus de version gratuite open-source pour Inlets, contrairement à frp ou Zrok. Si vous comparez “gratuit vs payant”, Inlets doit être considéré comme payant.

La gamme actuelle d’Inlets, par OpenFaaS Ltd :

• inlets Pro — client et serveur HTTP/TCP, pour particuliers et petites équipes.
• Inlets Uplink — contrôle natif Kubernetes, destiné aux fournisseurs SaaS ou entreprises, pour accéder à des environnements clients (bases privées, API internes) sans VPN complet. La connexion est sortie, TLS puis websocket, depuis le réseau privé du client vers votre serveur, en maintenant la data plane privée sauf si explicitement exposée.
• Inlets Cloud — solution entièrement managée.

Tarification vérifiée (inlets.dev/pricing) : Personal 25$/mois (5 tunnels), Commercial 50$/mois (2 tunnels + 25$/tunnel supplémentaire), Uplink 250$/mois par cluster (10 tunnels + 25$/tunnel supplémentaire). Facturation annuelle avec remise.

Intégration Kubernetes. inlets-operator utilise une ressource Tunnel custom, surveille les Services LoadBalancer, provisionne une VM cloud pour le serveur inlets Pro, et attache l’IP publique — pratique pour clusters locaux ou bare-metal sans LoadBalancer natif.

Où frp reste plus flexible et économique. frp n’a pas d’opérateur Kubernetes natif, il faut déployer frpc manuellement dans le cluster. En échange, c’est un proxy inverse totalement gratuit, flexible, avec KCP et QUIC pour réseaux à pertes, sans coût de licence.

Verdict mis à jour : si vous cherchez une solution commerciale supportée, avec provisioning automatique, Inlets (Pro/Uplink) est plus clé en main. Si vous préférez une solution gratuite, flexible, et auto-gérée, frp reste imbattable. La différence est maintenant : DIY et gratuit vs. commercial et managé.

6. Mise en pratique : garantir la souveraineté

Étape 1 : Sécuriser le relais dans une juridiction contrôlée. Que ce soit frps ou contrôleur OpenZiti pour Zrok, le relais doit être dans une infrastructure sous votre juridiction légale — par exemple, une entreprise de santé européenne hébergeant son relais en UE pour éviter que les données traversent les frontières.

Étape 2 : Chiffrement de bout en bout. Avec frp, TLS entre frpc et frps est activé par défaut depuis v0.50.0 (transport.tls.enable), plus besoin de chiffrement supplémentaire par proxy. Avec Zrok, le chiffrement est intégré dans la couche OpenZiti, protégeant cryptographiquement les données dès leur sortie du client jusqu’à la destination — et, depuis la version 1.8, le plan de contrôle est soumis à la même vérification cryptographique.

Étape 3 : Accès granulaire basé sur l’identité. Avec le mode privé de Zrok, vous pouvez donner accès à une identité Zrok spécifique, pas à un lien public. Si un utilisateur quitte, révoquer son identité coupe tous les tunnels internes. Contrôle d’accès basé sur l’identité, pas un lien leakable.

7. Conclusion : reprendre le contrôle de votre réseau

La commodité des tunnels commerciaux est indéniable, mais pour les équipes soumises à des contraintes réglementaires, la souveraineté des données prime. Faire transiter du code propriétaire, des bases internes ou des pré-versions via une infrastructure partagée comporte un risque évitable.

frp reste l’outil gratuit, flexible, et moderne pour la traversée réseau, avec une configuration TOML, TLS par défaut, et un dashboard en évolution. Zrok, basé sur OpenZiti, est idéal pour le zero-trust, le partage basé sur l’identité, sans port entrant, et s’intègre dans des tunnels IA ou MCP en 2026. Inlets vaut le coup si vous cherchez une solution Kubernetes native, supportée, payante, mais la période du “gratuit open-source” est finie ; la gamme actuelle est Pro/Uplink/Cloud, avec les prix ci-dessus.

Reprendre le contrôle de votre réseau, c’est maîtriser tout le cycle de vie du trafic, et connaître précisément le coût en argent ou en effort opérationnel.

---

Changelog

Corrections et ajouts basés sur les sources principales (gofrp.org, github.com/fatedier/frp, github.com/openziti/zrok, inlets.dev, docs.inlets.dev), juillet 2026 :

• Suppression des artefacts SEO/métadonnées et du titre trop long ; restructuration en Markdown propre avec titres.
• Correction du format de config frp : remplacement des exemples INI par TOML ; INI déprécié depuis v0.52.0.
• Correction de la gestion TLS : transport.tls.enable est par défaut à true depuis v0.50.0, plus besoin de tls_enable = true manuellement.
• Clarification du P2P/XTCP : frps reste impliqué dans la négociation STUN, même si le transfert bypass le, et le fallback STCP existe.
• Mise à jour des versions : dernière stable v0.70.0 (juillet 2026), et le développement lent de v2.
• Correction de la description privée Zrok : mode tokenisé entre clients authentifiés, modes backend listés (proxy, tcpTunnel/udpTunnel, socks, vpn).
• Ajout du hardening OpenZiti 1.8 (2026), non dans le draft initial.
• Note sur zrok v1.1.11 vs. zrok2 en développement.
• Ajout d’un cas d’usage : gateways zero-trust pour IA, MCP, LLM.
• Correction majeure sur Inlets : le projet OSS gratuit est abandonné, Inlets est maintenant commercial (Pro/Uplink/Cloud).
• Remplacement du prix vague “$25–$50/mois” par chiffres vérifiés : Personal 25$, Commercial 50$, Uplink 250$ par cluster.
• Refinement de l’intégration Kubernetes Inlets : opérateur inlets-operator crée une ressource Tunnel, surveille les Services LoadBalancer, provisionne une VM.
• Mise à jour du verdict : Inlets Pro/Uplink pour support et provisioning, frp pour DIY gratuit.
• Mise à jour de la conclusion pour refléter la nouvelle réalité tarifaire et de support.