Alternative à Cloudflare Tunnel : publier ou garder privé

Ce que Cloudflare Tunnel résout bien

Le principe de Cloudflare Tunnel est élégant : un petit démon, cloudflared, tourne à côté de votre service et établit une connexion sortante vers le réseau de Cloudflare. Le trafic des visiteurs arrive sur ce réseau, puis redescend par le tunnel jusqu'à votre machine. Résultat : aucun port entrant à ouvrir, aucune redirection à configurer sur le routeur, et le service fonctionne même derrière un NAT domestique ou un CGNAT d'opérateur, là où héberger un serveur classique est impossible.

• Exposition sans port ouvert : la machine qui héberge le service n'écoute pas depuis Internet, elle sort vers le réseau de Cloudflare.
• Protection du réseau mondial : le trafic public arrive d'abord sur l'infrastructure de Cloudflare, qui absorbe les attaques par déni de service avant qu'elles n'atteignent votre machine.
• Certificats et noms gérés : le visiteur atteint un nom de domaine en HTTPS sans que vous ayez de certificat à installer sur la machine d'origine.
• Adresse d'origine masquée : le visiteur ne voit que le réseau de Cloudflare, jamais l'adresse IP de votre connexion.

La question de fond : qui termine le TLS

Pour comprendre ce qu'on choisit vraiment, il faut distinguer deux familles d'outils que l'on confond souvent. Un tunnel d'exposition rend un service privé joignable depuis l'Internet public : n'importe qui peut s'y connecter, et une infrastructure intermédiaire reçoit ce trafic public pour le relayer vers l'origine. Un réseau privé, lui, relie vos machines entre elles : personne d'autre ne peut s'y connecter, et le trafic est chiffré d'un bout à l'autre entre les deux machines qui se parlent.

La différence se cristallise sur un point technique précis : qui termine le TLS. Dans l'architecture publique documentée de Cloudflare Tunnel, le flux HTTP des visiteurs transite par l'infrastructure de Cloudflare, qui termine la connexion TLS côté public avant de transmettre les requêtes par le tunnel. C'est un choix d'architecture cohérent — c'est ce qui permet le cache, l'inspection des attaques et la protection du réseau mondial — et il est parfaitement assumé et documenté. Il faut simplement en tirer la conséquence : un tunnel d'exposition n'est pas un réseau privé de bout en bout, et il ne prétend pas l'être.

Quand rien ne doit être public : le mesh privé

Si le service n'est destiné qu'à vous, à votre équipe ou à vos machines, VIGIL-MESH le garde entièrement hors d'Internet. Chaque machine rejoint un réseau privé maillé en établissant uniquement des connexions sortantes — un seul flux en 443 UDP, le même port que le web moderne — sans port entrant, sans redirection de box, y compris derrière un CGNAT 4G/5G. La connexion passe immédiatement par un relais, puis migre sans coupure vers le chemin direct de pair à pair dès que la traversée NAT aboutit.

Ce contrôle d'accès n'est pas une simple option de configuration : chaque changement de politique produit une nouvelle génération signée par le contrôleur, que chaque client vérifie cryptographiquement — y compris hors ligne — avant de l'appliquer. Appartenir au réseau n'ouvre aucun droit en soi ; sans règle qui l'autorise, un flux est refusé. C'est un modèle Zero Trust, pas un réseau plat.

Et parce qu'aucune porte publique n'existe, la surface d'attaque du service tombe à zéro pour tout l'Internet : rien à scanner, rien à forcer, rien à protéger d'un déni de service. La meilleure défense d'un service qui n'a pas vocation à être public, c'est de ne pas être joignable du tout.

Quand il faut vraiment exposer : la publication

Parfois, il faut réellement qu'un service soit joignable depuis l'Internet public : une application web pour des utilisateurs qui ne sont pas membres du mesh, une API consommée par des partenaires, un point d'entrée TCP pour un protocole métier. VIGIL-MESH couvre ce besoin avec les publications de la plateforme. Le principe reste le même que pour le mesh : la machine qui héberge le service n'ouvre aucun port entrant, elle rejoint le mesh en sortie ; c'est la plateforme qui présente la surface publique et relaie le trafic entrant jusqu'au service à travers le mesh chiffré.

Une publication est un acte explicite et chirurgical : chaque publication ouvre une porte vers un seul service interne. Le reste du réseau — adresses, noms de machines, services non publiés — reste invisible du visiteur. En HTTP, la plateforme agit en reverse-proxy : elle termine le TLS côté public avec un certificat obtenu et renouvelé automatiquement, puis transporte la requête jusqu'au service. En TCP, elle relaie le flux brut sans l'interpréter — et donc sans le chiffrer à votre place : c'est au protocole publié (SSH le fait nativement) d'assurer son propre chiffrement.

Soyons honnêtes sur la comparaison : dès qu'on publie en HTTP, quelqu'un termine le TLS côté public — c'est vrai pour la publication VIGIL-MESH comme pour Cloudflare Tunnel. La différence ne se joue plus sur le bout en bout, mais sur le périmètre et l'échelle. Et sur l'échelle, Cloudflare a un atout réel : son réseau mondial fait office de CDN et absorbe des attaques par déni de service massives au plus près de leur source. Pour un site public à fort trafic mondial ou particulièrement exposé aux attaques, c'est une force que la publication VIGIL-MESH ne prétend pas égaler.

Souveraineté : par où passent vos octets

Reste une question que les tunnels d'exposition ne posent jamais : à qui appartient l'infrastructure que traverse votre trafic ? Avec un tunnel géré, la réponse est structurelle — le trafic passe par le réseau de l'opérateur du tunnel. Avec VIGIL-MESH, le trafic de vos machines emprunte le chemin direct de pair à pair dès qu'il existe, sans transiter par quelque infrastructure que ce soit. Et pour la part relayée, vous pouvez reprendre la main.

• Vigie privée auto-hébergée : vous déployez votre propre relais sur votre serveur ; il s'enregistre automatiquement auprès du contrôleur et ne sert que votre espace de travail. Vos octets relayés ne transitent que par vos machines.
• Aveugle même chez vous : la vigie — la vôtre comme celle du service — ne détient pas les clés des sessions. L'auto-hébergement sert la souveraineté du chemin, la proximité et la conformité, pas la confidentialité du contenu, déjà garantie par le chiffrement de bout en bout.
• Proximité et conformité : un relais dans votre datacenter ou votre région réduit le détour du trafic relayé et le maintient dans votre périmètre contractuel et géographique.

Quel outil pour quel besoin

Le choix ne se résume pas à « Cloudflare Tunnel ou autre chose » : il dépend de qui doit joindre le service. Ce tableau ramène chaque besoin à l'outil qui lui correspond, y compris quand cet outil n'est pas le nôtre.

Les deux dernières lignes rappellent l'essentiel : la plupart des services d'un homelab ou d'une petite infrastructure n'ont pas besoin d'être publics. Les mettre sur le mesh, et ne publier que l'exception, réduit la surface d'attaque bien plus sûrement que n'importe quelle protection placée devant une exposition.

Mise en route : les deux scénarios

Premier scénario, le plus fréquent : accéder à vos services sans rien exposer. Tout se fait depuis la console, sans toucher à la box ni au pare-feu.

1. 1
   Créer un compte et un espace de travailL'espace de travail regroupe vos réseaux, vos machines et vos politiques d'accès. C'est gratuit pour un usage personnel.
2. 2
   Installer le client sur les machines concernéesLa machine qui héberge le service (NAS, serveur, box domotique) et celles qui doivent y accéder — Windows, Linux, Android, Jetson, ou même le navigateur via le nœud WASM.
3. 3
   Enrôler chaque machinePage Réseaux → Machines → « Ajouter une machine » : une clé à usage unique enrôle la machine dans le réseau.
4. 4
   Vérifier la connectivitéChaque machine reçoit une adresse stable et un nom MagicDNS ; un ping ou l'ouverture du service confirme que le mesh est en place.
5. 5
   Accéder au service par son nomDepuis n'importe quelle machine du réseau, joignez le service via l'adresse ou le nom de la machine, comme en local. Rien n'a été exposé à Internet.

Second scénario : le service doit être joignable par des visiteurs extérieurs au mesh. On passe alors par une publication HTTP de la plateforme.

1. 1
   Désigner le service interne à publierLa machine du mesh et le port sur lequel écoute l'application web. Le service continue de tourner exactement comme avant, sans modification.
2. 2
   Choisir le nom publicLe domaine ou sous-domaine par lequel les visiteurs atteindront le service ; sa gestion est décrite dans la documentation des domaines.
3. 3
   Laisser la plateforme obtenir le certificatLe certificat TLS du nom public est demandé et renouvelé automatiquement — aucun fichier à installer, aucune échéance à surveiller.
4. 4
   Le reverse-proxy relaie vers le serviceLe trafic entrant est terminé côté public puis transporté jusqu'au service interne à travers le mesh chiffré. Le reste du réseau reste invisible.

Questions fréquentes