Accéder à son homelab de partout, sans reverse proxy exposé

La pile classique du homelab exposé, et ce qu'elle coûte

Pour rendre un homelab joignable de l'extérieur, la recette traditionnelle empile plusieurs briques : une redirection de port sur la box vers un reverse proxy (Nginx, Caddy, Traefik…), un certificat TLS par nom de service, une couche d'authentification devant les interfaces d'administration, un fail2ban ou équivalent pour absorber les tentatives de connexion, et un DNS dynamique pour suivre l'adresse IP publique quand elle change. Chaque brique est raisonnable prise isolément ; c'est l'ensemble qui pèse.

• Une surface d’attaque permanente — un port ouvert est scanné en continu. Chaque service derrière le reverse proxy est à un défaut de configuration ou à une faille près d’être accessible à n’importe qui.
• De la maintenance récurrente — renouvellements de certificats, mises à jour de sécurité du proxy et de la couche d’authentification, règles fail2ban à ajuster, configuration à refaire quand un service s’ajoute.
• Une dépendance à l’adresse publique — le DynDNS suit l’IP qui change, et l’édifice suppose qu’une adresse publique existe. Derrière un CGNAT (fibre récente, 4G/5G), il n’y a simplement aucun port à ouvrir : la pile classique est impossible à héberger là.
• Un tout-ou-rien implicite — le même point d’entrée public sert à la fois l’interface de l’hyperviseur, le gestionnaire de mots de passe et le blog. Or ces trois-là n’ont pas du tout le même public.

Le modèle inverse : rien d'exposé, tout joignable

VIGIL-MESH renverse le raisonnement. Au lieu d’ouvrir une porte dans le pare-feu pour laisser entrer le trafic, chaque machine — le serveur du homelab comme le portable en déplacement — établit uniquement des connexions sortantes, un seul flux en 443 UDP, le même port que le web moderne. Aucun port entrant, aucune redirection sur la box, aucune règle de pare-feu à créer. La connexion s’établit immédiatement via un relais, puis migre sans coupure vers le chemin direct dès que la traversée NAT aboutit — y compris derrière un CGNAT, là où la pile classique ne peut pas exister.

Les sessions sont des connexions QUIC/TLS 1.3 chiffrées de bout en bout entre les machines, avec un établissement de clés hybride post-quantique (X25519 + ML-KEM). Chaque machine reçoit une adresse stable (dans 100.64.0.0/10) et un nom MagicDNS : vous joignez « nas » ou « proxmox » par leur nom, depuis n'importe où, exactement comme sur le réseau local. La résolution de ces noms est purement locale, servie depuis une carte réseau signée : aucune requête DNS ne quitte la machine pour les noms du mesh.

Autre différence qui compte pour un homelab : chaque réseau VIGIL-MESH est un domaine de diffusion. Le multicast et le broadcast IP y circulent, chiffrés de bout en bout, si bien que la découverte d'appareils — mDNS/Bonjour, SSDP/UPnP, WS-Discovery — fonctionne à travers le mesh comme sur un même segment local. Les applications qui trouvent votre NAS ou vos appareils multimédia par annonce continuent de les trouver quand vous êtes à distance, là où la plupart des VPN purement L3 laissent tomber cette découverte.

À quoi ressemble un homelab sur le mesh

Concrètement, rien ne change dans le homelab lui-même : les services tournent comme avant, sur les mêmes machines et les mêmes ports. Ce qui change, c'est la manière de les atteindre. Le client s'installe sur les machines (Windows, Linux, Android, Jetson) ou dans l'hôte ou la VM qui les porte, et chaque service devient joignable par le nom de sa machine, suivi du port habituel du service.

• L’hyperviseur — l’interface web de Proxmox VE (par défaut sur le port 8006) s’ouvre par le nom de la machine hôte, sans jamais être exposée à Internet.
• Le NAS — interface d’administration, partages de fichiers et sauvegardes s’atteignent par le nom du NAS, comme depuis le salon.
• La supervision — un tableau de bord Grafana, un Portainer ou tout autre outil d’administration se consulte à distance par nom, sans couche d’authentification publique ajoutée devant.
• La forge et les mots de passe — une instance Gitea ou un Vaultwarden restent strictement privés : joignables par les membres du réseau, invisibles depuis Internet.
• La domotique — Home Assistant (par défaut sur le port 8123) se pilote depuis l’extérieur sans exposition publique de son interface.

Ces exemples sont génériques à dessein : VIGIL-MESH n'a pas d'intégration par application, et n'en a pas besoin. Tout ce qui parle IP — interface web, SSH, partage de fichiers, flux vidéo — traverse le mesh tel quel. Si le service marche en local, il marche à distance, par le même nom.

Séparer le privé du public

Un homelab héberge en réalité deux familles de services que la pile classique confond : ceux qui n'ont qu'un seul utilisateur légitime — vous — et ceux qui sont faits pour être lus par tout le monde, comme un blog ou une galerie publique. Le bon modèle les traite différemment : le mesh pour le privé, une publication explicite pour le public.

Une publication ne vise qu'un seul service : le visiteur voit une URL, et rien d'autre. Il n'apprend ni la topologie du homelab, ni les noms des machines, ni l'existence des services restés privés. Publier le blog n'ouvre pas l'accès au NAS d'à côté. Et pour un service non web, une publication TCP existe — en gardant à l'esprit que le flux est alors relayé tel quel, au protocole d'assurer son propre chiffrement.

Souveraineté : ce qui tourne chez vous, ce qui n'y tourne pas

Le lecteur qui auto-héberge veut savoir précisément où passent ses octets et de qui il dépend. Disons-le sans détour. Le chemin des données est chiffré de bout en bout : relayé ou direct, le contenu de vos sessions n'est lisible que par vos machines. Quand un relais intervient — le temps que le chemin direct s'établisse, ou en permanence si les deux NAT s'y opposent —, ce relais (la « vigie ») est structurellement aveugle : il ne détient pas les clés et ne voit jamais le contenu.

Et vous pouvez héberger la vigie vous-même. Une vigie privée s'installe sur votre propre serveur — il lui faut une IP publique et trois ports entrants (udp/443, udp/4433, tcp/443) —, s'enregistre auprès du contrôleur avec un jeton à usage unique, et sert exclusivement votre espace de travail : vos octets relayés ne transitent alors que par une machine à vous. Le guide complet est sur /docs/vigie-privee ; la vigie autonome est en préversion, la boucle d'enrôlement complète est en cours de qualification.

Inviter la famille ou un ami, sans donner les clés du lab

Vient toujours le moment où quelqu'un d'autre doit accéder à un service : le serveur multimédia pour la famille, un partage de fichiers pour un ami. Avec la pile exposée, cela finit souvent en compte partagé sur une interface publique. Sur le mesh, l'invitation est un enrôlement comme un autre — mais encadré par les politiques d'accès (ACL).

Les ACL de VIGIL-MESH refusent par défaut : appartenir au réseau n'ouvre aucun droit en soi, et seul ce qui est explicitement autorisé passe. Les règles se rédigent par identité — machines, groupes, étiquettes —, jamais par adresse IP : une règle « le groupe invités peut joindre la machine du serveur multimédia, et rien d'autre » reste vraie quel que soit l'appareil que l'invité utilise ou le réseau d'où il se connecte. Chaque changement de politique produit une génération signée par le contrôleur, que chaque client vérifie avant de l'appliquer.

• Enrôlez l’appareil de l’invité avec une clé à usage unique, et placez-le dans un groupe dédié (par exemple « invités »).
• Écrivez une règle minimale : le groupe invités vers la seule machine concernée, éventuellement restreinte au seul service utile. Tout le reste — hyperviseur, NAS, mots de passe — reste refusé par défaut.
• Révoquez quand c’est fini : la révocation est immédiate, et l’appareil perd aussitôt l’accès aux flux directs comme aux diffusions.

Mettre en place l'accès distant

La mise en place ne demande ni reverse proxy, ni certificat, ni règle de pare-feu. C'est gratuit pour un usage personnel : le trafic direct est illimité, un quota s'applique au seul trafic relayé.

1. 1
   Créez un compte et un espace de travailL'espace de travail regroupe vos machines et vos réseaux ; c'est depuis sa console que tout s'administre.
2. 2
   Installez le client sur les machines concernéesLe serveur du homelab (ou l'hôte qui porte ses services) et les appareils depuis lesquels vous voulez y accéder : poste de travail, portable, téléphone Android.
3. 3
   Enrôlez chaque machinePage Réseaux → Machines → « Ajouter une machine », avec une clé à usage unique par appareil.
4. 4
   VérifiezChaque machine reçoit son adresse stable et son nom MagicDNS ; un ping par nom depuis le portable confirme que le chemin est en place.
5. 5
   Accédez à vos servicesOuvrez l'interface du service via le nom de sa machine et son port habituel, comme en local — depuis chez vous, en déplacement, ou derrière la 4G.

À partir de là, la pile exposée peut se démonter pièce par pièce : la redirection de port se ferme, le DynDNS et le fail2ban perdent leur raison d'être pour l'accès privé, et le reverse proxy — s'il reste — ne sert plus que ce qui est réellement public.

Questions fréquentes