Vérifiez votre type de NAT instantanément

Il s’agit de l’adresse IPv4 publique signalée pendant le test. Un routeur ou votre fournisseur d’accès peut traduire une adresse privée avant que le trafic n’atteigne Internet. Plusieurs appareils ou abonnés peuvent donc partager une adresse publique.

Une adresse seule ne confirme ni un CGNAT ni un Double NAT. Un VPN peut également modifier l’adresse publique observée par le test.

Lorsqu’un port est disponible, le nombre après les deux-points dans le résultat IPv4 est un port UDP observé lors de ce test dans le navigateur. Par exemple, 203.0.113.10:62000 indique une adresse et le port signalé, 62000.

Ce n’est ni un port de jeu, ni une règle de redirection de port, ni une preuve qu’un service est accessible à cette adresse. Les associations peuvent changer d’un test ou d’une destination à l’autre, notamment avec un NAT symétrique.

Ce résultat décrit le comportement UDP en IPv4 observé sur le chemin testé. NAT 1 correspond à un NAT à cône complet, NAT 2 à un NAT à cône restreint, NAT 3 à un NAT à cône restreint par port et NAT 4 à un NAT symétrique. Internet ouvert est un résultat distinct pour un chemin sur lequel aucun NAT n’a été observé.

Ce sont les libellés utilisés par NAT Checker pour les catégories de RFC 3489. PlayStation, Xbox et les autres plateformes ont leurs propres libellés et tests. Le type de NAT ne mesure pas le débit de téléchargement et ne garantit pas que chaque jeu puisse se connecter à chaque pair. Sélectionnez « Comment nous classons le NAT » pour consulter la logique de décision.

Il s’agit d’une adresse IPv6 globale fournie par votre navigateur pendant la vérification IPv6. Les adresses uniquement locales sont exclues. La détection IPv6 est indépendante du test NAT en IPv4.

Une adresse seule ne prouve pas la connectivité externe. « IPv6 non détecté » signifie que ce test n’a trouvé aucune adresse IPv6 globale ; cela ne démontre pas que votre fournisseur d’accès ou votre appareil ne peut pas prendre en charge IPv6.

« Connectivité externe confirmée » signifie que notre service de test IPv6 a signalé une connexion WebRTC/UDP réussie sur ce chemin. La simple découverte d’une adresse IPv6 ne suffit pas à produire ce résultat.

« La connectivité externe n’a pas pu être confirmée » signifie que ce chemin n’a pas pu être établi. Des règles de pare-feu, un VPN, des restrictions du navigateur ou les conditions du réseau peuvent affecter la vérification. La navigation habituelle en IPv6 peut encore fonctionner, car elle utilise d’autres connexions et protocoles. Une expiration du délai ou une erreur du service signifie que la vérification n’a pas abouti.

Le serveur de test NAT renvoie le résultat Bloqué lorsqu’il ne peut pas établir ce chemin UDP. Ce résultat n’identifie pas l’appareil ou le réglage à l’origine de l’échec.

Un délai dépassé signifie qu’aucune classification finale n’est arrivée pendant la durée du test. Une erreur ou le message « Service temporairement indisponible » signifie que le test n’a pas pu aboutir. Ces résultats ne constituent pas des classifications NAT 1–4 confirmées. Réessayez, puis vérifiez les restrictions du navigateur, les VPN et les réglages du pare-feu avant d’attribuer le problème au routeur ou au fournisseur d’accès.

RFC 3489 distingue les NAT en comparant les associations d’adresse IP et de port publics et en vérifiant quelles sources de réponse peuvent atteindre le même socket UDP local. Modifier la source d’une réponse et modifier la destination d’une requête testent des comportements différents.

1. Test I : envoyer une requête STUN Binding Request normale. La réponse fournit MAPPED-ADDRESS, l’adresse IP publique et le port UDP observés par le serveur. Comparer ces deux valeurs à l’adresse et au port du socket local pour déterminer s’il y a eu traduction.
2. Test II : demander une réponse provenant d’une autre adresse IP et d’un autre port du serveur. Sa réception montre qu’un émetteur externe que le client n’a pas contacté peut atteindre l’association.
3. Test I vers une autre destination : envoyer une requête normale depuis le même socket local vers le point de terminaison alternatif indiqué par CHANGED-ADDRESS. Comparer la nouvelle adresse IP publique et le port à la première association pour détecter une association dépendante de la destination.
4. Test III : demander une réponse provenant de l’adresse IP d’origine du serveur, mais d’un autre port. Cela distingue un filtre entrant fondé uniquement sur l’IP d’un filtre exigeant la correspondance de l’adresse IP et du port.

Ce sont les vérifications de classification du RFC. Notre test dans le navigateur obtient l’association publique avec STUN et utilise des vérifications de connectivité WebRTC assistées par le serveur pour renvoyer la catégorie de comportement correspondante.

1. Test I reçoit une réponse et l’adresse IP publique ou le port associés diffèrent du point de terminaison du socket local : un NAT est donc présent.
2. Test II reçoit une réponse provenant d’une autre adresse IP et d’un autre port du serveur, alors que le client n’a envoyé aucun trafic à cette source de réponse.
3. Dans l’arbre de décision de RFC 3489, il s’agit d’un NAT à cône complet (Full Cone), que nous appelons NAT 1.

Une fois une association UDP créée, d’autres émetteurs externes peuvent l’atteindre sans contact préalable. Cela facilite généralement les connexions directes entre pairs ; cela ne signifie pas que tous les ports sont ouverts.

1. Un NAT est présent, mais Test II ne reçoit aucune réponse depuis l’adresse IP et le port modifiés.
2. Un nouveau Test I vers l’autre destination renvoie la même adresse IP publique et le même port associés que la première requête. L’association ne change pas pour cette destination.
3. Test III reçoit une réponse depuis l’adresse IP d’origine du serveur, sur un autre port. Un contact préalable avec cette IP suffit ; il n’est pas nécessaire d’avoir contacté le port exact de la réponse.

Il s’agit d’un NAT à cône restreint (Restricted Cone), notre NAT 2. Le trafic UDP entrant est autorisé depuis les adresses IP externes que le client a déjà contactées.

1. Un NAT est présent et Test II ne reçoit aucune réponse depuis l’adresse IP et le port modifiés.
2. Test I vers l’autre destination renvoie la même adresse IP publique et le même port associés, ce qui écarte une association dépendante de la destination dans cette comparaison.
3. Test III ne reçoit pas non plus de réponse lorsque seul le port source du serveur change. Dans le modèle du RFC, le trafic entrant doit correspondre à une adresse IP et à un port déjà contactés par le client.

Il s’agit d’un NAT à cône restreint par port (Port-Restricted Cone), notre NAT 3. L’association reste identique dans cette comparaison, mais le filtre entrant est plus strict qu’avec NAT 2.

1. Un NAT est présent et Test II ne reçoit aucune réponse depuis l’adresse IP et le port modifiés.
2. Répéter Test I depuis le même socket UDP local vers le point de terminaison alternatif du serveur.
3. Si l’adresse IP publique ou le port associés diffèrent de la première association, l’arbre de décision du RFC identifie un NAT symétrique (Symmetric), notre NAT 4.

Par exemple, une destination peut observer 203.0.113.10:62000 et une autre 203.0.113.10:62001. Un changement de port suffit ; l’adresse IP publique n’a pas besoin de changer elle aussi. Un point de terminaison découvert auprès d’un serveur peut donc ne pas convenir à un autre pair, et certaines applications peuvent avoir besoin d’un relais.

Si Test I ne reçoit aucune réponse, le processus de découverte de RFC 3489 indique UDP Blocked. Dans un test réalisé par le navigateur, un chemin UDP en échec ou incomplet peut aussi être affecté par les réglages du navigateur, un VPN, un pare-feu, la disponibilité du service ou des pertes de paquets ; cela ne permet pas, à lui seul, de localiser la cause.

Si Test I réussit et que l’adresse IP et le port associés sont tous deux identiques au point de terminaison du socket local, aucun NAT n’est observé. La réussite de Test II identifie alors Internet ouvert (Open Internet). Si Test II échoue sur ce chemin sans NAT, le RFC parle de Symmetric UDP Firewall. Il s’agit d’un filtrage sans traduction d’adresse, pas d’un NAT symétrique, et il ne faut pas le confondre avec NAT 4.

Nos libellés de résultat ne proposent pas de catégorie distincte Symmetric UDP Firewall. Un test incomplet ou une erreur du service ne constitue pas non plus une catégorie de NAT confirmée.

STUN, décrit dans RFC 8489, permet au navigateur de connaître une adresse publique et un port UDP observés en dehors du réseau local. ICE, décrit dans RFC 8445, utilise des vérifications de connectivité pour établir un chemin entre deux points de terminaison.

RFC 3489 définit les catégories NAT à cône complet, NAT à cône restreint, NAT à cône restreint par port et NAT symétrique, ainsi que les tests d’association et de réponse qui les distinguent. Nous utilisons cette logique de classification avec notre navigateur et nos serveurs de test ; la découverte de l’adresse IPv6 et la connectivité externe font l’objet de vérifications séparées.

Le résultat décrit le chemin UDP testé par ce navigateur. Les VPN, les pare-feu et les restrictions du navigateur peuvent l’affecter. Un réseau réel peut combiner des comportements d’association et de filtrage que les libellés historiques de NAT ne décrivent pas entièrement.

Le test ne confirme ni un CGNAT ni un Double NAT, ne vérifie pas tous les ports des applications et ne garantit ni le libellé NAT d’une console ni toutes les connexions entre pairs. Une adresse IPv6 publique ne prouve pas la connectivité UDP externe.

RFC 3489 précise aussi qu’une nouvelle découverte utilisant le même socket local peut réutiliser d’anciennes associations NAT et fausser le résultat. Une nouvelle découverte utilise un autre point de terminaison local ou attend l’expiration des associations précédentes ; les résultats décrivent le réseau au moment de la vérification.