Cloudflare Tunnel comme alternative à l'ouverture de ports

Tout savoir sur Cloudflare Tunnel sans ouverture de port

Dans le cadre d'une ouverture de port classique, un client externe se connecte directement à l'adresse IP publique du routeur ou du serveur. Le routeur transfère ensuite le trafic entrant vers un service situé sur le réseau interne. Un Cloudflare Tunnel inverse ce processus d'établissement de connexion : le connecteur cloudflared fonctionne sur le réseau interne accessible et établit lui-même des connexions sortantes vers Cloudflare.

Lorsqu'un utilisateur accède, par exemple, à un portail d'administration, Cloudflare reçoit la requête concernant son nom d'hôte et la transmet au connecteur via une connexion tunnel déjà établie. Celui-ci atteint le service de destination configuré, par exemple http://localhost:8080. L'Origin ne nécessite donc ni adresse IP accessible directement depuis Internet, ni autorisation de pare-feu pour ce service.

Cela ne signifie pas pour autant que les règles de réseau ne s'appliquent plus. L'hôte avec cloudflared Cloudflare doit pouvoir communiquer avec l'extérieur. Cloudflare spécifie pour cela le port 7844 via TCP ou UDP ; les protocoles HTTP/2 et QUIC sont respectivement utilisés. Le trafic sortant doit être autorisé dans le pare-feu local, au niveau du routeur et, le cas échéant, via un proxy d’entreprise. C’est là la limite pratique que recouvre l’expression „ sans ouverture de port “.

Une entrée DNS ne suffit pas à elle seule à établir ce canal de connexion sécurisé. Le DNS se contente d'associer un nom à une adresse de destination ; il n'initie aucune connexion depuis le réseau privé et ne fournit aucun service local. Le connecteur de sortie est l'élément clé : il connaît le service cible interne et maintient ouvert le chemin menant à celui-ci, de l'intérieur vers l'extérieur. Les utilisateurs autorisés à emprunter ce chemin doivent être configurés séparément.

Un tunnel ne constitue pas une protection d'accès

Un tunnel réduit la visibilité directe de l'origine sur le réseau, mais ne détermine pas de manière autonome les autorisations. Si un panneau d'administration Web est acheminé via un nom d'hôte public, il peut en principe être consulté par n'importe quel internaute sans application Access en amont. Cloudflare recommande donc de configurer Access en amont de la route du tunnel en production. Le tunnel est le moyen de transport, pas le contrôle d'accès.

Pour un panneau d'administration privilégié, il faudrait une Politique d'accès n'autoriser que des personnes ou des groupes clairement définis. Outre les critères « Include », « Require » et « Exclude », des actions telles que « Allow », « Block », « Bypass » et « Service Auth » sont disponibles. L'authentification multifactorielle (MFA) peut être imposée via un fournisseur d'identité connecté ou en tant que facteur supplémentaire. Une règle générale applicable à tous les comptes d’un domaine de messagerie est généralement trop restrictive pour les interfaces à privilèges élevés.

La couche d'accès complète la sécurisation de l'application, mais ne la remplace pas. Le panneau d’administration nécessite toujours une connexion sécurisée, des mises à jour régulières, des règles de session appropriées et une attribution parcimonieuse des droits. Les comptes utilisateurs locaux, les rôles et les droits d’administration restent également essentiels : si un utilisateur obtient l’accès à l’application après s’être connecté via Access, cette personne ne doit pas y se voir automatiquement attribuer des droits d’administration plus étendus.

Il convient également de vérifier si l'application valide les jetons d'accès ou si elle utilise l'option de tunnel prévue à cet effet pour la vérification des jetons. Cela lie l'application à la vérification d'identité en amont et réduit les risques liés à un accès alternatif involontaire à l'origine. Une architecture en couches est recommandée : publication restrictive, vérification d'identité avec authentification multifactorielle (MFA), droits d'accès minimaux à l'application et un service cible accessible en interne, mais non exposé au grand public.

Classer HTTP, SSH, RDP et TCP

Les applications HTTP(S) et les protocoles d'administration présentent des modèles d'accès différents. Une interface Web interne peut être publiée via un nom d'hôte et sécurisée à l'aide d'Access devant l'origine. SSH, RDP et certains services TCP peuvent également être accessibles via des tunnels, mais nécessitent, selon le protocole utilisé, un logiciel supplémentaire côté client ou un accès via un navigateur. Une connexion Web ne se traduit pas automatiquement par un accès réseau natif quelconque.

Pour SSH avec le terminal local habituel, il est possible d'utiliser, côté client, cloudflared Établir la connexion via Access. Cloudflare documente par ailleurs le SSH rendu par le navigateur comme un mode d'accès distinct. Ces deux variantes diffèrent en termes de workflow client, de configuration SSH locale et d’utilisation ; elles ne sont donc pas interchangeables de manière générale. Les déclarations concernant des modèles d’infrastructure ou de certificats plus avancés ne doivent être intégrées dans une planification que si leur documentation actuelle et pertinente a été vérifiée séparément.

Un terminal SSH rendu par navigateur peut s'avérer pratique pour l'assistance technique ou un accès d'urgence urgent lorsqu'aucun client SSH local n'est disponible. Avant toute mise en œuvre, il convient toutefois d’évaluer les exigences d’audit, les procédures d’utilisation, les méthodes de clés locales et les transferts de fichiers. Le RDP et les autres services TCP doivent également être examinés au cas par cas, plutôt que d’être traités de manière globale comme une interface Web.

Tunnel ne constitue pas un substitut à part entière pour toutes les connexions réseau. Les protocoles initiés par le serveur, tels que la VoIP ou le SIP, ne sont pas pris en charge ; les sessions TCP de longue durée et sensibles aux interruptions nécessitent également un test de compatibilité. De plus, pour les protocoles SSH, RDP et TCP, Origin ne voit pas l’adresse IP d’origine du client, mais celle du connecteur. Avec HTTP, une application peut CF-Connecting-IP analyser. Les listes d'autorisation basées sur les adresses IP et les journaux d'analyse doivent tenir compte de cette limite.

Attribuer plusieurs services en toute sécurité

Un fichier Ingress local associe chaque nom d'hôte publié à une seule destination interne. Il est judicieux d'utiliser des noms distincts pour le panneau d'administration et SSH : cela permet de séparer clairement les autorisations, les journaux et les modifications ultérieures. Cloudflared évalue les règles de haut en bas ; la première règle correspondante détermine la destination.

L'exemple suivant est un modèle de configuration pour un tunnel géré localement. Il utilise délibérément example.invalid et ne contient ni identifiants d'accès ni domaine réel. Le service web reste sur localhost:8080 accessible ; les requêtes SSH sont redirigées vers le service SSH local.

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

ingress:
  - hostname: admin.example.invalid
    service: http://localhost:8080
  - hostname: ssh.example.invalid
    service: ssh://localhost:22
  - service: http_status:404

La dernière règle est la suivante : règle générale. Elle est nécessaire pour les fichiers Ingress locaux et assure ici, avec http_status:404 pour éviter qu'un nom d'hôte inconnu ne soit acheminé par erreur vers le premier service interne venu ou vers tout autre service interne. Un routage standard à grande échelle constituerait un risque inutile, en particulier vers des cibles administratives.

Ce fichier définit uniquement le chemin entre le tunnel et Origin. Il ne configure pas les enregistrements DNS et ne protège pas les noms via Cloudflare Access. Avant de mettre en place une route en production, il faut donc configurer séparément le nom d'hôte et la politique d'accès. Au niveau local également, les ports de destination ne doivent être accessibles que là où cloudflared en a réellement besoin.

Avant le démarrage, il est possible de vérifier l'ordre des règles sans modifier les paramètres. La première commande valide la configuration d'Ingress ; la seconde indique quelle règle s'appliquerait à l'adresse spécifiée.

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://admin.example.invalid

Sélectionner de manière ciblée les accès SSH

L'accès SSH via un tunnel n'est pas un mode d'accès unique. Le choix de la variante appropriée dépend du fait que les administrateurs continuent d’utiliser leur terminal local ou qu’ils doivent travailler sans client préconfiguré en cas de panne. Les modèles disponibles diffèrent en termes de client, d’identité et de procédure d’utilisation ; la configuration concrète de SSHD et la gestion des droits locaux restent indépendantes de cela.

Pour une petite équipe qui utilise régulièrement des outils locaux courants, la solution « cloudflared » côté client convient souvent : le port SSH reste interne, tandis qu’Access ajoute une couche d’authentification supplémentaire avant l’établissement de la connexion. Cela n’équivaut toutefois pas à une gestion centralisée de toutes les autorisations SSH.

L'accès via le navigateur doit être considéré comme un processus distinct. Il peut s'avérer utile en cas d'assistance ou d'accès imprévu, car il ne nécessite pas de client SSH configuré. Il ne s'agit toutefois pas d'une méthode d'administration systématiquement meilleure : les transferts de fichiers, les procédures habituelles de clés locales et les exigences d'audit peuvent rendre un client terminal ou un accès privé plus appropriés.

Quel que soit le chemin d'accès, les couches de protection locales restent en place. Comptes Linux, Règles relatives à sudo, la configuration du SSHD et les droits sur le système cible continuent de déterminer ce qu'un utilisateur connecté avec succès est autorisé à faire. Le tunnel ne remplace ni ces règles ni l'attribution de droits limités.

Pour les services non-HTTP publiés, l'utilisation de cloudflared côté client peut s'avérer nécessaire ; SSH offre par ailleurs un accès via un navigateur. Il ne faut donc pas planifier à la hâte les services RDP et autres services TCP en suivant le modèle SSH, mais en tenant compte de leurs exigences respectives en matière de clients et d'exploitation.

Tunnel, VPN, serveur bastion ou ouverture de port

Ce choix ne porte pas seulement sur la question de savoir si un port est ouvert, mais aussi sur l'étendue souhaitée de l'accès. Cloudflare Tunnel est particulièrement adapté à un petit nombre de services clairement identifiés. En revanche, ceux qui doivent accéder à de nombreux systèmes internes et segments de réseau ont généralement besoin d'un modèle d'accès au réseau privé plutôt que d'un ensemble de publications individuelles.

Une ouverture de port classique n'est pas mauvaise en soi. Elle peut convenir à un service délibérément public, dont la protection des applications, le fonctionnement du pare-feu et l'accessibilité publique font l'objet d'une gestion ciblée. À l'inverse, dans le cas d'un tunnel, c'est le connecteur qui établit la connexion à partir du réseau interne ; il n'est pas nécessaire d'accéder directement à l'origine depuis Internet.

Pour un seul panneau d'administration ou un petit ensemble d'objectifs de maintenance, une publication par service avec accès basé sur l'identité généralement plus faciles à circonscrire qu'un tunnel réseau global. Cela ne dispense toutefois pas de vérifier le protocole : les protocoles initiés par le serveur ne sont pas pris en charge, et les longues sessions TCP sensibles aux interruptions peuvent nécessiter d'autres modèles de connectivité.

Un VPN reste utile lorsque les collaborateurs ont besoin de plusieurs applications privées, plages d'adresses ou dépendances internes. Un hôte bastion, en revanche, concentre les accès SSH vers un point d'entrée unique, qui doit lui-même être soigneusement sécurisé et géré. Un proxy inverse constitue quant à lui une couche dédiée à la terminaison TLS et à la mise à disposition des applications ; il ne répond pas à lui seul à la question de savoir comment accéder à l’origine privée. Les rôles de proxy, de serveur d’applications et de gestionnaire de processus peuvent également être assurés dans le Comparaison entre NGINX Unit et PHP-FPM de suivre.

La décision pratique commence donc par une délimitation : quelles personnes ont besoin d'accéder à quel service et avec quel client ? Plus cette réponse est restreinte, plus il est facile d'exploiter un tunnel avec des noms d'hôtes et des règles précis. En revanche, des besoins réseau étendus, des protocoles spécifiques ou des exigences élevées en matière de stabilité des sessions justifient une évaluation distincte.

Assurer la sécurité des tunnels en service

Un tunnel actif ne se résume pas à une simple connexion ponctuelle. Cloudflare recense, pour chaque tunnel « cloudflared », quatre connexions sortantes persistantes vers au moins deux de ses propres centres de données. Ainsi, si un chemin de connexion vient à tomber en panne, les requêtes peuvent être acheminées via un autre chemin existant. Cela réduit les dépendances sur le trajet entre le connecteur et Cloudflare, mais ne rend pas pour autant le service interne hautement disponible.

Pour les applications critiques, plusieurs instances de cloudflared peuvent utiliser le même tunnel en tant que répliques. Cela crée des chemins supplémentaires entre le réseau Cloudflare et le réseau privé, mais ne remplace ni une application redondante, ni une stratégie de base de données ou d’hébergement. Si, par exemple, le seul serveur hébergeant le panneau d’administration est inaccessible, les autres connecteurs présents sur ce serveur ou sur d’autres serveurs ne seront utiles que s’ils parviennent effectivement à atteindre le service cible opérationnel. chemin de connexion La planification de la disponibilité des services doit donc être effectuée séparément.

Si plusieurs origines doivent être vérifiées de manière ciblée, contournées en cas de dysfonctionnement ou réparties selon des règles, un équilibrage de charge supplémentaire avec des contrôles d'intégrité et un routage du trafic est nécessaire. Un tunnel seul ne prend pas ces décisions de manière approfondie. L'architecture doit également définir comment le service cible sera rétabli après une panne et si des accès administratifs restent nécessaires pendant la panne.

La disponibilité ne se limite pas au logiciel. Si le connecteur et le système cible se trouvent dans un local technique dédié, l'alimentation électrique, le refroidissement, la qualité de l'air et les contrôles réguliers doivent également être pris en compte dans le concept d'exploitation. L'analyse suivante met en évidence les risques environnementaux supplémentaires qui peuvent survenir dans ce contexte : Ventilation d'une salle de serveurs située au sous-sol. De telles mesures ne remplacent pas les répliques, mais elles empêchent que tous les chemins de connexion prévus échouent en raison d'une même dépendance vis-à-vis de l'infrastructure locale.

Les mises à jour de cloudflared doivent être effectuées pendant une fenêtre de maintenance planifiée : elles entraînent un redémarrage et peuvent donc affecter le trafic en cours de traitement. Cloudflare propose l'équilibrage de charge ou l'utilisation de plusieurs instances de cloudflared comme options pour des mises à jour sans interruption. Le choix de la méthode de mise à jour appropriée dépend du type d'installation et de l'environnement d'exploitation, et doit être documenté avant la fenêtre de maintenance.

Pour chaque mise à jour, consignez la version installée, l'hôte responsable, une solution de secours et un test d'accessibilité du service cible. Après le redémarrage, vérifiez non seulement l'état du tunnel, mais aussi si la règle Ingress définie atteint bien le service attendu et si la couche d'accès prévue reste effective. Ainsi, le connecteur, le service cible et le chemin d'autorisation restent traçables en tant que tâches opérationnelles distinctes.

Détecter rapidement les erreurs de configuration courantes

Avant la mise en service, le dépannage du connecteur commence : l'hôte doit pouvoir accéder à Cloudflare sortant via le port 7844 en TCP ou UDP. On peut s'attendre à ce que le port entrant ne soit pas ouvert, mais pas à un pare-feu sortant bloquant systématiquement le trafic. Ce n'est que lorsque cloudflared parvient à établir les connexions sortantes qu'il vaut la peine d'examiner le DNS, les noms d'hôte et les règles d'accès au niveau de l'application.

1. Vérifier l'accessibilité locale : le service mentionné dans la règle Ingress doit être accessible depuis l'hôte cloudflared via le point de terminaison local ou interne spécifié.
2. Synchroniser le DNS et Ingress : le nom d'hôte public doit correspondre à l'itinéraire de tunnel prévu ; l'ordre des règles doit faire en sorte que la règle spécifique au service soit appliquée avant les règles plus générales.
3. Tester la règle « catch-all » : une règle finale avec http_status:404 empêche que des noms d'hôte non prévus soient redirigés vers un service par défaut.
4. Configurer Access avant sa mise en production : ce n'est qu'ensuite qu'il sera possible de tester de manière contrôlée le chemin d'accès externe avec un compte autorisé et un compte non autorisé.

Une erreur de sécurité courante consiste à définir une route trop large : au lieu de n'autoriser l'accès qu'à un panneau d'administration ou à un service SSH bien précis, on rend accessible une partie plus vaste du réseau. Les règles générales relatives aux domaines de messagerie pour les interfaces privilégiées présentent un risque tout aussi important. Pour les accès d'administration, des groupes restreints et vérifiables, des critères « Require » adaptés et l'authentification multifactorielle (MFA) doivent refléter le cercle réel des personnes autorisées. Autorisation minimale Cela signifie également qu'il ne faut pas regrouper inutilement des noms d'hôtes et des services cibles distincts.

La configuration des tunnels et des autorisations répond à des besoins différents. La règle d'entrée (Ingress) détermine où aboutit une connexion déjà établie ; la règle d'accès (Access) décide qui est authentifié et autorisé avant cela. Sans application Access adaptée, un nom d'hôte HTTP publié peut être accessible depuis Internet. Les comptes locaux, les règles sudo, les paramètres SSHD et le renforcement de la sécurité de l'application restent donc des points de contrôle distincts.

La limite relative à l'adresse IP source est importante pour les journaux et les audits : avec SSH, RDP et d'autres accès TCP, le serveur de destination ne voit pas l'adresse IP d'origine du client, mais le contexte du connecteur. Les listes d'autorisation basées sur l'adresse IP au niveau du système cible ne constituent donc pas un moyen fiable d'identifier les utilisateurs. Les applications HTTP peuvent exploiter l'en-tête CF-Connecting-IP, à condition que leur journalisation et leur chaîne de confiance en tiennent délibérément compte.

Choisir la solution d'accès adaptée

Cloudflare Tunnel convient à un panneau d'administration Web unique lorsque le service doit être accessible via un nom d'hôte clair, sans fournir d'adresse IP d'origine publique ni d'autorisation d'accès entrant. La configuration recommandée consiste à définir une destination restreinte, précédée d’une application d’accès dotée d’un petit groupe d’identités et d’une authentification multifactorielle (MFA). Cette méthode protège le chemin réseau, mais ne remplace ni la gestion sécurisée des sessions ni la vérification des droits d’accès au sein du panneau d’administration.

Une petite équipe d'administrateurs habituée à travailler en terminal peut utiliser SSH via Cloudflared et Access côté client. Le SSH rendu par navigateur convient particulièrement comme accès d'urgence ou d'assistance préparé à l'avance. Ces deux méthodes présentent des exigences différentes en matière de client et d’utilisation ; le transfert de fichiers, les workflows et les exigences d’audit doivent être adaptés à la méthode choisie. Le choix de modèles plus avancés pour les autorisations SSH centralisées ne doit se faire qu’en se basant sur leur documentation spécifique et à jour.

Si vous avez besoin de nombreux services internes, de segments entiers ou d’une communication est-ouest à grande échelle, vous devriez envisager un accès réseau privé tel qu’un VPN ou un modèle de connectivité prévu à cet effet. Un simple tunnel publié ne remplace pas automatiquement l’ensemble des charges de travail VPN. Le tunnel n’est pas adapté aux protocoles initiés par le serveur, tels que la VoIP ou le SIP ; de même, les sessions TCP de longue durée et sensibles aux interruptions nécessitent une analyse du protocole concerné et des conséquences éventuelles d’une reconnexion.

Une ouverture de port classique peut se justifier lorsqu'un service est délibérément proposé directement au public et que le pare-feu, la protection de l'origine ainsi que l'authentification des applications sont gérés en conséquence. Un hôte bastion centralise les accès SSH, mais reste lui-même un point d'entrée qu'il convient de sécuriser avec un soin particulier. Un proxy inverse, quant à lui, constitue une couche dédiée à la terminaison TLS et à la mise à disposition des applications ; il ne répond pas à lui seul à la question de savoir comment accéder à l'origine privée.

La norme minimale en matière de productivité est la suivante : périmètre cible réduit au strict minimum, règles basées sur l'identité, authentification multifactorielle (MFA) pour les rôles privilégiés, configuration testée d'Ingress et de Catch-all, processus de mise à jour planifié et procédure de restauration documentée. Plan de reprise Cela comprend au moins la définition des responsabilités, la mise en place de chemins de secours et la vérification que le service cible et le connecteur sont à nouveau accessibles après une intervention de maintenance. Les tunnels réduisent la surface d'exposition du réseau, mais ils ne remplacent pas le renforcement de la sécurité des applications, les autorisations locales ou la surveillance continue de l'exploitation.