Cloudflare Tunnel permet de publier un site, une API ou une application interne sans ouvrir de port entrant sur le serveur. Le connecteur cloudflared établit lui-même une liaison sortante vers Cloudflare, qui devient le point d’entrée public et sécurisé du service.

Qu’est-ce qu’un Cloudflare Tunnel ?

Un Cloudflare Tunnel crée une liaison sécurisée entre un serveur privé et le réseau mondial de Cloudflare.

Traditionnellement, publier une application impose plusieurs opérations :

• disposer d’une adresse IP publique ;
• ouvrir les ports 80 ou 443 ;
• configurer une redirection NAT ;
• exposer un reverse proxy ;
• gérer les certificats TLS ;
• protéger directement l’adresse IP du serveur.

Cloudflare Tunnel inverse cette logique.

Le serveur exécute un petit programme nommé cloudflared. Celui-ci ouvre des connexions sortantes vers Cloudflare. Le pare-feu n’accepte donc aucune connexion entrante destinée au tunnel.

Lorsqu’un visiteur ouvre l’application, Cloudflare reçoit la requête. Son réseau la transmet ensuite à cloudflared, qui la relaie vers le service local concerné.

Cloudflare Tunnel peut publier des serveurs HTTP, des applications HTTPS, des services SSH, des bureaux RDP, des sockets Unix et différents services TCP. Aucun routage IP public n’est nécessaire sur le serveur d’origine.

Pourquoi utiliser Cloudflare Tunnel ? Ne plus exposer directement son serveur

Le principal intérêt réside dans la disparition des connexions entrantes.

Le serveur initie lui-même le tunnel. Il n’a donc pas besoin d’écouter publiquement sur les ports utilisés par l’application.

Vous pouvez, par exemple, faire écouter une interface d’administration uniquement sur :

127.0.0.1:8080

cloudflared accède au service depuis la machine locale. En revanche, aucune machine distante ne peut joindre directement ce port.

Cette architecture réduit considérablement la surface d’exposition du serveur. Elle évite également les erreurs fréquentes de configuration NAT ou de pare-feu.

Masquer l’adresse IP de l’origine

Le DNS public pointe vers une adresse spéciale associée au tunnel :

<TUNNEL-UUID>.cfargotunnel.com

Il ne pointe plus directement vers l’adresse IP du serveur.

Cloudflare reçoit donc les connexions avant l’origine. Le serveur peut rester derrière un routeur, une connexion avec CGNAT ou un pare-feu restrictif.

Toutefois, un tunnel ne peut pas faire oublier une adresse déjà divulguée. D’anciens enregistrements DNS, des services annexes ou des sous-domaines mal configurés peuvent toujours révéler l’origine.

Publier un service sans redirection de ports

Cloudflare Tunnel convient particulièrement aux environnements où vous ne contrôlez pas le routeur.

C’est souvent le cas pour :

• un serveur installé derrière une box ;
• un NAS domestique ;
• une machine hébergée dans un réseau d’entreprise ;
• un environnement de développement ;
• une connexion utilisant le CGNAT ;
• une application exécutée dans Docker ou Kubernetes.

Le serveur doit uniquement pouvoir établir des connexions sortantes vers Cloudflare.

Ajouter les protections Cloudflare

Les applications publiées héritent des réglages Cloudflare associés à leur nom d’hôte.

Vous pouvez notamment appliquer :

• la protection DDoS ;
• le pare-feu applicatif ;
• les règles de cache ;
• les règles de limitation de débit ;
• les règles personnalisées ;
• les fonctions de gestion des robots.

Cloudflare traite la requête avant de la transmettre au tunnel.

Protéger une application avec Cloudflare Access

Cloudflare Tunnel publie le service. Cependant, il ne décide pas automatiquement qui peut l’utiliser.

Une application associée à un nom d’hôte public reste accessible à tous, sauf si vous ajoutez une politique de sécurité.

Cloudflare Access apporte cette couche d’authentification. Vous pouvez autoriser uniquement :

• certaines adresses électroniques ;
• un domaine professionnel ;
• des membres précis de votre organisation ;
• des utilisateurs authentifiés par Google, GitHub, Microsoft Entra ID ou un autre fournisseur ;
• des appareils conformes à une politique de sécurité ;
• des services automatisés présentant un jeton valide.

Les applications Access refusent les connexions par défaut. L’utilisateur doit correspondre à une politique Allow pour obtenir l’accès.

Dans quels cas utiliser un Cloudflare Tunnel ? Une interface d’administration

Vous pouvez protéger un tableau de bord Grafana, Portainer, phpMyAdmin ou une interface interne.

L’application reste liée à l’adresse locale. Cloudflare Access contrôle ensuite l’identité des utilisateurs.

Un environnement WordPress de préproduction

Un site de développement peut être publié sur un sous-domaine comme :

staging.example.com

Vous pouvez alors le protéger avec une authentification Cloudflare Access.

Cette méthode évite de laisser un site de préproduction ouvert aux moteurs de recherche, aux robots et aux visiteurs indiscrets.

Un service installé sur un NAS

Un tunnel peut publier une interface web, un gestionnaire de fichiers ou une application hébergée sur un NAS.

Vous évitez ainsi d’ouvrir directement les ports du routeur vers le NAS.

Une application locale en développement

Cloudflare propose des tunnels temporaires appelés Quick Tunnels.

La commande suivante publie immédiatement un service local :

cloudflared tunnel --url http://localhost:8080

Cloudflare génère alors une adresse aléatoire sous trycloudflare.com.

Ces tunnels conviennent aux démonstrations et aux tests. Ils ne doivent pas servir en production.

Un serveur sans adresse IPv4 publique

Le tunnel fonctionne même si le fournisseur d’accès utilise le CGNAT.

Le serveur n’a pas besoin de recevoir directement la connexion. Il doit seulement pouvoir contacter Cloudflare.

Comment fonctionne Cloudflare Tunnel ?

Le chemin complet d’une requête ressemble à ceci :

Visiteur
   ↓
Réseau Cloudflare
   ↓
Nom d’hôte public
   ↓
Cloudflare Tunnel
   ↓
Connecteur cloudflared
   ↓
Service local

Prenons l’exemple suivant :

https://app.example.com

Le service réel écoute uniquement ici :

http://127.0.0.1:8080

Le navigateur contacte d’abord Cloudflare. Celui-ci applique ses règles de sécurité, puis sélectionne une connexion active du tunnel.

cloudflared reçoit la requête et la transmet à 127.0.0.1:8080.

La réponse reprend ensuite le même chemin en sens inverse.

Les connexions entre cloudflared et Cloudflare

Une instance cloudflared établit plusieurs connexions sortantes vers différents centres de données Cloudflare.

Si une connexion ou un centre de données devient indisponible, les autres connexions continuent de transporter le trafic.

Par défaut, cloudflared utilise QUIC sur le port UDP 7844. Si QUIC échoue, il peut basculer vers HTTP/2 sur le port TCP 7844.

Le rôle du DNS

Chaque tunnel possède un identifiant UUID.

Cloudflare lui associe une cible DNS de cette forme :

6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com

Le sous-domaine public utilise ensuite un enregistrement CNAME :

app.example.com → 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com

Plusieurs sous-domaines peuvent pointer vers le même tunnel. Chaque nom d’hôte peut ensuite être dirigé vers un service local différent.

Cloudflare Tunnel remplace-t-il un VPN ?

Pas exactement.

Cloudflare Tunnel excelle lorsqu’il faut publier une application précise. Il associe alors un nom d’hôte à un service local.

Un VPN traditionnel donne généralement accès à une partie plus large du réseau privé.

Pour fournir un accès privé à plusieurs adresses IP internes, Cloudflare Tunnel peut fonctionner avec Cloudflare One Client, anciennement WARP. Dans cette configuration, Cloudflare agit davantage comme une plateforme Zero Trust que comme un simple reverse proxy.

Pour une interface web unique, le couple Cloudflare Tunnel et Cloudflare Access reste souvent plus simple.

Les différents modes de gestion

Cloudflare propose deux méthodes principales.

Le tunnel géré depuis le tableau de bord

Cloudflare appelle ce mode un tunnel remotely managed.

Vous créez le tunnel depuis le tableau de bord. Cloudflare stocke sa configuration. Le serveur utilise uniquement un jeton pour lancer cloudflared.

Cette méthode convient à la majorité des installations.

Elle offre plusieurs avantages :

• configuration centralisée ;
• ajout simple de routes ;
• déploiement rapide ;
• absence de fichier YAML obligatoire ;
• intégration directe avec Cloudflare Access.

Le tunnel géré localement

Un tunnel locally managed conserve sa configuration dans un fichier YAML placé sur le serveur.

Cette méthode convient lorsque vous souhaitez :

• versionner la configuration ;
• automatiser le déploiement ;
• gérer précisément les règles d’entrée ;
• intégrer le tunnel à une infrastructure existante ;
• contrôler localement chaque changement.

Elle demande toutefois une gestion plus rigoureuse des certificats et des fichiers d’identification.

Mise en place d’un Cloudflare Tunnel sous Ubuntu ou Debian

Nous allons d’abord utiliser la méthode recommandée pour une installation courante : le tunnel géré depuis le tableau de bord.

Prérequis

Vous devez disposer :

• d’un compte Cloudflare ;
• d’un domaine dont la zone DNS utilise Cloudflare ;
• d’un serveur Linux connecté à Internet ;
• d’un service local fonctionnel ;
• d’un accès administrateur au serveur.

Le service local peut être Nginx, Apache, Docker, Node.js ou n’importe quelle application HTTP.

Dans cet exemple, il écoute sur :

http://127.0.0.1:8080

Vérifier le service local

Avant de configurer Cloudflare, testez directement l’application :

curl --fail --show-error --head http://127.0.0.1:8080

Vous devez obtenir une réponse HTTP.

Un tunnel ne peut pas réparer un service local qui ne fonctionne pas.

Installer cloudflared

Ajoutez d’abord la clé du dépôt Cloudflare :

sudo mkdir -p --mode=0755 /usr/share/keyrings

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg |
	sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null

Ajoutez ensuite le dépôt :

echo \
	"deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main" |
	sudo tee /etc/apt/sources.list.d/cloudflared.list >/dev/null

Installez le paquet :

sudo apt-get update
sudo apt-get install cloudflared

Vérifiez la version :

cloudflared version

Cloudflare maintient un dépôt officiel pour Debian et Ubuntu. Maintenez régulièrement le connecteur à jour.

Créer le tunnel depuis le tableau de bord Cloudflare

Dans le tableau de bord Cloudflare :

1. ouvrez Networking ;
2. sélectionnez Tunnels ;
3. cliquez sur Create Tunnel ;
4. donnez un nom descriptif au tunnel ;
5. choisissez l’environnement Linux correspondant au serveur.

Utilisez, par exemple :

apollo-applications

Cloudflare affiche alors une commande contenant le jeton du tunnel.

Elle ressemble à ceci :

sudo cloudflared service install <TUNNEL_TOKEN>

Exécutez cette commande sur le serveur.

Le jeton donne le droit de lancer le tunnel. Ne le placez jamais dans un dépôt Git, un journal public ou une capture d’écran.

Une fois la commande exécutée, le tableau de bord doit afficher l’état :

Healthy

Ajouter une application publiée

Ouvrez le tunnel, puis ajoutez une route de type Published application.

Configurez les champs suivants :

Hostname : app.example.com
Service  : http://127.0.0.1:8080

Cloudflare crée automatiquement l’enregistrement DNS nécessaire.

Une fois la route enregistrée, l’application devient accessible ici :

https://app.example.com

Cloudflare termine la connexion HTTPS publique. Le service local peut donc continuer à utiliser HTTP sur l’interface de boucle locale.

Vérifier le service systemd

Contrôlez l’état de cloudflared :

sudo systemctl status cloudflared --no-pager

Affichez les derniers journaux :

sudo journalctl \
	--unit=cloudflared \
	--lines=100 \
	--no-pager

Suivez les journaux en direct :

sudo journalctl \
	--unit=cloudflared \
	--follow

Testez ensuite l’adresse publique :

curl --fail --show-error --head https://app.example.com

Ajouter Cloudflare Access

Une route publiée n’est pas privée par défaut.

Pour protéger une interface interne, créez une application Cloudflare Access correspondant au même nom d’hôte.

Dans le tableau de bord Zero Trust :

1. ouvrez Access controls ;
2. sélectionnez Applications ;
3. créez une application auto-hébergée ;
4. ajoutez le nom app.example.com ;
5. créez une politique Allow ;
6. limitez l’accès aux utilisateurs autorisés ;
7. configurez la durée des sessions ;
8. activez l’authentification multifacteur si nécessaire.

Par exemple, vous pouvez autoriser une adresse précise :

admin@example.com

Vous pouvez aussi autoriser les adresses d’un domaine professionnel :

@example.com

Évitez une politique Allow fondée sur Everyone. Elle rendrait l’application accessible à tous.

Créer le tunnel avec cloudflared

La gestion locale apporte davantage de contrôle.

Authentifier cloudflared

Lancez :

cloudflared tunnel login

Une page Cloudflare s’ouvre dans le navigateur. Sélectionnez ensuite la zone DNS concernée.

La commande crée un fichier :

~/.cloudflared/cert.pem

Ce certificat permet de créer, modifier et supprimer les tunnels du compte. Il dispose donc de droits étendus.

Ne le copiez pas sur chaque serveur.

Le fichier d’identification propre à un tunnel possède des droits beaucoup plus limités. Il permet uniquement de lancer le tunnel correspondant.

Créer le tunnel

Lancez :

cloudflared tunnel create apollo-internal

La commande affiche l’UUID du tunnel et crée un fichier JSON :

~/.cloudflared/<TUNNEL-UUID>.json

Conservez l’identifiant :

TUNNEL_ID="6ff42ae2-765d-4adf-8112-31c55c1551ef"

Vérifiez la liste des tunnels :

cloudflared tunnel list

Installer les identifiants du tunnel

Créez le répertoire de configuration :

sudo install \
	--directory \
	--mode=0750 \
	--owner=root \
	--group=root \
	/etc/cloudflared

Copiez le fichier d’identification :

sudo install \
	--mode=0600 \
	--owner=root \
	--group=root \
	"$HOME/.cloudflared/${TUNNEL_ID}.json" \
	"/etc/cloudflared/${TUNNEL_ID}.json"

Créer le fichier de configuration

Créez le fichier :

sudo nano /etc/cloudflared/config.yml

Ajoutez cette configuration :

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:8080

  - hostname: monitoring.example.com
    service: http://127.0.0.1:3000

  - hostname: ssh.example.com
    service: ssh://127.0.0.1:22

  - service: http_status:404

La dernière règle sert de règle générale. Elle répond avec une erreur 404 lorsqu’aucune route précédente ne correspond.

Protégez le fichier :

sudo chown root:root /etc/cloudflared/config.yml
sudo chmod 0600 /etc/cloudflared/config.yml

Valider les règles

Validez la configuration avant de redémarrer le service :

cloudflared tunnel \
	--config /etc/cloudflared/config.yml \
	ingress validate

Vous pouvez également vérifier quelle règle traiterait une adresse donnée :

cloudflared tunnel \
	--config /etc/cloudflared/config.yml \
	ingress rule https://app.example.com/

Créer les routes DNS

Créez un enregistrement pour chaque nom d’hôte :

cloudflared tunnel route dns \
	apollo-internal \
	app.example.com

Puis :

cloudflared tunnel route dns \
	apollo-internal \
	monitoring.example.com

La commande crée les CNAME pointant vers l’adresse cfargotunnel.com du tunnel.

Installer le service systemd

Installez cloudflared comme service :

sudo cloudflared \
	--config /etc/cloudflared/config.yml \
	service install

Activez-le et démarrez-le :

sudo systemctl enable --now cloudflared

Vérifiez son état :

sudo systemctl status cloudflared --no-pager

Après chaque modification de la configuration, validez le fichier puis redémarrez le service :

cloudflared tunnel \
	--config /etc/cloudflared/config.yml \
	ingress validate

sudo systemctl restart cloudflared

Faut-il ouvrir des ports dans le pare-feu ?

Vous ne devez pas ouvrir le port 7844 en entrée.

cloudflared utilise ce port uniquement pour ses connexions sortantes.

Avec un pare-feu qui autorise déjà tout le trafic sortant, aucune règle supplémentaire n’est normalement nécessaire.

Dans un environnement où les sorties sont filtrées, autorisez :

UDP sortant 7844
TCP sortant 7844
TCP sortant 443
DNS sortant vers le résolveur utilisé

QUIC utilise UDP 7844. Le mode HTTP/2 de secours utilise TCP 7844.

Si UDP 7844 est bloqué, cloudflared tente automatiquement HTTP/2. Si UDP et TCP sont bloqués sur ce port, le tunnel ne peut pas fonctionner.

Avec UFW et une politique restrictive en sortie, les règles pourraient ressembler à ceci :

sudo ufw allow out 7844/udp
sudo ufw allow out 7844/tcp
sudo ufw allow out 443/tcp

Adaptez toujours les règles DNS au résolveur réellement utilisé par le serveur.

Fermer l’accès direct à l’origine

Installer un tunnel ne suffit pas si le même service reste publiquement accessible par son adresse IP.

Supposons que Nginx continue d’écouter sur toutes les interfaces :

listen 80;
listen 443 ssl;

Un visiteur qui connaît l’adresse IP pourrait encore contourner Cloudflare.

Pour un service exclusivement publié par le tunnel, vous pouvez le faire écouter sur l’adresse locale :

listen 127.0.0.1:8080;

Vous pouvez ensuite configurer la route :

http://127.0.0.1:8080

Autre possibilité : conservez l’écoute publique, mais bloquez le trafic direct avec le pare-feu.

Le meilleur choix dépend des autres services hébergés sur la machine.

Utiliser Cloudflare Tunnel avec WordPress

Cloudflare Tunnel peut publier un site WordPress complet. Toutefois, il devient particulièrement intéressant pour les services annexes.

Un site de préproduction

Vous pouvez placer une préproduction sur :

staging.example.com

Ajoutez ensuite une politique Cloudflare Access limitée au client et aux développeurs.

Une interface d’administration séparée

Vous pouvez protéger un outil d’administration ou un tableau de suivi placé sur un sous-domaine distinct.

Évitez néanmoins de protéger aveuglément l’intégralité d’un site WooCommerce avec Access.

Les services suivants peuvent nécessiter un accès public :

• les notifications Stripe ;
• les webhooks PayPal ;
• les API de livraison ;
• les tâches distantes ;
• les appels REST ;
• les services de supervision ;
• certaines communications entre WooCommerce et des fournisseurs externes.

Dans ce cas, protégez uniquement les noms d’hôtes ou les chemins réellement privés.

Un serveur WordPress auto-hébergé

Le tunnel peut éviter d’exposer directement Nginx. Cependant, il ne remplace pas :

• la maintenance de WordPress ;
• les mises à jour des extensions ;
• le durcissement de PHP ;
• les règles du pare-feu ;
• la protection des comptes administrateurs ;
• les sauvegardes ;
• la surveillance de l’intégrité.

Le tunnel réduit l’exposition réseau. Il ne corrige pas une vulnérabilité présente dans l’application.

Mettre en place plusieurs connecteurs

Vous pouvez exécuter plusieurs instances de cloudflared pour un même tunnel.

Cloudflare appelle chaque instance supplémentaire une replica.

Cette architecture protège contre la panne d’une machine ou d’un connecteur.

En revanche, les replicas d’un même tunnel servent principalement à la haute disponibilité. Ils ne remplacent pas un véritable équilibrage applicatif avec contrôles de santé, affinité de session et routage pondéré.

Pour un équilibrage précis, utilisez plusieurs tunnels distincts associés à Cloudflare Load Balancing ou à un répartiteur interne.

Surveiller un Cloudflare Tunnel

Le tableau de bord peut afficher quatre états principaux :

• Healthy : les connexions attendues sont actives ;
• Inactive : le tunnel existe, mais aucun connecteur ne l’a encore lancé ;
• Down : le connecteur fonctionnait auparavant, mais il est désormais déconnecté ;
• Degraded : le tunnel fonctionne encore, mais une ou plusieurs connexions ont échoué.

Attention : l’état du tunnel mesure la liaison entre cloudflared et Cloudflare.

Un tunnel peut apparaître comme sain alors que l’application locale ne répond plus. Vous devez donc superviser séparément le connecteur et le service d’origine.

Afficher les informations d’un tunnel

Pour un tunnel géré localement :

cloudflared tunnel info apollo-internal

Listez les tunnels :

cloudflared tunnel list

Consulter les journaux distants

Vous pouvez diffuser les journaux d’un tunnel depuis une autre machine :

cloudflared tail <TUNNEL-UUID>

Pour obtenir du JSON :

cloudflared tail \
	--output=json \
	<TUNNEL-UUID> |
	jq .

Exposer les métriques Prometheus

cloudflared expose un endpoint Prometheus local.

Vous pouvez définir son adresse explicitement :

cloudflared tunnel \
	--metrics 127.0.0.1:60123 \
	run apollo-internal

Les métriques deviennent alors disponibles ici :

http://127.0.0.1:60123/metrics

Ne publiez pas cet endpoint sur Internet sans authentification.

Mettre à jour cloudflared

Lorsque cloudflared provient du dépôt APT, utilisez :

sudo apt-get update

sudo apt-get install \
	--only-upgrade \
	cloudflared

sudo systemctl restart cloudflared.service

Vérifiez ensuite la version :

cloudflared version

Une mise à jour redémarre le connecteur et peut interrompre brièvement les connexions actives.

Pour supprimer cette interruption, déployez plusieurs replicas ou une architecture équipée d’un répartiteur de charge.

Résoudre les problèmes fréquents Le tunnel est sain, mais l’application ne répond pas

Testez d’abord le service local :

curl --fail --show-error --head http://127.0.0.1:8080

Vérifiez ensuite :

• l’adresse configurée ;
• le port ;
• le protocole HTTP ou HTTPS ;
• les droits d’accès au socket ;
• les règles du pare-feu local ;
• les journaux de l’application.

Un état Healthy ne garantit pas que cloudflared peut joindre l’application.

Cloudflare affiche une erreur 502

Une erreur 502 indique souvent que Cloudflare atteint le tunnel, mais que cloudflared ne peut pas joindre le service local.

Vérifiez notamment que l’application n’écoute pas uniquement dans un autre conteneur ou espace réseau.

Avec Docker, 127.0.0.1 désigne le conteneur cloudflared lui-même lorsque les deux services ne partagent pas le même réseau.

Cloudflare affiche une erreur 1016

Une erreur 1016 peut apparaître lorsqu’un enregistrement DNS pointe vers un tunnel qui ne fonctionne plus.

Le DNS et le tunnel restent indépendants. L’arrêt du tunnel ne supprime pas automatiquement l’enregistrement DNS.

QUIC ne peut pas se connecter

Les journaux peuvent afficher :

Failed to dial a quic connection

Testez le port UDP 7844 :

nc -uvz -w 3 198.41.192.227 7844

Remplacez l’adresse par celle affichée dans les journaux.

Si UDP est bloqué, cloudflared doit normalement basculer vers HTTP/2.

Vous pouvez forcer temporairement HTTP/2 pour confirmer le diagnostic :

cloudflared tunnel \
	--protocol http2 \
	run apollo-internal

QUIC reste néanmoins le protocole recommandé lorsque le réseau l’autorise.

Le nom DNS existe déjà

Cloudflare refuse de créer la route lorsqu’un enregistrement A, AAAA ou CNAME utilise déjà le même nom.

Inspectez les enregistrements DNS, puis supprimez ou remplacez l’entrée conflictuelle.

Le fichier JSON est introuvable

Vérifiez le chemin défini ici :

credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json

Contrôlez ensuite le fichier :

sudo stat /etc/cloudflared/<TUNNEL-UUID>.json

Le service doit pouvoir le lire.

Le service utilise la mauvaise configuration

Inspectez l’unité systemd :

sudo systemctl cat cloudflared

Recherchez le chemin transmis avec l’option --config.

Le problème apparaît souvent lorsque la configuration reste dans le répertoire personnel d’un utilisateur, tandis que le service s’exécute avec un autre compte.

Les limites de Cloudflare Tunnel Le connecteur devient indispensable

Si cloudflared s’arrête, Cloudflare ne peut plus atteindre l’application.

Utilisez systemd, une supervision et éventuellement plusieurs replicas.

Cloudflare devient un intermédiaire

Le trafic public traverse le réseau Cloudflare.

Cette architecture apporte le WAF, la protection DDoS et le contrôle d’accès. Elle place aussi Cloudflare dans le chemin réseau de l’application.

Les services non HTTP demandent un client

Pour les services SSH, TCP, RDP ou SMB publiés via un nom d’hôte, l’utilisateur doit généralement installer cloudflared côté client.

Les services HTTP et HTTPS fonctionnent directement dans un navigateur.

Le tunnel ne constitue pas une authentification

Un tunnel public reste public.

Ajoutez Cloudflare Access lorsque le service ne doit pas être accessible à tous.

Le tunnel ne protège pas une application vulnérable

Un plugin WordPress vulnérable, un mot de passe faible ou une mauvaise politique d’autorisation restent dangereux.

Le tunnel ne doit pas devenir une excuse pour négliger la sécurité applicative.

Bonnes pratiques

1. Liez les services privés à 127.0.0.1 ou à un réseau interne.
2. Fermez les ports publics devenus inutiles.
3. Protégez les interfaces sensibles avec Cloudflare Access.
4. Conservez les jetons et fichiers JSON hors des dépôts Git.
5. Limitez l’usage du certificat cert.pem.
6. Ajoutez toujours une règle générale http_status:404.
7. Validez le fichier YAML avant chaque redémarrage.
8. Surveillez séparément le tunnel et l’application.
9. Maintenez cloudflared à jour.
10. Déployez plusieurs replicas pour les services critiques.

Cloudflare Tunnel est-il adapté à la production ?

Oui, à condition de le traiter comme un composant d’infrastructure.

Une installation de production doit inclure :

• un service cloudflared supervisé ;
• une configuration reproductible ;
• une politique de mise à jour ;
• des contrôles de disponibilité ;
• une protection Cloudflare Access lorsque nécessaire ;
• une stratégie de redondance ;
• une origine correctement isolée.

Cloudflare Tunnel est disponible sur les différents forfaits Cloudflare. Les fonctionnalités Zero Trust et les limites applicables dépendent ensuite du forfait et des services choisis.

Conclusion

Cloudflare Tunnel change la manière de publier un service auto-hébergé.

Au lieu d’ouvrir un port et d’attendre les connexions, le serveur établit une liaison sortante vers Cloudflare. Cette inversion simplifie le réseau, masque l’origine et réduit la surface d’exposition.

Le tunnel devient particulièrement efficace lorsqu’il fonctionne avec Cloudflare Access. Vous obtenez alors une passerelle Zero Trust capable de contrôler l’identité avant que la requête n’atteigne votre serveur.

Pour un site public, un environnement de préproduction, une interface d’administration ou un service installé derrière une box, Cloudflare Tunnel constitue une solution robuste. Il faut néanmoins surveiller le connecteur, protéger les identifiants et verrouiller l’accès direct à l’origine.

Questions fréquentes sur Cloudflare Tunnel Cloudflare Tunnel est-il gratuit ?

Cloudflare Tunnel est disponible sur les différents forfaits Cloudflare. Certaines fonctions complémentaires de Cloudflare Zero Trust, Access ou Load Balancing peuvent dépendre du forfait utilisé.

Faut-il une adresse IP publique ?

Non. Le serveur établit lui-même les connexions sortantes vers Cloudflare. Il peut donc fonctionner derrière un routeur, le CGNAT ou un pare-feu sans redirection de ports.

Faut-il ouvrir le port 7844 en entrée ?

Non. Le port 7844 sert aux connexions sortantes de cloudflared. QUIC utilise UDP et HTTP/2 utilise TCP.

Cloudflare Tunnel chiffre-t-il les connexions ?

Oui. Les connexions entre cloudflared et Cloudflare sont chiffrées.

Cloudflare Tunnel remplace-t-il Cloudflare Access ?

Non. Cloudflare Tunnel transporte le trafic. Cloudflare Access authentifie les utilisateurs et applique les politiques d’autorisation.

Peut-on utiliser Cloudflare Tunnel avec WordPress ?

Oui. Vous pouvez publier un site WordPress complet, un environnement de préproduction ou une interface annexe. Vous devez cependant préserver l’accès aux webhooks, API et services externes nécessaires au fonctionnement du site.

Peut-on publier plusieurs applications avec un seul tunnel ?

Oui. Un même tunnel peut associer plusieurs noms d’hôtes à plusieurs services locaux.

Que se passe-t-il si cloudflared s’arrête ?

Cloudflare ne peut plus atteindre l’origine. Le DNS reste présent, mais les visiteurs obtiennent une erreur. Vous pouvez déployer plusieurs replicas pour améliorer la disponibilité.

Sources

• Présentation de Cloudflare Tunnel
• Création et installation d’un tunnel
• Routage des applications et services
• Configuration des tunnels
• Protection avec Cloudflare Access
• Dépannage de cloudflared

Report a typo