Architecture v1 : XTNA, ou comment survivre sans IP publique
Adieu l'ADSL, bonjour la 5G... et la perte de mon IP publique (CGNAT) ! Découvrez comment j'ai tenté de sauver l'accès à mon Home Lab via XTNA et Azure Entra ID, et pourquoi cette solution "Zero Trust" n'a pas survécu à mes envies de liberté.
Dans l'article précédent, j'expliquais comment la perte de mon IP publique (suite au passage forcé en 5G) avait rendu mon infrastructure inaccessible depuis l'extérieur. Voici la première architecture que j'ai mise en place pour contourner ce problème.
Le CGNAT, une prison invisible
À l'époque de l'ADSL, j'avais une IP publique fixe. Configurer mon domaine chez Amen et quelques règles de NAT suffisaient pour accéder à mon serveur depuis n'importe où. Avec la 5G, c'est une autre histoire.
Les opérateurs mobiles utilisent massivement le CGNAT (Carrier-Grade NAT) : mon routeur ne reçoit pas d'IP publique, mais une adresse privée au sein du réseau de l'opérateur, partagée avec des milliers d'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'un tunnel
La solution technique au CGNAT consiste à créer un tunnel initié depuis l'intérieur du réseau vers un point de sortie public. J'ai d'abord envisagé des VPNs proposant des IPs dédiées — mais le coût mensuel, une fois les offres d'appel terminées, devenait rapidement prohibitif pour un usage personnel.
Il me fallait 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 avec Azure — et c'est là que j'ai découvert XTNA (XplicitTrust Network Agent).
XTNA : le Zero Trust à portée de main
XplicitTrust propose une solution de ZTNA (Zero Trust Network Access) basée sur des tunnels chiffrés WireGuard. À l'époque, ils proposaient un plan gratuit pour usage personnel, sur demande au support — qui s'est montré très réactif.
L'architecture reposait sur deux composants :
- Côté serveur (homelab) : un agent XTNA initie une connexion sortante vers le cloud XplicitTrust, contournant ainsi le CGNAT sans ouvrir le moindre port entrant.
- Côté client (appareils distants) : un agent installé sur chaque périphérique se connecte via ce même cloud.
L'authentification déléguée à Azure Entra ID
XTNA ne gère pas seulement le tunnel, il gère aussi l'identité. Pour sécuriser l'accès, j'ai délégué l'authentification à Azure Entra ID (anciennement Azure AD), dont la version gratuite couvre jusqu'à 5 utilisateurs actifs mensuels.
Le résultat était fonctionnel : une interface d'administration centralisée pour mes tunnels, une authentification solide, et un accès à mon homelab depuis mon PC portable et mon téléphone, où que je sois.
Pourquoi j'ai abandonné
Malgré le fait que "ça marchait", plusieurs frictions se sont accumulées, jusqu'à rendre la solution incompatible avec ma vision d'un homelab souverain.
La dépendance trop forte
Mon infrastructure reposait sur deux services tiers que je ne maîtrisais pas :
- Azure pour l'authentification : dépendance directe à Microsoft
- XplicitTrust pour le tunnel : mon serveur maintenait une connexion ouverte 24h/24 vers leurs infrastructures, une boîte noire au cœur de mon réseau, dont la gratuité à long terme restait floue
La complexité réseau au quotidien
XTNA crée un réseau virtuel avec ses propres plages d'adresses IP. Résultat : une IP différente selon qu'on soit en local ou à l'extérieur, des configurations de services à dupliquer, et un DNS capricieux sur l'application Android — précisément l'appareil que j'utilisais le plus. Devoir taper des IPs à la main ou ajuster ses configurations en permanence, c'est vite épuisant.
La lourdeur des agents clients
Le modèle Zero Trust implique d'installer un agent sur chaque appareil et de se ré-authentifier régulièrement via Entra ID. Acceptable en entreprise avec un MDM. Trop contraignant pour un usage domestique.
XTNA m'a sauvé la mise le temps de trouver mieux. Mais la philosophie ne collait pas : trop de boîtes noires, utilisation de services de GAFAM, trop de friction au quotidien. Il me fallait une autre approche : un canal transparent entre un VPS que je contrôle et mon réseau local, sans agent côté client. C'est ce que j'ai construit avec FRP et Caddy, décrit dans l'article suivant.