J’ai enfin compris les tunnels Zero Trust de Cloudflare

 (david.coffee)
2 points par GN⁺ 2025-11-17 | 1 commentaires | Partager sur WhatsApp
  • Explication d’une architecture qui utilise Cloudflare Zero Trust et WARP pour relier des réseaux privés et contrôler l’accès aux services sans problèmes de NAT ni de pare-feu
  • Avec les tunnels Argo, il est possible d’exposer un réseau privé ou un service local sur un domaine public, ou de construire un réseau privé accessible uniquement via une connexion WARP
  • Tailscale est rapide grâce au P2P, mais reste limité dans certains environnements NAT, tandis que Cloudflare fait transiter tout le trafic via son réseau edge, offrant une connexion plus stable
  • Cloudflared sert à créer les tunnels, le client WARP gère la connexion réseau et l’application des politiques, tandis que Tunnels, Routes et Targets structurent les flux de trafic et le contrôle d’accès
  • Des politiques d’accès fines, basées par exemple sur l’e-mail ou la connexion GitHub, permettent de créer un environnement réseau sécurisé où la procédure de connexion peut être ignorée ou restreinte selon que WARP est connecté ou non

Vue d’ensemble de Cloudflare Zero Trust et WARP

  • L’apprentissage de Cloudflare Zero Trust + WARP a commencé après un échec de traversée NAT avec Tailscale
  • Les tunnels Zero Trust permettent de relier des réseaux privés, publier des services, construire des réseaux à IP privées et exposer temporairement des services locaux
  • Tout le trafic transite par le réseau Cloudflare sans problème de NAT, et des politiques d’accès granulaires permettent de contrôler les accès entre utilisateurs, bots et serveurs
  • Pour les connexions SSH, une connexion basée sur l’authentification Zero Trust est prise en charge sans ouvrir de port public

Cloudflare Zero Trust vs Tailscale

  • Tailscale tente d’établir des connexions P2P en contournant NAT et pare-feu, et utilise un serveur relais lorsque cela est impossible
  • Avec Cloudflare, à l’exception du Warp-to-Warp, tout le trafic passe par les serveurs edge de Cloudflare : il n’y a donc pas de problème de NAT, au prix d’une légère latence

Différence entre Cloudflared et WARP

  • Client WARP : outil qui connecte le client au réseau Cloudflare et applique les politiques
    • Il s’exécute principalement sur le client, mais peut aussi être utilisé sur un serveur
    • Le routage Warp-to-Warp permet des connexions P2P
  • Cloudflared : outil qui crée un tunnel et l’ajoute au réseau Zero Trust
    • Il s’exécute sur le serveur pour fournir un point d’entrée au réseau
    • La commande cloudflared access permet de se connecter à d’autres ressources Zero Trust
    • Il est possible de créer des tunnels temporaires pour des tests ponctuels

Structure Tunnels, Routes, Targets

  • Tunnels : points de sortie du trafic déployés avec cloudflared
    • Exemple : installation sur un équipement toujours allumé dans un réseau domestique (192.168.1.1/24)
    • Le fichier de configuration (/etc/cloudflared/config.yml) indique où router les requêtes à leur arrivée
    • Exemple : gitlab.widgetcorp.tech → localhost:80, gitlab-ssh → localhost:22
  • Exemple d’exposition publique :
    • homeassistant.mydomain.com → routé vers 192.168.1.3
    • Si le CNAME dans le DNS Cloudflare pointe vers l’adresse du tunnel, l’accès est possible même sans WARP
  • Routes : définissent vers quel tunnel envoyer une plage IP donnée
    • Exemple : l’ensemble de 192.168.1.1/24 ou une IP unique 192.168.1.3/32
    • Lorsqu’une connexion WARP est établie, les requêtes vers ces IP sont transmises au tunnel via le réseau Cloudflare
    • Il est aussi possible de router une IP virtuelle inexistante, par exemple 10.128.1.1
  • Targets : définissent les unités d’infrastructure à protéger
    • Exemple : homeassistant.mydomain.com → 192.168.1.3/32
    • Une politique d’accès peut être appliquée à une cible afin de n’autoriser que certains utilisateurs

Access Policies : contrôle d’accès

  • Une fois les tunnels, routes et cibles configurés, les droits d’accès sont définis via des Access Policies
  • Éléments qui composent une politique
    • Include : conditions autorisant l’accès (OR)
    • Require : conditions devant impérativement être remplies (AND)
    • Action : Allow / Deny / Bypass / Service Auth
  • Exemple 1 – Contrôle d’accès basé sur l’e-mail
    • Seules des adresses e-mail spécifiques sont autorisées
    • Il est aussi possible de limiter l’authentification à une connexion GitHub
  • Exemple 2 – Ignorer la connexion lorsque WARP est connecté
    • Le sélecteur Gateway permet de supprimer l’écran de connexion lorsqu’une connexion Zero Trust WARP est active
    • Si WARP n’est pas connecté, une connexion GitHub est demandée

Déploiement et enregistrement du client WARP

  • Définition de la politique d’enregistrement dans Settings → Warp Client
    • Authentification GitHub et autorisation d’enregistrement limitée à certaines adresses e-mail
    • La définition d’un identifiant d’authentification WARP permet d’utiliser le sélecteur Gateway
  • Profile Settings permet de définir le comportement du client
    • Réglages du protocole (MASQUE/WireGuard), du mode de service, des IP exclues du routage, etc.
    • Installation automatique de la CA Cloudflare, attribution d’une IP CGNAT unique, et configuration du contrôle de l’état des appareils (Device Posture)
  • Une fois connecté sur le client WARP, la connexion au réseau Zero Trust est établie
    • Les requêtes vers 192.168.1.3 sont ensuite routées via le tunnel

Résumé du résultat de l’architecture

  • Enregistrement du client WARP avec une politique de connexion basée sur GitHub et l’e-mail
  • Le tunnel dans le réseau privé transmet les requêtes homeassistant.mydomain.com vers 192.168.1.3
  • Le trafic vers 192.168.1.3 n’est accessible via le tunnel que lorsque WARP est connecté
  • Deux modes d’accès sont proposés : accès public basé sur le DNS et accès privé basé sur WARP
  • Lorsque WARP est connecté, la connexion est ignorée ; sinon, une authentification GitHub est requise

Éléments supplémentaires non abordés

  • Le routage Warp-to-Warp
  • La création d’IP privées réservées à l’usage interne de Zero Trust
  • La configuration des politiques d’authentification SSH
  • Les types d’applications autres que Self-Hosted

Aucune information supplémentaire dans le texte source

À lire aussi

1 commentaires

 
GN⁺ 2025-11-17
Avis Hacker News

  • Cloudflare agit comme un point de terminaison TLS, ce qui est désavantageux pour un usage personnel
    Avec Tailscale Funnel, le certificat est installé directement sur mon endpoint, alors qu’avec Cloudflare, le trafic est déchiffré au milieu puis rechiffré
    Je ne connais pas bien le niveau de confidentialité réseau privée de WARP, mais je pense que la dégradation de la confidentialité est importante pour le tunneling Internet
    Je considère aussi que l’architecture connexion P2P + repli via relais est bien plus souhaitable, car elle peut fonctionner sans intermédiaire tiers

    • J’ai récemment créé moi-même un projet appelé TunnelBuddy
      Le principe consiste à utiliser la machine d’un ami comme nœud de sortie basé sur WebRTC, et ne prend en charge que le P2P, sans serveur TURN/relais
      Le taux de réussite des connexions est faible selon l’environnement NAT, mais comme le trafic ne passe par aucun serveur tiers, la confidentialité est réellement garantie
    • Il est ironique que, sous l’étiquette « Zero Trust », on doive au final faire entièrement confiance à Cloudflare
    • Personnellement, je fais davantage confiance à Tailscale, mais les fonctionnalités de domaine personnalisé et d’accès sans client de Cloudflare sont séduisantes
      On peut monter quelque chose de similaire avec Caddy, mais il faut toujours du port forwarding
    • NetFoundry dans la liste awesome-tunneling est aussi une bonne alternative
      Ses atouts sont le chiffrement de bout en bout et la performance·fiabilité assurées par plus de 100 PoP
    • connet vise une architecture P2P + repli via relais
      Seuls les pairs participants exposent leurs endpoints, ce qui est avantageux du point de vue sécurité et confidentialité
      On peut l’héberger soi-même ou utiliser le service officiel

  • J’utilise Netbird chez moi et à titre personnel
    Je l’ai installé sur un Synology NAS, ainsi que sur tous les laptops, desktops et mobiles de la famille, et c’est pratique à utiliser comme un bureau à distance dans un environnement Tmux

  • Je me suis arrêté de lire à la phrase « tout le trafic passe par le réseau Cloudflare »
    Hyprspace a traversé tous les NAT que j’ai rencontrés, et fonctionne bien sans infrastructure de grand groupe

  • Le texte donne vraiment l’impression d’un excellent guide de configuration
    Cloudflare pourrait le documenter et l’utiliser comme guide officiel

  • J’ai lu un billet expliquant qu’après avoir été frustré par l’incapacité de Tailscale à établir une connexion P2P en environnement NAT, l’auteur s’était mis à apprendre Cloudflare Zero Trust + Warp
    Mais Cloudflare n’essaie même pas le P2P au départ, donc cela revient finalement à basculer vers le modèle de confiance de Cloudflare
    La motivation est difficile à comprendre, mais le texte lui-même est bien structuré

    • Cloudflare dispose d’un réseau mondial de PoP de haute qualité, donc en pratique la qualité était meilleure qu’en P2P
      Notre entreprise est entièrement en remote, et les performances se sont améliorées après être passés de Tailscale à Cloudflare
    • La question essentielle est de savoir si le chiffrement entre pairs est maintenu même en passant par Cloudflare
      Si oui, la différence de modèle de confiance n’est pas si grande, mais Cloudflare mise surtout sur la performance du relais, ce qui lui donne un avantage en vitesse
      Malgré cela, la capacité de NAT hole punching de Tailscale est excellente, donc si possible je préfère une connexion directe

  • J’utilise tuns.sh pour exposer des services personnels
    J’apprécie le fait que, basé sur un tunnel SSH, il soit utilisable immédiatement sans installation

  • Le billet comme les commentaires étaient instructifs
    En revanche, l’image dans le corps de l’article est cassée et renvoie une erreur 404 — par exemple : targets-config-screen.png

  • Je suis heureux de voir enfin des critiques sur le problème majeur de CF
    Je pense qu’il faut une discussion qui pointe les problèmes du modèle Zero Trust

  • Le fait qu’on ne puisse pas faire tourner un serveur Plex avec un compte Cloudflare gratuit est rédhibitoire
    Les conditions concernées peuvent être consultées ici

    • Est-ce que ton FAI fournit par hasard de l’IPv6 ?
      Moi, j’utilise très bien Emby et Jellyfin avec des amis via IPv6
    • Qui s’attendrait à ce que quelqu’un fournisse gratuitement du trafic de streaming vidéo ?
      Contrairement à un simple trafic web, un seul film entraîne des coûts de bande passante des centaines de fois plus élevés
    • Sur mon compte gratuit, cloudflared tunnel fonctionne très bien avec Jellyfin
      Cette méthode m’a été utile parce qu’on ne pouvait pas installer Tailscale sur le laptop professionnel de ma copine
    • En pratique, si le trafic n’est pas important, les conditions d’utilisation ne sont pas appliquées strictement
    • Moi aussi je l’utilise pour Jellyfin, et cela fonctionne sans problème depuis plusieurs mois

  • Je me demande si l’usage de Cloudflare ne relève pas du vendor lock-in
    Je pense qu’au moins Tailscale n’a pas ce type de dépendance

    • J’ai pourtant été surpris d’apprendre que Tailscale était finalement aussi un éditeur commercial
      Je croyais que c’était un projet open source, mais ce n’est pas le cas