Le NAT de niveau opérateur peut-il bloquer l'accès en auto-hébergement même avec le transfert de port ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Can Carrier-Grade NAT Block Self-Hosted Access Even With Port Forwarding?

Oui, le CGNAT peut bloquer l'accès entrant auto-hébergé car votre routeur ne contrôle pas l'adresse IPv4 publique recevant la connexion.

Une règle de redirection de port ne traduit que le trafic qui atteint l'interface WAN du routeur où la règle existe. Sous NAT de niveau opérateur (carrier-grade NAT), le FAI place une autre couche de traduction en amont et partage une adresse IPv4 publique entre plusieurs clients, donc les paquets entrants non sollicités s'arrêtent avant d'atteindre le routeur domestique. La bonne décision est de vérifier si le routeur possède un point de terminaison public, puis de choisir une adresse publique réelle, IPv6 natif, un tunnel sortant, un relais ou un VPN superposé au lieu de modifier sans cesse une redirection qui ne peut pas recevoir de trafic.

Comparer l'adresse WAN du routeur avec l'adresse IPv4 publique

Ouvrez la page d'état du routeur domestique et notez son adresse IPv4 WAN. Depuis un appareil sur la même connexion, comparez cette valeur avec l'adresse rapportée par un service public d'adresse IP externe.

Un explicatif sur le CGNAT pour les auto-hébergeurs indique qu'un routeur peut recevoir une adresse de la plage partagée 100.64.0.0/10 tandis que l'internet extérieur voit une autre adresse publique partagée différente. Les plages privées telles que 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 indiquent également une autre couche NAT.

Si les adresses WAN et publiques correspondent, un CGNAT ordinaire est moins probable et le test suivant concerne la redirection, le pare-feu, le service ou le chemin de retour. Si elles diffèrent, identifiez si la couche en amont est votre propre modem/routeur ou un réseau contrôlé par le FAI.

Comprendre pourquoi la redirection du routeur domestique ne voit pas le paquet

Une redirection sur le routeur domestique associe un port externe sur l'adresse WAN de ce routeur à un serveur interne. Elle ne peut pas créer une association sur un routeur opérateur en amont que le client ne peut pas configurer.

Un cas d'auto-hébergement sur Super User montre un routeur avec une adresse WAN 100.70.x.x et une adresse publique différente, rendant le serveur web inaccessible malgré la redirection locale. Le problème principal est que le FAI possède la traduction externe.

Ne réagissez pas en plaçant le NAS dans une DMZ, en activant toutes les redirections UPnP ou en désactivant le pare-feu hôte. Ces changements augmentent l'exposition à l'intérieur du domicile mais ne créent pas une redirection entrante côté opérateur.

Écarter un double NAT que vous pouvez contrôler

Suivez le chemin physique du modem ou de la passerelle du FAI jusqu'au routeur où la règle de redirection est configurée. Une passerelle fournisseur en mode routeur peut créer la même discordance WAN/public que le CGNAT, mais vous pouvez peut-être la passer en mode pont ou rediriger à travers les deux appareils.

Un guide d'auto-hébergement explique que la redirection de port fonctionne uniquement lorsque votre routeur détient l'adresse publique. C'est la limite architecturale qui sépare une réparation locale de double NAT d'une limitation du FAI.

Si l'appareil en amont vous appartient, placez-le en mode pont ou passthrough, redirigez le même port étroit à travers les deux couches, ou déplacez le service exposé au public vers le premier routeur. Si le réseau en amont est contrôlé par l'opérateur, cessez de le considérer comme une passerelle domestique configurable.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Tester si l'IPv6 natif offre une alternative accessible

Vérifiez si le FAI délègue un préfixe IPv6 global et si le serveur domestique reçoit une adresse globale stable. IPv6 peut rendre le serveur directement adressable sans traduction de port IPv4, mais le pare-feu doit explicitement autoriser uniquement le service prévu.

Testez le nom d'hôte exact et le port depuis un réseau IPv6 externe. Un enregistrement AAAA publié ne suffit pas si le routeur bloque l'IPv6 entrant, si le préfixe change ou si l'application écoute uniquement sur IPv4.

Utilisez IPv6 uniquement lorsque les mises à jour DNS, la politique de pare-feu, TLS, la liaison d'application et les changements de préfixe sont maîtrisés. Ne supposez pas que « pas de NAT » signifie « pas de frontière de sécurité » ; les services routables globalement nécessitent toujours un filtrage au moindre privilège et une authentification.

Choisir un tunnel sortant, un relais ou un VPN superposé si nécessaire

Lorsqu'une adresse publique est indisponible, créez une connexion qui démarre en sortie depuis le réseau domestique. Un fournisseur de tunnel, un relais VPS ou un VPN superposé peut maintenir l'état à travers le CGNAT et fournir un point de terminaison accessible ailleurs.

Une discussion communautaire GL.iNet décrit l'utilisation d'un tunnel client sur routeur domestique qui se connecte à un VPS pour que le serveur externe puisse atteindre le réseau domestique via un tunnel sortant plutôt que de compter sur une redirection côté opérateur.

Choisissez la méthode selon la charge de travail : l'accès privé aux fichiers convient généralement à un VPN superposé authentifié, les applications web publiques peuvent convenir à un tunnel HTTPS contrôlé ou un proxy inverse, et les protocoles nécessitant des ports entrants arbitraires peuvent nécessiter un VPS avec redirection explicite.

Vérifier le chemin de remplacement depuis l'extérieur du domicile

Testez depuis les données mobiles ou un autre réseau externe après configuration du chemin alternatif. Confirmez DNS, authentification, TLS, accès à l'application et le flux réel de fichiers ou d'applications plutôt que de vérifier uniquement si une page d'état de tunnel indique connecté.

La comparaison ZimaSpace de VPN, tunnels et redirection de port aide à adapter la solution aux accès privés, à la diffusion d'applications publiques et aux risques de maintenance.

La décision est complète lorsque vous pouvez expliquer qui possède le point de terminaison public, où le trafic entrant se termine et comment le serveur domestique l'authentifie. Si le FAI fournit plus tard une adresse publique, supprimez les règles obsolètes de relais ou de tunnel avant de réintroduire la redirection directe.