CGNAT et Home Assistant — pourquoi votre redirection de port va bientôt cesser de fonctionner

Le symptôme

Un grand classique des forums Home Assistant. Quelqu’un ouvre le port 8123 sur sa box, la règle s’affiche en vert, HA tourne nickel sur le réseau local, mais depuis l’extérieur — rien. Des heures de debug. Pare-feu. DDNS. Certificats. Firmware du routeur. Tout vérifié, rien trouvé. Jusqu’à ce qu’un type plus bas dans le fil pose la seule question qui aurait dû venir en premier : « Au fait, est-ce que tu as vraiment une adresse IPv4 publique ? »

Réponse, en général : « Je crois que oui. »

Puis le conseil : ouvrir whatismyip.com, comparer ce qui s’affiche avec l’IP WAN du routeur. Si les deux ne correspondent pas, le mystère est résolu. CGNAT. Et à ce moment-là, la redirection de port n’est pas cassée d’une façon qui se règle dans le routeur — elle vit dans un segment du réseau que l’internet public n’a jamais eu vocation à atteindre.

Ce qu’est vraiment le CGNAT

Carrier-Grade NAT, parfois appelé Large-Scale NAT, c’est la réponse des opérateurs à la pénurie d’IPv4. Au lieu de donner à chaque ligne client sa propre IPv4 publique, ils mettent en commun un nombre plus réduit d’adresses publiques entre de nombreux clients, avec un gros routeur NAT côté opérateur qui gère la traduction.

Concrètement, pour vous : votre adresse WAN devient soudain privée. Typiquement quelque part dans 100.64.0.0/10, le bloc réservé exactement à cet usage. Un paquet entrant depuis internet n’atteint plus votre routeur — il tombe d’abord sur le NAT du fournisseur, qui n’a aucune idée auquel des mille clients derrière cette IP publique le paquet est destiné, et le jette. Le sortant continue de fonctionner, parce que le NAT garde la trace du chemin de retour pour les connexions que vous initiez.

La redirection de port suppose que votre côté WAN est joignable depuis l’extérieur. Derrière le CGNAT, il ne l’est pas. Reconfigurer le routeur pour la quinzième fois n’y changera rien.

Qui est concerné

Le CGNAT n’est plus un cas marginal :

• Données mobiles : quasiment toutes, partout. Si HA tourne sur un routeur 4G/5G quelque part — résidence secondaire, lien de secours — vous êtes derrière du CGNAT, garanti.
• Nouvelles lignes fibre : beaucoup d’opérateurs fibre récents distribuent du CGNAT par défaut sur les offres grand public les moins chères. Une IPv4 publique fixe, c’est en option, en général payante.
• Câble : de plus en plus, surtout dans les zones nouvellement raccordées.
• DSL : historiquement public. Certains fournisseurs basculent discrètement ici aussi.

Un changement de forfait suffit. Parfois juste un échange de box chez le même opérateur. Et la redirection de port qui marchait hier est morte aujourd’hui.

Test rapide : suis-je concerné ?

Trois minutes :

1. Lire l’IP WAN dans votre routeur.
2. Récupérer l’IP publique vue de l’extérieur. whatismyip.com dans un navigateur, ou curl ifconfig.me dans un terminal.
3. Comparer.
   • Identiques → IPv4 publique, la redirection de port classique fonctionne encore.
   • Différentes, et l’IP WAN commence par 100.64. à 100.127. → CGNAT. La redirection de port ne vous amènera nulle part.
   • Différentes, et l’IP WAN est privée (10.x, 192.168.x, 172.16-31.x) → vous êtes derrière plusieurs couches de NAT, probablement un second routeur en amont. Réparable. Pas du CGNAT.

Contournements, et ce qui cloche dans chacun

Plusieurs voies existent pour obtenir un accès distant derrière le CGNAT. Aucune n’est parfaite.

IPv6

Élégant sur le papier. Les adresses IPv6 sont publiques, chaque appareil a la sienne. Dans la vraie vie, il y a des accrocs. Beaucoup d’opérateurs déploient l’IPv6 de façon opportuniste, sans préfixe stable et sans la moindre promesse. Les fournisseurs DynDNS qui gèrent proprement les enregistrements AAAA se cherchent. Et l’autre bout de la connexion — le Wi-Fi de l’hôtel, le réseau mobile, le réseau invité de l’entreprise depuis lequel vous vous connectez — n’a souvent pas d’IPv6 du tout.

Pour les bidouilleurs, ça marche. Pour un accès distant fiable chez un client, c’est trop branlant.

VPN classique (WireGuard, OpenVPN)

Le serveur VPN a lui aussi besoin d’une IPv4 publique — donc on l’héberge ailleurs. Petit serveur cloud, IP statique. L’hôte HA et le client se connectent tous deux en sortant vers ce serveur VPN, qui fait l’intermédiaire.

Éprouvé. Ancien. Techniquement sous votre contrôle. Le prix : vous opérez un serveur de plus, et un VPN ouvre typiquement tout le réseau. Acceptable pour une seule installation à vous. Déployez ça chez dix clients, et vous avez signé pour une dette de maintenance — et côté client, vous prenez un coup de confiance, parce que « attends, vous avez aussi accès à mon imprimante et mon NAS, c’est ça ? ».

Tailscale

VPN maillé avec relais DERP. Chaque nœud se connecte en sortant vers le plan de contrôle, les relais font l’intermédiaire derrière le CGNAT. Pas de serveur à vous.

Zero-config, fiable, compatible CGNAT, gratuit à petite échelle. Bête connue, sait ce qu’elle fait. Le hic est le même qu’avec WireGuard : installer Tailscale sur un site client, et le voilà dans votre tailnet. Ce qui signifie potentiellement dans son imprimante, son NAS et son babyphone. Un saut de confiance plus grand côté client que ce que le cas d’usage demande vraiment.

Cloudflare Tunnel

Tunnel sortant persistant depuis l’hôte HA vers Cloudflare. Le frontend devient joignable via un sous-domaine. Très stable en pratique, certificats TLS gratuits, compatible CGNAT, bien documenté.

Deux choses à savoir. Le trafic passe par une infrastructure américaine, ce qui devient gênant à expliquer sous RGPD quand on déploie chez des clients. Et c’est du single-instance — dix clients, ça fait dix configurations Cloudflare séparées, chacune avec sa propre charge de maintenance.

Relais WebSocket (tunnel sortant spécialisé)

L’architecture qu’utilise HA Fleet Manager. Une intégration custom Home Assistant ouvre une WebSocket sortante longue durée vers un serveur de relais au démarrage. Quand l’intégrateur a besoin d’un accès distant, un tunnel vers l’interface HA s’ouvre par-dessus cette même connexion — limité dans le temps, et uniquement après consentement explicite du client.

Compatible CGNAT, parce que tout part en sortant. L’accès reste cantonné à l’appareil HA lui-même, pas de VPN sur tout le LAN. Multi-tenant, consentement et journalisation intégrés, hébergement UE possible. Le prix : vous accordez votre confiance à un composant de relais centralisé. Plus facile à avaler quand c’est un fournisseur spécialisé avec une architecture documentée qu’une boîte noire généraliste, mais ça reste une décision de confiance assumée.

Ce que ça veut dire pour l’architecture

Le CGNAT progresse, il ne recule pas. Les opérateurs y gagnent de l’argent réel, et le pool d’IPv4 ne grossira pas. Quiconque tient encore une IPv4 publique aujourd’hui ne devrait pas miser sur l’avoir demain.

La réponse qui tient sur la durée pour Home Assistant, c’est toujours sortante. Pas de redirection de port, pas d’attente de paquets entrants, juste une connexion initiée par l’hôte HA vers un intermédiaire qui s’occupe du reste. Tailscale, Cloudflare Tunnel et les relais WebSocket spécialisés suivent tous ce schéma. Là où ils diffèrent, c’est sur qui fait l’intermédiaire, jusqu’où va l’accès, et comment le consentement et l’audit sont organisés.

Pour une installation HA privée seule, n’importe laquelle de ces options fera l’affaire. Dès que plusieurs installations clientes s’empilent, l’argument d’une plateforme combinant ce tunnel sortant avec du multi-tenant, du monitoring et un workflow de consentement devient difficile à contrer — et c’est précisément la lacune que HA Fleet Manager est venu combler.