Le réflexe classique pour accéder à son NAS ou à son serveur depuis l'extérieur, c'est la redirection de port : on ouvre le 443 sur la box, on le pointe vers la machine, et c'est réglé. Sauf que ça revient à publier son homelab sur l'internet entier. Les scanners de masse trouvent le port en quelques heures — pas parce qu'on vous vise, mais parce que tout l'espace IPv4 est balayé en continu.
Le tunnel sortant règle le problème par l'autre bout : au lieu de laisser entrer, on sort.
Le principe : inverser le sens de la connexion
Un connecteur installé sur votre réseau ouvre une connexion sortante et persistante vers l'infrastructure de Cloudflare. Quand un visiteur demande votre nom de domaine, la requête arrive chez Cloudflare, qui la fait redescendre par ce canal déjà établi jusqu'au connecteur, lequel la transmet au service local.
Trois conséquences directes :
- Aucun port entrant à ouvrir. Votre pare-feu peut refuser la totalité du trafic entrant, le tunnel continue de fonctionner.
- Votre IP publique n'est jamais exposée. Les visiteurs ne voient que les adresses de Cloudflare. Votre ligne résidentielle n'est plus une cible.
- L'IP peut changer librement. Plus besoin d'IP fixe ni de DNS dynamique : c'est vous qui initiez la connexion.
Ce que ça protège, et ce que ça ne protège pas
C'est le point qui mérite d'être posé clairement, parce que le raccourci « c'est derrière un tunnel donc c'est sécurisé » fait des dégâts.
Ce qui disparaît réellement : le scan de ports, l'exploitation directe d'un service exposé, les tentatives de connexion en force sur un port ouvert, et le DDoS volumétrique — absorbé en amont par Cloudflare.
Ce qui ne change pas : le trafic HTTP légitime atteint toujours votre application. Une interface d'administration sans mot de passe reste sans mot de passe, une version obsolète reste vulnérable, une injection reste injectable. Le tunnel déplace la frontière du réseau ; il ne durcit pas le logiciel.
La couche qui manque souvent : l'authentification
C'est là que Cloudflare Access intervient. Il s'insère avant que la requête n'atteigne le tunnel et impose une authentification — fournisseur d'identité, code par e-mail à usage unique, ou jeton de service pour les accès machine.
La différence est structurelle : un visiteur non authentifié est refusé au bord du réseau Cloudflare, sans jamais atteindre votre machine. Votre service ne voit passer que du trafic déjà validé. Pour tout ce qui est interface d'administration, tableau de bord, ou service personnel, c'est le complément indispensable du tunnel — pas une option de confort.
Pour les appels automatisés qui ne peuvent pas passer par un écran de connexion, les jetons de service permettent de conserver la protection sans casser les intégrations.
Les pièges qui cassent une installation
Le connecteur lancé à la main
La panne la plus banale. Le connecteur est démarré dans un terminal pour tester, tout marche, et on passe à autre chose. Au premier redémarrage de la machine, tout tombe. Il doit être installé comme service supervisé, avec redémarrage automatique — exactement comme le service qu'il publie.
Le connecteur trop bavard sur le réseau
Le tunnel supprime l'exposition externe, mais la machine qui l'héberge conserve son accès complet au réseau local. Si elle est compromise, elle devient un point d'entrée vers tout le reste. Le connecteur doit pouvoir joindre le service qu'il publie, et rien d'autre. Un conteneur dédié sur un réseau restreint est plus sain qu'un binaire lancé en root sur l'hyperviseur.
L'absence de règle de repli
La configuration d'ingress associe des noms d'hôtes à des destinations internes, et elle est évaluée dans l'ordre. Sans règle finale explicite qui refuse tout le reste, une requête ne correspondant à aucun hôte peut atteindre une destination inattendue. La dernière règle doit toujours être un refus.
Le mauvais port dans la configuration
Piège discret et redoutablement chronophage : une règle qui pointe vers un port où rien n'écoute ne provoque pas d'erreur de configuration. Le tunnel monte normalement, le domaine répond, et l'on obtient un comportement incohérent selon les chemins. Après tout changement d'ingress, vérifiez que le port visé correspond bien au service qui écoute réellement.
Les limites à connaître avant de se lancer
Le tunnel fait transiter votre trafic par un tiers, qui le déchiffre pour appliquer ses règles. Pour un service personnel c'est un compromis raisonnable ; pour des données réglementées, la question mérite d'être posée en amont plutôt qu'après.
Par ailleurs, tout dépend d'un fournisseur unique : son indisponibilité rend vos services inaccessibles, même si les machines fonctionnent parfaitement. C'est le prix de la simplicité, et il vaut mieux le choisir en connaissance de cause.
En résumé
Le tunnel sortant est la bonne réponse à un mauvais réflexe. Il élimine la redirection de port, l'IP fixe et l'exposition directe — trois causes majeures de compromission en homelab — pour un coût de mise en œuvre très faible.
Mais il ne remplace ni l'authentification, ni les mises à jour, ni la segmentation réseau. Un tunnel devant un service non authentifié et non maintenu, c'est une porte mieux cachée sur une serrure toujours cassée. Le tunnel gère l'exposition ; le reste du travail vous appartient toujours.
Commentaires