Roamba Windlassida Epaphras
Roamba Epaphras
#cloudflare#cloudflare-tunnel#vps#sécurité#linux#ubuntu#ssh#zero-trust#devops#infrastructure#afrique#cote-ivoire

Cloudflare Tunnel : sécuriser son VPS en fermant tous les ports (Guide 2026)

Fermez tous les ports entrants de votre VPS et exposez quand même vos services sur internet via une connexion sortante chiffrée vers Cloudflare. Le guide complet 2026 pour configurer cloudflared en mode dashboard ou en mode config.yml, sécuriser SSH avec Zero Trust et éviter les pièges classiques.

Roamba Epaphras, développeur Full-Stack à Abidjan, Côte d'Ivoire Roamba Windlassida Epaphras
Cloudflare Tunnel : sécuriser son VPS en fermant tous les ports (Guide 2026)

Combien de fois êtes-vous tombé sur un VPS attaqué dès la première semaine de mise en ligne ? Tentatives de brute-force SSH sur le port 22, scans de ports automatisés, exploits visant un panneau admin oublié sur le port 8080... Le simple fait d'avoir une IP publique avec des ports ouverts vous met dans la ligne de mire de millions de bots qui scannent internet en permanence.

Cloudflare Tunnel change radicalement cette équation. L'idée est simple mais puissante : au lieu d'ouvrir des ports sur votre VPS pour que les visiteurs s'y connectent, c'est votre VPS qui ouvre une connexion sortante chiffrée vers le réseau Cloudflare. Tout le trafic passe par ce tunnel, et aucun port entrant n'a besoin d'être ouvert. Un scan de votre IP ne révèle rien. Aucun port ne répond. Vous êtes invisible.

Dans ce guide complet 2026, vous allez apprendre à installer cloudflared, à créer un tunnel via le dashboard (la méthode recommandée par Cloudflare aujourd'hui), à le configurer en local avec un fichier config.yml pour les cas avancés, à sécuriser SSH derrière Zero Trust, et à éviter les pièges classiques que rencontrent ceux qui débutent.

Pourquoi Cloudflare Tunnel change la sécurité d'un VPS en 2026

Avant Cloudflare Tunnel, sécuriser un VPS impliquait une pile complète : pare-feu UFW correctement configuré, fail2ban pour bloquer les brute-force, reverse proxy Nginx ou Caddy, certificat SSL Let's Encrypt à renouveler tous les 90 jours, parfois un VPN comme WireGuard pour les accès admin. Cela fonctionne, mais c'est plusieurs surfaces d'attaque empilées, chacune avec ses propres CVE et sa propre maintenance.

Cloudflare Tunnel élimine en un seul mouvement plusieurs catégories entières d'attaques :

  • DDoS direct sur l'origine : impossible, l'IP du VPS n'est pas exposée.
  • Brute-force SSH sur le port 22 : impossible, le port 22 n'est pas accessible depuis internet.
  • Exploitation d'un service sur un port oublié (Redis, Mongo, panneau admin Adminer...) : impossible, rien n'écoute.
  • Énumération via scan de ports : impossible, tous les ports sont fermés.

En bonus, vous récupérez gratuitement le certificat TLS Cloudflare valide en bord de réseau, la protection DDoS L3/L4/L7 de Cloudflare, et la latence réduite par le routage Anycast vers le datacenter le plus proche du visiteur. Tout cela dans le plan gratuit, jusqu'à 50 utilisateurs Zero Trust inclus.

Comment fonctionne Cloudflare Tunnel (en 30 secondes)

Le démon cloudflared tourne en permanence sur votre VPS. Au démarrage, il établit quatre connexions sortantes persistantes (HTTP/2 ou QUIC) vers quatre datacenters Cloudflare différents, pour la redondance. Toutes ces connexions partent du VPS vers Cloudflare, donc elles traversent votre pare-feu sortant sans problème — exactement comme un navigateur qui charge une page web.

Quand un visiteur tape https://app.votre-domaine.com, sa requête arrive sur le réseau Cloudflare, qui regarde dans sa table de routage, identifie le tunnel correspondant, et fait transiter la requête à travers la connexion sortante déjà ouverte vers votre VPS. Votre service local (Nginx sur 127.0.0.1:8080, par exemple) la reçoit, renvoie sa réponse, et le tunnel la fait remonter au visiteur. Tout cela en quelques millisecondes.

Aucun port n'a été ouvert. Aucune règle NAT n'a été configurée. Aucun certificat n'a été géré manuellement.

Ce qu'il vous faut avant de commencer

  • Un VPS Linux (Ubuntu 22.04 ou 24.04 dans ce guide, mais Debian, Rocky, AlmaLinux fonctionnent de la même façon). Si vous cherchez un VPS abordable, Linode propose un plan à 5 $/mois parfaitement adapté.
  • Un domaine ajouté à Cloudflare (les nameservers du domaine doivent pointer vers Cloudflare). Si ce n'est pas le cas, allez sur dash.cloudflare.com → Add a Site, suivez l'assistant, modifiez les nameservers chez votre registrar (OVH, Namecheap, GoDaddy...) et attendez la propagation (souvent moins d'une heure).
  • Un compte Cloudflare avec accès au dashboard Zero Trust (gratuit, accessible sur one.dash.cloudflare.com).
  • Un service local à exposer : un Nginx, une API Node.js, une instance Grafana, peu importe — du moment qu'il écoute sur un port local du VPS.

Méthode 1 : Tunnel remotely-managed via le dashboard (recommandée en 2026)

Depuis 2024-2025, Cloudflare pousse activement les nouveaux utilisateurs vers les tunnels remotely-managed. La configuration vit dans le cloud (dans le dashboard Zero Trust), et le démon local n'a besoin que d'un token pour s'authentifier. C'est plus simple, c'est ce que la doc officielle recommande, et c'est ce que vous devriez utiliser pour 95 % des cas.

Étape 1 : Créer le tunnel dans le dashboard

Connectez-vous à one.dash.cloudflare.com, puis allez dans Networks → Tunnels → Create a tunnel. Choisissez Cloudflared comme connecteur, donnez un nom au tunnel (par exemple vps-prod-paris), et cliquez sur Save tunnel.

L'écran suivant vous propose une commande d'installation toute prête pour Linux (Debian/Ubuntu, RPM, Docker...). Copiez la commande pour Debian/Ubuntu 64-bit, elle ressemble à ceci :

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb && \
sudo dpkg -i cloudflared.deb && \
sudo cloudflared service install eyJhIjoiMTIzNDU2Nzg5MGFiY2RlZjEyMzQ1Njc4OTBhYmNkZWYi...

Cette commande :

  1. Télécharge le binaire cloudflared depuis GitHub.
  2. L'installe via dpkg.
  3. Enregistre un service systemd avec votre token de tunnel intégré.

Lancez-la sur votre VPS en SSH. En 30 secondes, le service tourne. Vérifiez :

sudo systemctl status cloudflared

Le service doit être active (running). Revenez dans le dashboard : votre tunnel doit passer en Healthy (point vert).

Étape 2 : Router un nom de domaine vers un service local

Dans l'onglet Public Hostname du tunnel, cliquez sur Add a public hostname :

  • Subdomain : app (ou ce que vous voulez)
  • Domain : choisissez le domaine que vous avez ajouté à Cloudflare
  • Type : HTTP (ou HTTPS si votre service interne tourne déjà en TLS)
  • URL : localhost:8080 (l'adresse interne de votre service)

Cliquez sur Save hostname. Cloudflare crée automatiquement l'enregistrement DNS CNAME pointant app.votre-domaine.com vers le tunnel.

Testez immédiatement : https://app.votre-domaine.com doit afficher votre service. Le certificat TLS est géré par Cloudflare en bord de réseau, sans intervention de votre part.

Étape 3 : Vérifier qu'aucun port n'est ouvert

Sur votre VPS, activez UFW et bloquez tout entrant sauf SSH temporairement, ou directement tout entrant si vous accédez en SSH via console fournisseur ou Cloudflare Access (voir plus bas) :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Faites un scan depuis une autre machine pour vérifier :

nmap -Pn -p 1-10000 votre-ip-vps

Le résultat doit indiquer que tous les ports sont fermés ou filtrés, et pourtant https://app.votre-domaine.com continue de répondre. C'est exactement ce qu'on cherche.

Méthode 2 : Tunnel locally-managed avec config.yml (contrôle total)

Si vous gérez plusieurs tunnels via Ansible, Terraform ou des scripts, ou si vous voulez versionner la configuration dans Git, le mode locally-managed garde tout dans un fichier YAML local. C'est l'ancienne méthode, mais elle reste pleinement supportée et indispensable dans certains contextes.

Étape 1 : Installer cloudflared et s'authentifier

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
cloudflared tunnel login

La dernière commande ouvre une URL — copiez-la dans votre navigateur, choisissez le domaine concerné, et autorisez. Un fichier cert.pem est créé dans ~/.cloudflared/. Il sert à signer la création de tunnels.

Étape 2 : Créer le tunnel et le fichier de configuration

cloudflared tunnel create vps-prod

Notez le Tunnel UUID affiché (et le fichier JSON correspondant créé dans ~/.cloudflared/). Créez ensuite ~/.cloudflared/config.yml :

tunnel: vps-prod
credentials-file: /root/.cloudflared/UUID.json

ingress:
  - hostname: app.votre-domaine.com
    service: http://localhost:8080
  - hostname: grafana.votre-domaine.com
    service: http://localhost:3000
  - hostname: api.votre-domaine.com
    service: http://localhost:5000
    originRequest:
      noTLSVerify: true
      connectTimeout: 30s
  - service: http_status:404

La dernière règle http_status:404 est obligatoire — c'est le catch-all pour toute requête qui n'aurait pas matché les hostnames précédents.

Étape 3 : Pointer les DNS et installer en service

Pour chaque hostname, créez le CNAME automatiquement :

cloudflared tunnel route dns vps-prod app.votre-domaine.com
cloudflared tunnel route dns vps-prod grafana.votre-domaine.com
cloudflared tunnel route dns vps-prod api.votre-domaine.com

Puis installez le service systemd qui démarrera au boot :

sudo cloudflared service install
sudo systemctl start cloudflared
sudo systemctl enable cloudflared

Vérifiez l'état et les logs en temps réel :

sudo systemctl status cloudflared
sudo journalctl -u cloudflared -f

Vous devriez voir quatre lignes confirmant les connexions sortantes établies vers les datacenters Cloudflare (souvent libellées cdg01, cdg02, etc. pour Paris).

Sécuriser SSH derrière Cloudflare Tunnel (Zero Trust)

Le scénario qui justifie à lui seul de migrer vers Cloudflare Tunnel : fermer le port 22 et n'autoriser SSH qu'après authentification SSO via Cloudflare Access. Plus de brute-force possible, plus besoin de bouger d'IP ou de jouer avec fail2ban.

Côté tunnel : exposer SSH

Ajoutez dans le dashboard (ou dans config.yml) un hostname pointant vers SSH :

  • Hostname : ssh.votre-domaine.com
  • Type : SSH
  • URL : localhost:22

Côté Access : restreindre l'accès

Dans one.dash.cloudflare.com → Access → Applications → Add an application, choisissez Self-hosted, mettez ssh.votre-domaine.com comme URL d'application, et créez une policy :

  • Action : Allow
  • Include : Emails ending in @votre-entreprise.com (ou emails individuels)
  • (Optionnel) Require : géolocalisation Côte d'Ivoire, méthode d'authentification MFA, etc.

Côté client : configurer SSH local

Sur votre poste, installez cloudflared puis ajoutez à ~/.ssh/config :

Host ssh.votre-domaine.com
  ProxyCommand cloudflared access ssh --hostname %h

Vous pouvez désormais faire ssh utilisateur@ssh.votre-domaine.com. La première fois, votre navigateur s'ouvre pour l'authentification SSO Cloudflare. Une fois validé, vous tombez sur le prompt SSH classique. Vous pouvez maintenant fermer définitivement le port 22 sur votre VPS sans perdre l'accès.

Cas d'usage concrets

Exposer un Grafana ou un Portainer sans VPN. Inutile de monter WireGuard juste pour accéder à votre dashboard de monitoring depuis un café. Un tunnel + une policy Access restreinte à votre email, et vous y accédez depuis n'importe où.

Recevoir des webhooks en local pendant le développement. Stripe, Twilio, GitHub envoient des webhooks vers votre app. En dev local, ils ne peuvent pas atteindre votre localhost:3000. Avec cloudflared tunnel --url http://localhost:3000, vous obtenez instantanément une URL https://random-name.trycloudflare.com qui forward vers votre machine. Aucune configuration, aucun compte requis (utile pour des tests ponctuels).

Exposer une API privée vers un partenaire B2B. Vous ne voulez pas que cette API soit accessible publiquement, juste par le partenaire X. Combinez un tunnel avec une policy Access qui n'autorise que les emails du domaine du partenaire. Vous gardez l'API hors d'internet, tout en lui donnant un accès propre via HTTPS.

Connecter un VPS à un réseau privé d'entreprise. Avec WARP-to-Tunnel, les utilisateurs WARP de votre organisation peuvent atteindre les services exposés par votre tunnel comme s'ils étaient sur le LAN — pratique pour des outils internes qui n'ont pas vocation à être sur internet.

Erreurs courantes et debugging

Erreur 502 Bad Gateway dans le navigateur. Le tunnel marche, mais cloudflared n'arrive pas à joindre votre service local. Vérifiez : le service écoute bien sur 127.0.0.1:PORT (pas seulement sur 0.0.0.0 derrière un autre pare-feu), le port est bien celui indiqué dans la config, et le firewall local du VPS n'intercepte pas le trafic loopback.

Le hostname répond 1033 (Argo Tunnel error). Le tunnel n'est pas connecté ou le hostname pointe vers un tunnel détruit. Vérifiez sudo systemctl status cloudflared et la santé dans le dashboard.

cloudflared service install échoue avec "service already exists". Désinstallez l'ancien d'abord : sudo cloudflared service uninstall. Cela arrive si vous changez de méthode (remotely-managed vers locally-managed ou inverse).

Les changements de config.yml ne sont pas pris en compte. En mode locally-managed, redémarrez explicitement : sudo systemctl restart cloudflared. Le démon ne recharge pas la config à chaud.

Mises à jour de cloudflared. Le binaire ne s'auto-met-à-jour pas par défaut. Mettez à jour régulièrement : sudo apt update && sudo apt upgrade cloudflared (si vous avez ajouté le repo Cloudflare), ou réinstallez le .deb depuis GitHub.

Limites et alternatives à connaître

Cloudflare Tunnel est gratuit et excellent, mais il a quelques limites à comprendre. Le trafic non-HTTP/SSH (par exemple un serveur de jeu UDP ou un FTP) nécessite des configurations plus avancées via Spectrum, qui est payant. Le tunnel ajoute un saut de latence (généralement faible, mais perceptible si votre service est très sensible — pas un problème pour 99 % des sites). Et le débit total d'un tunnel est limité (les chiffres officiels parlent de plusieurs Gbps, ce qui dépasse largement les besoins d'un VPS standard).

Si vous avez besoin d'exposer des services TCP arbitraires sans passer par Spectrum, regardez Tailscale ou WireGuard self-hosted comme alternatives. Pour du web pur, Cloudflare Tunnel reste imbattable en rapport simplicité / sécurité / prix.

Conclusion : un VPS invisible, mais accessible

En moins de 30 minutes, vous êtes passé d'un VPS exposé à tous les scans d'internet à un VPS totalement invisible dont les services restent pourtant publics et performants. UFW bloque tout en entrée, aucun certificat à renouveler, plus de crainte du brute-force SSH, et la protection DDoS de Cloudflare en bonus.

Pour la prochaine étape logique : automatiser tout ça (création de tunnels, DNS, déploiement) avec l'API et le CLI Cloudflare. C'est le sujet de l'article suivant sur l'automatisation Cloudflare avec API token et Wrangler CLI, qui pousse la démarche infrastructure-as-code à son maximum.

Et si vous cherchez un VPS solide pour mettre tout cela en pratique, le guide complet des prix Linode Akamai 2026 vous aidera à choisir le bon plan — un Nanode à 5 $/mois suffit largement pour héberger plusieurs services derrière un tunnel.