J'adore mon Homelab. C'est mon terrain de jeu, mon bac à sable géant où tournent Home Assistant, mes services de médias, mes petits projets perso... Mais il faut être honnête, la sécurité, c'est souvent le parent pauvre. On bricole un VPN, on ouvre deux-trois ports sur la box en croisant les doigts, et on espère que ça tiendra. J'ai longtemps été de ceux-là, jonglant entre OpenVPN et WireGuard, avec l'éternel dilemme des ports exposés.
Et puis, il y a le concept de SASE (Secure Access Service Edge). Ça sonne un peu comme un buzzword marketing, mais en gros, c'est l'idée d'unifier le réseau et la sécurité en une seule plateforme, avec un principe fort : le Zero Trust. En clair, on ne fait confiance à personne, ni à l'intérieur, ni à l'extérieur, tant que l'identité et le contexte ne sont pas vérifiés. Pour un Homelab, ça veut dire accéder à ses services internes sans ouvrir un seul port sur son routeur, même derrière un CGNAT. Magique ? Non, juste une approche moderne.
C'est là que j'ai découvert Pangolin, une solution SASE open-source. Une alternative auto-hébergeable à des géants comme Cloudflare One ou Tailscale, mais avec un contrôle total sur mon infrastructure. Et croyez-moi, l'idée de sécuriser mon Homelab sans galérer avec des règles de pare-feu complexes m'a tout de suite séduit. Voici mon retour d'expérience sur l'installation et la configuration de cette petite merveille.
Pangolin : la bête à cornes de la sécurité
Pangolin, c'est donc une plateforme SASE open-source construite sur WireGuard. Derrière ce nom d'animal un peu mignon, se cache une solution robuste qui unifie le VPN Zero Trust, un proxy inverse Zero Trust, et la gestion des accès privilégiés. L'objectif est simple : connecter et protéger les utilisateurs et les ressources, où qu'ils soient, sans jamais ouvrir de ports entrants sur votre réseau privé. C'est développé par Fossorial et le dépôt GitHub principal est fosrl/pangolin.
Concrètement, qu'est-ce que ça offre pour nous, les Homelabbers ?
- Accès Zero Trust : Chaque tentative d'accès à une ressource est vérifiée, quelle que soit l'origine.
- Pas de ports ouverts : C'est le Graal ! Pangolin établit des tunnels sortants depuis votre Homelab vers un serveur central (votre serveur Pangolin), rendant vos services accessibles sans exposer votre IP publique. Idéal pour les CGNAT.
- Basé sur WireGuard : Rapide, léger et moderne.
- Proxy inverse intégré : Pour exposer vos applications web HTTPS en toute sécurité.
- Accès SSH, RDP, VNC : Sécurisez l'accès à vos machines distantes.
Pour vous donner une idée, c'est un peu comme si vous aviez Cloudflare Tunnels, Tailscale et un proxy inverse type Nginx Proxy Manager, le tout unifié et sous votre contrôle. Il existe différentes éditions de Pangolin, dont une Community Edition open-source, et une Enterprise Edition qui est gratuite pour un usage personnel et les entreprises réalisant moins de 100 000 USD de revenus annuels bruts. Pas mal, non ? La version la plus récente au moment où j'écris est la 1.25, sortie en octobre 2026. Oui, le futur est déjà là !
Préparation du terrain : votre Homelab sous stéroïdes
Avant de plonger dans l'installation, il y a quelques prérequis. Ne vous inquiétez pas, rien de bien sorcier pour un Homelabber aguerri :
- Un serveur VPS avec une adresse IP publique : C'est le cœur de votre infrastructure Pangolin. Il hébergera le hub central. Un petit VPS chez un hébergeur classique fera l'affaire.
- Un nom de domaine : Vous aurez besoin d'un domaine (ou sous-domaine) que vous contrôlez, pour que Pangolin puisse générer les certificats Let's Encrypt et gérer les accès.
- Docker et Docker Compose : Évidemment, on ne se passe plus de ces outils magiques pour déployer nos services.
- Ports ouverts sur votre VPS : Assurez-vous que les ports suivants sont accessibles sur votre pare-feu VPS :
22/TCP(pour SSH, si vous ne l'avez pas déjà)80/TCPet443/TCP(pour le tableau de bord web et les applications que vous exposerez)51820/UDP(pour WireGuard)21820/UDP(pour le connecteur de site Pangolin)
C'est tout ! Votre Homelab lui-même n'aura pas besoin d'ouvrir de ports entrants, ce qui est une excellente nouvelle.
Installation de Pangolin : le décollage sans accroc
L'installation de Pangolin se fait en deux temps : le serveur central (sur votre VPS) et le client/agent de site (sur une machine de votre Homelab).
Le connecteur de site : relier le Homelab à Pangolin
Avant de connecter mon ordinateur portable, il faut déjà donner à Pangolin un chemin vers les services de la maison. C'est le rôle du connecteur de site : une petite porte de sortie contrôlée, installée sur une machine capable de joindre les applications internes.
Il faut bien distinguer deux usages : le connecteur de site relie le Homelab à Pangolin, tandis que le client utilisateur permet à un ordinateur distant d'accéder aux ressources privées autorisées. Les deux participent à la connexion, mais ne jouent pas le même rôle.
Pour cette installation Docker, je pars sur Newt, le connecteur léger du projet. La documentation recommande désormais le CLI Pangolin pour les nouveaux sites, mais Newt reste disponible et convient très bien à ce déploiement en conteneur.
Dans le tableau de bord, créez un site pour votre Homelab, puis récupérez sa configuration. Vous aurez notamment un identifiant, un secret et l'adresse de votre serveur Pangolin. Le secret mérite le même traitement qu'un mot de passe : il n'a rien à faire dans un dépôt Git public ou une capture d'écran de blog.
Le tableau de bord fournit les informations nécessaires au déploiement. Voici à quoi ressemble une configuration Docker Compose minimale :
services:
newt:
image: fosrl/newt:latest
restart: unless-stopped
environment:
PANGOLIN_ENDPOINT: https://pangolin.mondomaine.com
NEWT_ID: VOTRE_IDENTIFIANT_DE_SITE
NEWT_SECRET: VOTRE_SECRET_DE_SITEPour une installation que vous souhaitez faire évoluer tranquillement, remplacez ensuite latest par une version précise, compatible avec votre serveur. Cela évite de découvrir un changement de comportement au détour d'une mise à jour.
Une fois les valeurs remplacées, démarrez le connecteur depuis le dossier contenant votre fichier Compose :
docker compose up -d
docker compose logs --tail=50 newtLe site doit apparaître connecté dans Pangolin. À ce stade, le tunnel existe, mais aucune application n'est encore publiée : il reste à définir les ressources accessibles et leurs autorisations.
Un détail mérite votre attention : Newt doit pouvoir joindre les services ciblés depuis son propre environnement réseau. Dans un conteneur, localhost désigne ce conteneur, pas votre NAS ni votre serveur Docker. Utilisez une adresse du réseau local ou un nom de service accessible sur un réseau Docker partagé.
Publier une première application web
Pour commencer, choisissez une application simple. Un petit tableau de bord interne fera très bien l'affaire : inutile de démarrer avec le service dont toute la famille dépend pour regarder son film du soir.
Dans Pangolin, créez une ressource web publique associée à votre site. Le terme publique décrit ici son mode d'accès : elle possède une adresse accessible depuis Internet. Vous pouvez néanmoins en protéger l'accès par une authentification Pangolin.
La configuration consiste à relier trois éléments :
- Une adresse externe, par exemple
dashboard.mondomaine.com, dont le DNS pointe vers le VPS. - Un site, celui de votre Homelab.
- Une cible interne, par exemple un service HTTP disponible sur
192.168.200.50:8080.
Activez ensuite l'authentification de la ressource et accordez l'accès à votre utilisateur ou à un rôle adapté. Le tunnel transporte le trafic ; les règles d'accès décident qui peut l'emprunter. Ce sont deux réglages distincts, et c'est justement leur association qui rend l'ensemble intéressant.
Pour vérifier le résultat, ouvrez l'adresse depuis une connexion extérieure, par exemple votre téléphone en réseau mobile. Faites aussi un essai en navigation privée : une session déjà ouverte peut masquer une erreur de configuration des accès.
Le résultat attendu est simple : un visiteur non authentifié rencontre la protection Pangolin, un utilisateur autorisé accède à l'application et un utilisateur sans permission reste bloqué.
Accéder aux ressources privées depuis son ordinateur
Pour administrer une machine en SSH ou ouvrir une session RDP, je préfère définir une ressource privée et passer par le client Pangolin. Cela permet d'autoriser un accès précis sans publier directement le service sur Internet.
Sur un poste Linux utilisant le CLI seul, l'installation et la connexion passent par les commandes suivantes :
curl -fsSL https://static.pangolin.net/get-cli.sh | bash
pangolin login
pangolin upPendant l'authentification, sélectionnez votre instance auto-hébergée et votre organisation. Le client donne ensuite accès aux ressources privées que vos permissions autorisent. Installer le client ne dispense donc pas de définir les ressources et leurs droits dans le tableau de bord.
Pour un premier essai, limitez-vous à une machine et au port nécessaire. Vous pourrez élargir les accès ensuite, si vous en avez réellement besoin. Donner accès à tout le réseau parce que « ça ira plus vite » reste une excellente façon de retrouver les habitudes que l'on essayait justement d'améliorer.
Vous utilisez ensuite votre logiciel habituel pour rejoindre la ressource : client SSH, bureau à distance ou autre outil adapté. L'accès réseau fourni par Pangolin ne remplace pas automatiquement l'authentification du service cible : vos clés SSH et vos comptes système gardent tout leur intérêt.
Le piège : croire que le tunnel fait toute la sécurité
Ne plus rediriger de ports sur la box est confortable, mais cela ne fait pas disparaître l'exposition. Pour les applications web publiées, le point d'entrée se trouve désormais sur le VPS. Il faut donc entretenir ce serveur, protéger son administration et vérifier les règles appliquées aux ressources.
Une application accessible sans authentification restera accessible sans authentification, même si le trajet vers votre maison emprunte un tunnel chiffré. Le mot « Zero Trust » dans la présentation du produit ne configure pas les permissions à votre place.
Dans mon Homelab, je garderais quelques règles simples :
- Un compte par personne, avec les seuls accès nécessaires.
- Une authentification multifacteur sur les comptes qui administrent la plateforme.
- Des ressources précises, plutôt qu'un accès général au réseau par facilité.
- Des services à jour, aussi bien sur le VPS que derrière le connecteur.
- Un accès local de secours, pour intervenir si Pangolin ou le VPS devient indisponible.
Et attention aux applications mobiles, aux API et aux webhooks : une page de connexion interactive placée devant une application web peut perturber les logiciels qui s'attendent à recevoir directement une réponse de leur serveur. Testez ces usages séparément avant de considérer la migration comme terminée.
Ce que cette architecture change au quotidien
L'intérêt dépasse finalement la question des ports ouverts. On commence à raisonner en ressources et en utilisateurs : qui peut consulter ce tableau de bord ? Qui peut administrer cette machine ? Quel service doit réellement être accessible depuis l'extérieur ?
C'est aussi une façon plus propre de partager un accès ponctuel. Donner accès à une application précise est plus facile à comprendre et à retirer que distribuer une configuration VPN donnant une visibilité trop large sur le réseau.
Il reste évidemment des contraintes. Le VPS devient un composant important de l'installation, et ses ressources comme sa bande passante doivent correspondre à vos usages. Pour des interfaces d'administration, les besoins seront très différents de ceux d'un serveur multimédia utilisé à distance pendant plusieurs heures.
Je ne donnerai donc pas de chiffre magique de performances : le débit dépend de votre connexion montante, de l'hébergement et du chemin réellement emprunté. Un test avec vos propres services sera beaucoup plus instructif qu'une promesse universelle.
Un Homelab plus accessible, avec des accès mieux définis
Ce qui me plaît dans Pangolin, c'est de pouvoir réunir l'accès aux applications et la gestion des permissions dans un ensemble auto-hébergeable. On conserve la main sur le serveur central, tout en évitant de transformer sa box en catalogue de redirections de ports.
Ce n'est pas une raison pour jeter un WireGuard qui répond déjà parfaitement au besoin. En revanche, dès que l'on veut partager plusieurs applications, gérer plusieurs utilisateurs ou relier différents sites, cette approche devient particulièrement intéressante.
Le bon point de départ reste modeste : un site, une application et un utilisateur. On valide l'accès depuis l'extérieur, on vérifie qu'un compte non autorisé reste bloqué, puis on étend progressivement. Le Homelab reste un terrain de jeu ; autant savoir à qui l'on confie les clés.