Quelle adresse IP la page de recherche affiche-t-elle ?
Lorsque vous ouvrez la page Recherche d’adresse IP, vous voyez l’adresse de sortie visible par ce service pour la requête en cours. Si le service utilise un proxy inverse fiable, il résout généralement aussi l’adresse client transférée selon sa propre configuration. Cette adresse n’est pas forcément celle de la carte réseau de votre ordinateur : dans un réseau IPv4 domestique, une traduction d’adresses réseau (NAT) est souvent en place, et il peut y avoir en amont une autre couche de NAT, un proxy ou un VPN. Notez séparément « l’adresse de l’appareil », « l’adresse WAN du routeur » et « la valeur observée par la page web », au lieu de les appeler toutes votre IP publique.
Le proxy et le VPN peuvent modifier ou non la sortie web, selon les règles de routage et de répartition du trafic. Un proxy de navigateur peut ne transférer que les requêtes web, et un VPN système peut ne transporter que les segments du réseau interne de l’entreprise ; seule la configuration en tunnel complet enverra tout le trafic internet concerné vers la passerelle VPN. Ainsi, différentes applications du même appareil, ou les connexions IPv4 et IPv6, peuvent passer par des sorties différentes. Une requête web seule ne suffit pas pour déterminer qui a attribué l’adresse, si elle est dédiée, ou si l’appareil utilise un VPN. Il faut examiner la configuration réseau réellement active à ce moment-là.
Les adresses privées ou partagées se trouvent généralement dans l’état de la carte réseau locale, de la box ou de l’interface WAN du routeur. Une requête internet publique normale ne doit pas considérer les adresses RFC 1918 ou RFC 6598 comme une sortie cliente routable mondialement ; si la page affiche une telle valeur, vérifiez d’abord s’il s’agit d’une information locale ou d’un problème de configuration de transfert. Le caractère public d’une adresse ne garantit pas sa réputation : une adresse routable peut avoir un historique d’abus, et une adresse privée ne participe pas directement à la comparaison de réputation publique. Pour plus de détails, consultez Réputation IP : comprendre les scores et listes de blocage.
Appareil, routeur et opérateur : les quatre couches d’adresses
Commencez par comprendre les adresses selon quatre positions. La première couche est l’adresse que votre appareil utilise sur le réseau local, par exemple 192.168.50.8 ; la deuxième est l’interface WAN du routeur domestique, qui peut recevoir une adresse publique ou une adresse privée attribuée par la box en amont ; la troisième est le réseau de l’opérateur, où dans un déploiement CGNAT, l’adresse côté utilisateur est traduite par l’opérateur vers une adresse publique pour communiquer, et le côté utilisateur peut utiliser 100.64.0.0/10 ; la quatrième est la source de la requête observée par le service cible. Si un proxy est également utilisé, la cible voit la sortie du proxy.
Voici un exemple clairement marqué comme illustratif de double NAT domestique. Supposons qu’une box soit configurée en mode routeur par l’opérateur ; l’adresse LAN de la box est 192.168.1.1, et l’opérateur attribue à son interface WAN l’IP publique 203.0.113.10 (adresse d’exemple, pas une adresse utilisateur réelle). L’utilisateur connecte un routeur sans fil, dont le port WAN reçoit 192.168.1.100 de la box et dont l’adresse LAN est 192.168.50.1. Le téléphone de l’utilisateur obtient l’adresse 192.168.50.8. Lorsque le téléphone accède à un site de requête IP, le routeur sans fil change d’abord l’adresse source en 192.168.1.100, puis la box la change en 203.0.113.10, et le serveur voit finalement 203.0.113.10. Localement, le téléphone voit l’IP LAN 192.168.50.8, et l’interface du routeur affiche l’IP WAN 192.168.1.100 ; aucune n’est publique, mais la sortie finale est une adresse publique. Cet exemple illustre uniquement l’ordre des traductions d’adresses, et ne représente aucun environnement utilisateur réel.
Si l’adresse WAN du routeur est 100.64.0.2 et que la sortie web est une autre IPv4 routable mondialement, cela correspond à une traduction d’adresses en amont, mais confirmez l’architecture exacte auprès de l’opérateur. Si le WAN est 192.168.1.2, cela peut être un mode routeur de la box, un deuxième routeur ou une passerelle d’entreprise supérieure ; cette valeur seule ne vous dit pas quel appareil effectue la NAT. Documenter la topologie et les rôles de chaque interface est plus utile pour le dépannage que de capturer une seule adresse.
Identification précise des adresses privées et de l’espace d’adresses partagé
La RFC 1918 définit trois plages IPv4 privées : 10.0.0.0/8, de 10.0.0.0 à 10.255.255.255 ; 172.16.0.0/12, de 172.16.0.0 à 172.31.255.255 ; 192.168.0.0/16, de 192.168.0.0 à 192.168.255.255. Toutes les IPv4 commençant par 10 sont dans la première plage, mais toutes les adresses commençant par 172 ou 192 ne sont pas privées. Le fait de ne pas appartenir à ces trois plages ne signifie pas automatiquement que l’adresse est utilisable sur l’internet public ; vérifiez aussi les autres plages d’adresses à usage spécial.
La RFC 6598 définit l’espace d’adresses partagé 100.64.0.0/10, de 100.64.0.0 à 100.127.255.255, destiné à des scénarios spécifiques au sein des réseaux de fournisseurs de services, et non routable mondialement. Un WAN de routeur dans cette plage est un indice fort d’un réseau partagé en amont, mais ne prouve pas à lui seul quel type de CGNAT l’opérateur a mis en œuvre. Inversement, l’absence de cette plage n’exclut pas une NAT en amont, car la planification d’adresses interne de l’opérateur peut être différente.
Pour juger, comparez les plages complètes, et ne marquez pas toutes les adresses commençant par 100 comme CGNAT. Les adresses partagées se situent généralement du côté avant la traduction, et une requête publique voit la sortie routable mondialement après traduction ; ces deux résultats ne sont pas contradictoires. Vérifiez aussi si la requête passe par un proxy, si elle utilise le même WAN et la même famille d’adresses. Ce n’est qu’en fixant ces conditions que les écarts d’adresses deviennent un indice explicable ; en fin de compte, la question de savoir si votre forfait fournit une IPv4 publique attribuée directement reste soumise à la confirmation de l’opérateur et à la configuration réseau réelle.
Comment comparer l’adresse WAN et la sortie web
Dans la mesure du possible, enregistrez l'IPv4 de sortie de la page web au même moment, sur le même terminal et sous le même réseau, puis vérifiez l'IPv4 WAN du routeur qui achemine réellement la requête. Une reconnexion, un changement de Wi-Fi, l'utilisation d'un double WAN ou d'un split proxy peuvent fausser la comparaison. La vérification de l'IPv6 est différente : le terminal possède généralement sa propre adresse IPv6 globale, et on ne peut pas exiger qu'elle soit identique à l'IPv6 WAN du routeur. Il faut vérifier l'adresse source effectivement utilisée par le terminal, le préfixe délégué par l'opérateur et la route attendue ; les adresses IPv6 temporaires peuvent aussi changer avec le temps.
Sur un réseau domestique, consultez d'abord la page d'état et la topologie existante, sans réinitialiser l'appareil aux paramètres d'usine pour consulter les adresses. Les utilisateurs d'un réseau d'entreprise ou de campus peuvent transmettre les résultats des requêtes du terminal à l'administrateur réseau, qui vérifiera la sortie et la traduction en amont. Si l'appareil possède plusieurs interfaces, indiquez le nom et la fonction de chaque interface, en distinguant l'adresse de gestion du modem optique, l'adresse LAN du routeur, l'adresse WAN et l'adresse de l'interface virtuelle VPN, sinon plusieurs valeurs correctes côte à côte peuvent mener à une conclusion erronée.
Pour une même requête IPv4, sans proxy et avec le bon WAN sélectionné, le WAN et la sortie de la page web sont identiques, et on ne peut généralement pas soutenir l'hypothèse que « ce chemin passe par un CGNAT supplémentaire qui modifie l'IPv4 source ». Cependant, cette égalité ne garantit pas une attribution statique, une exclusivité ou des connexions entrantes autorisées : les politiques de l'opérateur et les pare-feu de l'hôte et du routeur peuvent encore restreindre l'accès. La capacité d'entrée doit être testée depuis un réseau externe indépendant sur le service que vous gérez, en notant séparément le protocole, le port et l'étape de l'échec.
Le WAN diffère de la sortie, quelles autres raisons ?
Si l'adresse WAN diffère de la sortie de la page web, pensez d'abord à la topologie réelle. Lorsque le modem optique est en mode routeur, le routeur de niveau inférieur peut en recevoir une adresse privée, créant un double NAT ; un VPN système peut aussi faire passer la page web par une passerelle distante. Vérifiez d'abord le mode du modem optique, la répartition VPN et l'interface qui achemine réellement la requête, puis déterminez à quelle couche la différence est due. Les modifications du pont, de la connexion par numérotation ou du tunnel doivent être confirmées par l'opérateur ou l'administrateur selon les besoins du réseau, et non opérées uniquement pour rendre les deux nombres identiques.
Le proxy du navigateur modifie également la sortie de la page web, tandis que d'autres applications du même appareil peuvent se connecter directement. La fenêtre de navigation privée ne contourne généralement pas le proxy système et ne garantit pas la désactivation de toutes les extensions ; la configuration du navigateur utilisée pour la comparaison doit confirmer l'état du proxy et des extensions. Les passerelles de sécurité d'entreprise, les services de navigation à distance et la répartition multi-sorties peuvent aussi causer des différences. Pour les appareils gérés, demandez directement à l'administrateur de vérifier les politiques, ce qui est souvent plus efficace que de désactiver vous-même le tunnel d'entreprise.
L'exclusion par couches doit être effectuée dans l'ordre. Vérifiez d'abord qu'aucun VPN ou proxy n'est activé sur l'appareil, puis vérifiez si l'adresse WAN du routeur est dans la plage RFC 1918 ou RFC 6598. Si le WAN est une adresse privée, le modem optique est peut-être encore en mode routeur ; si le WAN est 100.64.x.x, l'opérateur a peut-être utilisé du CGNAT ; si le WAN est une adresse publique mais que la sortie de la page web diffère, il y a peut-être un proxy ou une passerelle d'entreprise. Ne tirez pas de conclusion à partir d'une seule capture d'écran, car les adresses peuvent changer dynamiquement et le logiciel proxy peut se lancer au démarrage du système. Conservez les observations à plusieurs moments et comparez-les aux changements de topologie pour améliorer la précision du diagnostic.
IPv4 et IPv6 doivent être vérifiés séparément
IPv4 et IPv6 sont généralement déployés en parallèle, mais avec des allocations d'adresses, des routages et des politiques de pare-feu distincts. Le terminal peut utiliser IPv4 via NAT tout en obtenant directement une adresse IPv6 globale. Un accès IPv6 réussi indique seulement que ce chemin IPv6 et ce service sont disponibles ; un échec d'accès IPv4 peut aussi impliquer DNS, routage, proxy ou écoute côté serveur. Le CGNAT est particulièrement pertinent pour les connexions entrantes IPv4 sans mappage établi, et on ne peut pas l'invoquer pour expliquer toutes les pannes sortantes IPv4.
Vérification de l’environnement du navigateur peut aider à observer la sortie des requêtes et le comportement réseau du navigateur, mais elle ne prouve pas qu'un hôte externe peut se connecter activement à votre service IPv6. La vérification de l'entrée nécessite un service réellement à l'écoute, des règles de pare-feu appropriées et un test depuis un réseau externe indépendant. Les règles d'autorisation des deux protocoles peuvent différer, donc « la page web peut se connecter » et « les autres peuvent se connecter » doivent être validés séparément, et on ne peut pas prétendre que l'entrée est ouverte simplement parce que la page affiche une adresse IPv6 globale.
Lors du diagnostic, notez séparément la cible, l'adresse source et l'étape de l'échec pour IPv4 et IPv6. Si vous soupçonnez que le chemin ne correspond pas aux attentes du proxy ou du VPN, lisez Fuites WebRTC, DNS et IPv6 : tester et lire les résultats. Les candidats WebRTC reflètent des indices d'interfaces ou de sortie que le navigateur peut collecter ; les tests DNS observent généralement la source du résolveur récursif lorsque la requête de test atteint le serveur faisant autorité, et non l'IP cible obtenue par résolution du nom de domaine comme étant votre sortie. Désactiver IPv6 peut masquer le phénomène ; précisez d'abord quel chemin précis ne correspond pas aux attentes.
Comment analyser un échec de mappage de port ?
En cas d'échec du mappage de port, vérifiez d'abord que le service local fonctionne et écoute sur l'interface et le port attendus. S'il n'est lié qu'à 127.0.0.1 ou ::1, les appareils externes ne peuvent pas se connecter directement ; selon les besoins du service, liez-le à l'interface interne désignée et restreignez l'accès avec le pare-feu de l'hôte. Changer le service pour écouter sur toutes les interfaces n'est pas la seule solution et peut élargir la surface d'exposition. Validez d'abord la réponse de l'application depuis un autre appareil du réseau local, puis examinez couche par couche le routeur et le réseau en amont.
Si l'écoute locale et le pare-feu de l'hôte sont normaux, l'étape suivante consiste à vérifier les règles de redirection de port sur le routeur. Les erreurs courantes incluent : redirection vers une mauvaise IP interne, ports internes et externes non concordants, ou protocole sélectionné en TCP alors que le service réel utilise UDP. Certains routeurs exigent également d'ouvrir séparément ce port sur le pare-feu et de redémarrer pour appliquer la règle. À ce stade, vous pouvez tester la disponibilité du service depuis une autre machine du réseau local pour isoler les problèmes de configuration du routeur.
Lorsque la configuration du routeur est correcte mais que l'entrée échoue toujours, comparez l'IPv4 WAN et la sortie de la page web, et vérifiez le NAT en amont et les politiques de l'opérateur. Test de connexion TCP peut fournir une observation externe dans la plage de cibles et de ports publics autorisée par l'outil ; si l'entrée est refusée par la politique de l'outil, ce n'est pas une preuve d'échec de connexion à la cible. Le test TCP ne remplace pas la validation d'un service UDP. En cas d'échec d'un test externe, conservez la raison d'origine, sans tout attribuer au CGNAT.
Si le test externe montre que le port est inaccessible, envisagez aussi que l'opérateur bloque les ports entrants courants, comme 80, 25, 445, etc. Certains opérateurs bloquent par défaut toutes les connexions entrantes, sauf si l'utilisateur demande une IP publique ou l'ouverture de ports spécifiques. Dans ce cas, contactez l'opérateur pour confirmer la politique plutôt que de modifier sans cesse la configuration locale. L'ordre de diagnostic peut être résumé ainsi : écoute locale, pare-feu de l'hôte, redirection du routeur, NAT en amont, restrictions de l'opérateur ; ne changez qu'une variable à la fois pour déterminer précisément l'origine du problème.
Comment la sortie partagée affecte-t-elle les CAPTCHA et la réputation IP ?
Lorsque vous utilisez une IP de sortie partagée, le comportement d'autres utilisateurs peut affecter la réputation de cette adresse, déclenchant ainsi davantage de captchas ou de restrictions d'accès. Il faut distinguer l'observation au niveau de l'adresse et l'utilisateur spécifique. L'observation au niveau de l'adresse indique seulement qu'une IP a déjà été associée à des requêtes automatisées ou à un trafic anormal, sans pouvoir déterminer qui les a émises ni prouver que l'utilisateur actuel est malveillant. Sous CGNAT d'un opérateur, des centaines d'utilisateurs, voire plus, peuvent partager la même adresse IPv4 ; l'anomalie de l'un quelconque peut être enregistrée sur cette adresse par les sites web.
L'aide sur le trafic anormal de Google indique que les requêtes automatiques d'autres utilisateurs sur un réseau partagé ou un VPN peuvent déclencher un message de trafic anormal. C'est une cause possible, mais cela ne permet pas de déterminer, à partir du message, quel utilisateur ou quel programme a émis la requête, ni d'affirmer que cette sortie figure sur une liste noire publique. Conservez l'erreur spécifique et l'heure à laquelle elle s'est produite, puis vérifiez séparément le réseau, le navigateur et les règles du site cible en suivant IP sur liste de blocage et CAPTCHA répétés : que faire ?.
Une IP partagée n'implique pas en soi une insécurité, ni une intention malveillante de l'utilisateur. De nombreuses organisations utilisent le CGNAT pour économiser des adresses IPv4, ce qui est une pratique normale d'ingénierie réseau. L'évaluation de la sécurité doit reposer sur le trafic et les sessions spécifiques, et non sur une adresse partagée. Si vous contactez un site web ou un opérateur en raison de problèmes de captcha, vous pouvez expliquer que vous êtes dans un environnement de sortie partagée et fournir des preuves observables de vos horaires d'accès et de votre comportement, plutôt que d'exiger le blanchiment de l'IP entière, car cela pourrait masquer de véritables anomalies.
Pour les exploitants de sites web, se fier à la réputation d'une seule IP pour prendre des décisions risque de causer des dommages collatéraux. Une approche plus raisonnable consiste à combiner plusieurs signaux, tels que l'agent utilisateur, l'empreinte TLS et les modèles de comportement, et à proposer des méthodes de vérification supplémentaires pour les utilisateurs de sorties partagées, par exemple un code par e-mail ou SMS. Lorsqu'un utilisateur ordinaire constate une augmentation des captchas, il peut essayer de changer d'environnement réseau ou signaler au site web la plage d'IP de sortie et les horaires d'accès, mais il ne doit pas utiliser d'outils de contournement pour passer outre les contrôles d'accès.
Que rédiger dans le ticket à l'opérateur
Lorsque vous soumettez un ticket à l'opérateur, plus les informations sont complètes, plus le traitement est rapide. Fournissez le fuseau horaire et l'heure exacts, par exemple la date et la plage horaire en UTC+8, afin que l'opérateur puisse faire correspondre les journaux. Indiquez également l'adresse IP affichée sur l'interface WAN du routeur ; si l'adresse WAN du routeur n'est pas publique, renseignez-la telle quelle. L'IP de sortie observée de l'extérieur peut être obtenue via des sites de consultation ; présenter les deux côte à côte permet de déterminer rapidement s'il existe un NAT intermédiaire.
Si vous utilisez à la fois IPv4 et IPv6, vous devez les décrire séparément. De nombreux réseaux mobiles ou connexions haut débit domestiques ont activé l'IPv6, mais l'IPv4 peut encore passer par un CGNAT. En décrivant le problème, ne dites pas seulement « impossible d'accéder », mais précisez les protocoles entrants nécessaires, par exemple le port TCP 443 pour HTTPS, ou le port UDP 51820 pour WireGuard. Décrivez également la topologie existante, par exemple si l'ONT est en mode pont ou routeur, la marque et le modèle du routeur, et s'il passe par un routeur secondaire.
Dans le ticket, ne demandez pas à l'opérateur de « blanchir » l'IP d'une liste noire, à moins d'avoir des preuves concrètes que l'adresse a été marquée par erreur. Une question plus appropriée est : le forfait actuel fournit-il une adresse IPv4 publique ? Les connexions entrantes sont-elles autorisées ? Si l'IPv4 n'est pas disponible, un accès entrant IPv6 est-il proposé ? Ces questions concernent directement les capacités du réseau, et non la réputation. Il n'est pas nécessaire de fournir spontanément des journaux sensibles, tels que des enregistrements de trafic complets ou des identifiants d'accès, mais si l'opérateur a besoin de poursuivre le diagnostic, vous pouvez fournir des journaux anonymisés selon le principe du minimum nécessaire.
Si l'opérateur demande des preuves, vous pouvez établir une chronologie : quand la redirection de port a été configurée, depuis quel réseau externe vous avez testé, quel outil de test vous avez utilisé et quels résultats vous avez obtenus. Ces preuves doivent rester inchangées, sans modifier les captures d'écran ni les sorties. Lors du suivi du ticket, consignez l'heure de chaque communication, le numéro du conseiller et la conclusion, afin de constituer un enregistrement vérifiable. Indiquer clairement la résolution attendue et la prochaine échéance améliore aussi l'efficacité du traitement.
Comment choisir entre utilisateur domestique et développeur
Si un utilisateur domestique a besoin d'accéder à distance à des appareils qu'il gère, il peut d'abord vérifier si son forfait prend en charge l'accès entrant IPv4 public ou IPv6, puis choisir une solution adaptée. En l'absence de capacité d'accès entrant direct, il peut évaluer un tunnel inverse ou un service de relais authentifié, en vérifiant les contrôles d'accès, les modalités de maintenance, les coûts et la disponibilité, et en respectant les règles de gestion du réseau concerné. La nécessité de cette solution dépend de l'objectif métier ; il ne faut pas considérer « avoir une IPv4 publique » comme un prérequis pour tout accès à distance.
En ce qui concerne l'accessibilité des adresses IP publiques et des ports, les utilisateurs domestiques ont souvent une idée fausse : ils pensent que si l'adresse WAN du routeur est publique, tous les ports seront accessibles depuis Internet. En réalité, de nombreuses connexions haut débit domestiques, même lorsqu'elles attribuent une IPv4 publique, bloquent les ports de services courants sur les équipements de bordure de l'opérateur. De plus, une IP publique dynamique peut changer, et l'accès à distance nécessite en plus un DNS dynamique. Si l'accès n'est que temporaire, il est plus sûr d'utiliser la gestion à distance fournie par le fabricant ou un service de relais autorisé.
Lorsqu'un développeur effectue des tests d'intégration de services Internet, il ne doit pas considérer qu'un accès sortant réussi depuis sa machine équivaut à une validation d'accès entrant depuis Internet. Un accès sortant réussi via NAT ou pare-feu indique seulement que le chemin sortant est dégagé, et non que des machines externes peuvent se connecter activement à la vôtre. Par exemple, si un service web tourne sur localhost et qu'un appel API externe via curl réussit, cela ne prouve pas que des utilisateurs externes peuvent accéder à ce service web. Il faut effectuer un test actif depuis une autre machine sur un réseau différent, ou utiliser un outil externe de vérification TCP.
Le développeur doit aussi vérifier la publication des ports entre les conteneurs, les machines virtuelles et l'hôte. Un service fonctionnant correctement dans un conteneur ne signifie pas que l'hôte a ouvert ce port sur l'interface prévue ; un accès via l'adresse de bouclage de l'hôte ne signifie pas non plus que le réseau local ou Internet peut y accéder. La validation finale doit préciser le point d'observation et le résultat de l'application : pour un service TCP, il faut établir la connexion et réaliser l'interaction attendue ; pour un service UDP, il faut envoyer une requête conforme au protocole et vérifier la réponse. On ne peut pas conclure à un établissement TCP à partir d'un UDP sans poignée de main de connexion.
Trois questions fréquentes
L'IP publique est-elle fixe ? Cela dépend de l'opérateur et du forfait. Les connexions haut débit domestiques utilisent généralement des adresses dynamiques ; même si une IPv4 publique est attribuée, elle peut changer à l'expiration du bail, lors d'une reconnexion ou d'un redémarrage de l'équipement. Les lignes dédiées d'entreprise ou les forfaits à IP fixe peuvent fournir des adresses statiques, mais moyennant un coût supplémentaire. Les adresses IPv6 sont généralement déléguées par préfixe ; si le préfixe de l'opérateur ne change pas, l'adresse de l'appareil peut rester stable un certain temps, sans garantie de permanence. Ne partez pas du principe que l'adresse est fixe ; les services à distance nécessitent tout de même un DNS dynamique ou des mises à jour régulières de la configuration.
Le redémarrage du routeur change-t-il forcément l'adresse ? Pas nécessairement. Le changement d'adresse dépend de la durée du bail DHCP, de la politique de pool d'adresses de l'opérateur et de la méthode d'authentification. Parfois l'adresse reste identique après un redémarrage, parfois elle change ; il n'y a pas de règle générale. En environnement CGNAT, un redémarrage peut modifier la correspondance interne de l'opérateur plutôt que l'adresse publique de sortie. Pour déterminer si la sortie actuelle a changé, vous pouvez enregistrer l'IP de sortie avant et après le redémarrage à l'aide de plusieurs services de consultation indépendants, en veillant à ce que le fuseau horaire et l'environnement réseau restent identiques.
Plusieurs utilisateurs partageant une IP publique ne signifie pas automatiquement qu'ils peuvent s'accéder mutuellement, ni ne constitue une preuve d'isolation de sécurité. L'isolation réelle dépend de la configuration du réseau d'accès, des contrôles d'accès et des pare-feu des appareils ; le NAT ne doit pas être considéré comme une frontière de sécurité complète. Une sortie partagée peut créer une association de réputation, amenant les utilisateurs normaux à rencontrer ensemble des CAPTCHA ou des restrictions, mais l'impact précis dépend des politiques des sites cibles. Évaluez séparément la connectivité, la réputation de l'adresse et la sécurité des appareils, et évitez de résumer tous les problèmes par une simple étiquette « partagé ».
Former un enregistrement vérifiable
Lors du dépannage des problèmes de joignabilité d'une IP publique et d'un port, l'enregistrement doit permettre une vérification ultérieure. Pour créer une chronologie, utilisez une approche schématique : par exemple, à 10 h 00 un jour donné, vous configurez la redirection de port sur le routeur ; à 10 h 05, depuis un réseau externe, vous testez le port 8443 avec un outil de détection TCP et le test échoue ; à 10 h 10, vous modifiez le pare-feu de l'hôte ; à 10 h 15, vous retestez et l'échec persiste. Un tel enregistrement montre clairement chaque action et son résultat. N'omettez pas les opérations ayant échoué, car les échecs permettent aussi d'exclure des variables.
Ne modifiez qu'une seule variable à la fois et notez les résultats avant et après ; ajuster simultanément les règles du pare-feu et du routeur rend la cause difficile à déterminer. Vous pouvez conserver les pages d'état, les textes d'erreur, les heures de test et les résultats de sortie ; lorsque vous fournissez des documents à des tiers, supprimez les informations non pertinentes comme les identifiants et les jetons. Pour comprendre les types d'adresses, leurs sources et les limites d'observation, consultez la Sources de données et méthodologie de ce site. L'objectif de l'enregistrement est de permettre au prochain intervenant de reproduire les conditions, et non d'accumuler des captures d'écran inexplicables.
La détection d'IP partagée ou de proxy peut produire des faux positifs ; par exemple, un réseau domestique normal peut être signalé comme VPN ou proxy en raison d'une sortie partagée. Dans ce cas, collectez l'IP de sortie, l'heure de la requête et la plateforme de détection, et notez les divergences de jugement entre plusieurs plateformes. Ne vous fiez pas à une seule liste noire ou à un seul service de détection, car certaines plateformes sont peu adaptées aux plages CGNAT. Pour des cas de faux positifs et des pistes de dépannage, consultez IP détectée comme VPN ou proxy : vérifier un faux positif, qui explique comment distinguer les marquages au niveau de l'adresse d'un comportement de proxy réel.
Lorsque l'enregistrement de dépannage est suffisamment complet mais que le problème n'est toujours pas résolu, définissez des conditions d'arrêt claires. Par exemple : vous avez modifié l'écoute locale et le pare-feu, confirmé que les règles du routeur sont correctes, testé depuis deux réseaux externes différents avec échec, et le fournisseur d'accès a répondu qu'il n'y a pas de capacité entrante. Dans ce cas, l'étape suivante devrait être de demander une adresse publique auprès du fournisseur ou d'adopter une solution de relais autorisée, plutôt que de continuer à deviner ou à modifier. Une fois terminé, archivez tous les enregistrements, indiquez la conclusion « impossible d'établir une connexion entrante, la cause étant attribuée à la politique du fournisseur », et joignez la chaîne de preuves.
