Cloudflare Tunnel : publier une application sans ouvrir un seul port
La plupart des sites exposent leurs services sur des ports ouverts, alors qu'on peut les rendre publics sans rien ouvrir. Explication et retour d'expérience.
Le problème des ports ouverts
Quand vous hébergez quelque chose sur votre propre machine — un serveur, un NAS, une application interne — l'approche classique consiste à rediriger un port de votre box vers cette machine, puis à dire au monde entier : « entrez ». Vous venez d'ajouter une surface d'attaque. Chaque service exposé est une porte possible, et les scanneurs qui fouillent Internet les trouvent en quelques minutes.
Cette logique est vraie, mais elle est devenue contre-productive. On met un pare-feu, on filtre des IP, on ajoute une seconde couche… et on passe des soirées à maintenir une pile qui n'existait pas il y a dix ans. Cloudflare Tunnel inverse la logique : au lieu de pousser du trafic vers votre machine, c'est votre machine qui établit une connexion sortante vers Cloudflare.
Concrètement : aucune redirection de port sur votre box, aucun port ouvert sur votre pare-feu. Le service reste joignable publiquement parce que Cloudflare le relaie, et le trafic arrive quand même par le réseau edge — donc TLS, cache et protection DDoS restent en place.
Comment ça marche, précisément
Vous lancez un petit programme, cloudflared, sur la machine qui héberge le service. Il ouvre une connexion sortante chiffrée vers Cloudflare — le port 7844 en TCP, et UDP 7844 pour le protocole QUIC, plus rapide. Votre pare-feu n'autorise que les connexions sortantes, ce qui est le cas par défaut presque partout.
Côté Cloudflare, vous associez un nom de domaine à un service local : app.exemple.fr pointe vers http://localhost:8080. Cloudflare crée automatiquement l'enregistrement DNS correspondant. Un point de sécurité qu'il faut connaître : le sous-domaine généré, de la forme <uuid>.cfargotunnel.com, ne relaie le trafic que pour les enregistrements DNS appartenant au même compte Cloudflare. Quelqu'un qui découvrirait votre identifiant de tunnel ne pourrait donc pas l'utiliser pour router du trafic à travers votre tunnel depuis un autre compte.
Au niveau des protocoles, cloudflared gère bien plus que HTTP : SSH, RDP, SMB, les sockets Unix, et un mode bastion qui lui fait servir de rebond vers n'importe quelle adresse locale. Pour du SSH, par exemple, l'utilisateur final lance lui aussi cloudflared en client. C'est ce qui permet d'ouvrir une administration sans l'exposer.
Le fichier de configuration
La configuration se fait dans un fichier YAML, et c'est là que se joue la partie sérieuse. Les règles ingress sont évaluées de haut en bas, et la dernière doit obligatoirement être un fourre-tout :
- tunnel : l'identifiant du tunnel
- credentials-file : le fichier de connexion
- ingress : la liste des règles, dans l'ordre
- une dernière règle fourre-tout, obligatoirement
Une règle peut porter sur le nom d'hôte, sur le chemin, ou sur les deux. Si elle ne précise pas d'hôte, elle s'applique à tous ; si elle ne précise pas de chemin, elle s'applique à tous les chemins. Le fourre-tout final renvoie une 404 — ce qui est important : sans lui, cloudflared refuse simplement de démarrer. J'ai fait l'erreur une fois, le tunnel ne démarrait pas et le message n'explique pas clairement la cause.
Les pièges que j'ai rencontrés
Le premier, c'est le firewall. Si votre serveur est derrière un pare-feu restrictif, cloudflared doit pouvoir joindre Cloudflare sur le port 7844. J'ai passé du temps à comprendre pourquoi ça ne marchait pas alors que la machine avait bien Internet : le port était filtré en sortie.
Le deuxième, c'est de vouloir mettre le tunnel « en avant ». Le trafic passe par Cloudflare, donc l'adresse IP d'origine de la requête n'est plus celle de votre machine. Si votre application fait de la géolocalisation, la géolocalisation se fait désormais sur le pays du point d'entrée edge. Pour un site de PME en France, cela reste correct ; pour une logique fine de distribution, il faut le savoir.
Le troisième, et le plus vicieux : les websockets et les longues connexions. Le tunnel les supporte, mais une reconnexion de cloudflared coupe les connexions en cours. Sur une application de chat ou un tableau de bord, il faut prévoir un comportement de reconnexion côté client — ce que font la plupart des bibliothèques modernes, mais pas toutes les implémentations maison.
→ Vous avez un service qui doit être joignable mais pas exposé ? Je peux le mettre derrière un tunnel, avec le DNS et les règles d'accès. Écrivez-moi ce que vous cherchez à exposer.
Est-ce que c'est adapté à votre site ?
Soyons honnêtes : pour un site vitrine public, un tunnel n'est pas nécessaire. Si votre nom de domaine pointe déjà chez un hébergeur, ce dernier s'occupe du HTTPS. Le tunnel prend tout son sens dans trois cas : vous auto-hébergez, vous exposez un service interne, ou vous voulez supprimer une surface d'attaque.
Pour une PME, le scénario typique n'est pas technique : c'est un dirigeant ou une association qui a un serveur chez lui ou chez un prestataire, et qui s'inquiète d'une intrusion. Le tunnel répond à cette inquiétude sans demander de connaître le réseau.
Si votre question est plutôt « mon site est lent et je ne sais pas par où commencer », le sujet est différent : parlons-en, et je vous dirai honnêtement si un tunnel vous apporterait quelque chose.
→ Décrivez-moi votre installation actuelle — hébergement, services exposés, niveau de confort technique — et je vous dirai si un tunnel est pertinent ou si une autre solution conviendrait mieux.
