Dans mon précédent article, j'évoquais la genèse de mon Home Lab. Aujourd'hui, je vais vous parler d'une problématique concrète que j'ai rencontrée début 2024 et de la première architecture que j'ai mise en place pour la contourner.

Le défi de la 5G : Adieu IP publique, bonjour CGNAT

Tout a commencé quand j'ai troqué ma connexion ADSL tombée en rade pour un routeur 5G. Si le gain en débit était indéniable, j'ai vite déchanté sur un point crucial : l'accessibilité externe.

À l'époque de l'ADSL, j'avais une IP publique fixe. Il me suffisait de configurer mon domaine (chez Amen) et quelques règles de NAT sur ma box pour accéder à mon serveur Apache hébergé sur mon Home Lab. Avec la 5G, c'est une autre histoire. Les opérateurs mobiles utilisent massivement le CGNAT (Carrier-Grade NAT). En résumé : mon routeur ne reçoit pas d'IP publique, mais une IP privée au sein du réseau de l'opérateur. Je partageais ma sortie vers internet avec des milliers d'autres abonnés.

Conséquence directe : impossible d'ouvrir des ports ou de joindre mon réseau local depuis l'extérieur. J'étais invisible.

La quête d'une solution de Tunneling

Pour contourner le CGNAT, la solution technique est de passer par un tunnel initié depuis l'intérieur du réseau (mon serveur) vers un point de sortie public.

J'ai d'abord envisagé les VPNs proposant des IPs publiques dédiées. Si les offres d'appel semblaient alléchantes, la réalité économique m'a vite rattrapée : une fois les remises initiales terminées, le coût mensuel devenait prohibitif pour un simple usage personnel.

Il me fallait donc une solution SaaS capable de créer ce tunnel sans me ruiner. Ayant déjà un pied dans l'écosystème Microsoft, j'ai cherché du côté des services compatibles ou gratuits sur Azure et c'est là que j'ai découvert XTNA (XplicitTrust Network Agent).

XTNA : L'approche "Zero Trust" facile ?

XplicitTrust propose une solution de ZTNA (Zero Trust Network Access). Le principe est séduisant : un service Cloud permet de monter des tunnels chiffrés (souvent basés sur WireGuard sous le capot) entre des machines, peu importe où elles se trouvent.

À l'époque, ils proposaient un plan gratuit pour un usage personnel (sur demande au support, qui a été très réactif). L'architecture était simple :

  1. Côté Serveur : j'installe l'agent XTNA en mode "serveur" sur ma machine à la maison. Il initie une connexion sortante vers le cloud XplicitTrust (contournant ainsi le problème du CGNAT).
  2. Côté Client : j'installe l'agent sur mes périphériques distants.

Le lien était fait, mais il fallait sécuriser la porte d'entrée.

Sécurisation avec Azure Entra ID

XTNA ne gère pas seulement le tuyau, il gère aussi l'identité. Pour s'authentifier sur le réseau, il fallait un fournisseur d'identité (IdP) robuste.

C'est là qu'Azure Entra ID (anciennement Azure AD) entre en jeu. La version gratuite d'Entra ID est généreuse (jusqu'à 5 utilisateurs actifs mensuels, il me semble). J'ai donc configuré XTNA pour déléguer l'authentification à Microsoft.

Le résultat était fonctionnel : une interface d'administration en ligne simple pour gérer mes tunnels, et une authentification "pro" pour accéder à mes services. J'avais accès à mon Home Lab depuis mon PC portable et mon téléphone Android, où que je sois.

Pourquoi j'ai abandonné cette solution

Malgré le fait que "ça marche", j'ai rapidement senti que cette architecture n'était pas pérenne pour moi. Plusieurs frictions se sont accumulées :

1. La dépendance (trop) forte

Moi qui cherche via le Self-Hosting à m'émanciper des GAFAM et à reprendre le contrôle de mes données, j'étais servie :

  • Azure : Dépendance critique pour l'authentification.
  • XplicitTrust : Mon serveur maintenait un tunnel ouvert 24h/24 vers leurs infrastructures. Même si le trafic est chiffré, cela reste une "boîte noire" au cœur de mon réseau.

2. La complexité réseau au quotidien

L'utilisation de XTNA induisait la création d'un réseau virtuel avec ses propres plages d'adresses IP.

  • Jonglage d'IPs : Je devais utiliser une IP spécifique (celle du tunnel) quand j'étais à l'extérieur, et mon IP locale quand j'étais chez moi. Il me fallait également configurer mes services pour qu'ils acceptent ces deux IPs.
  • Problème de DNS : Bien que XTNA permette théoriquement de définir des DNS, la fonctionnalité était capricieuse sur l'application mobile Android à l'époque. C'était le périphérique que j'utilisais le plus, et devoir taper des IPs ou modifier mes configurations en permanence devenait vite agaçant.

3. La lourdeur des agents

Le modèle "Zero Trust" pur implique souvent d'installer un agent sur chaque périphérique client. Devoir installer un logiciel et me ré-authentifier régulièrement via Entra ID sur chaque appareil pour accéder à un simple service web était une contrainte trop forte pour mon usage "domestique".

En résumé, XTNA m'a sauvé la mise lors de ma transition 5G, mais la philosophie ne collait pas avec ma vision d'un Home Lab souverain et fluide. Il me fallait une autre approche... que je vous détaillerai dans le prochain article !