Aller au contenu principal
MyIPKit— Votre réseau, expliqué.

Vérifications réseau locales

Les questions auxquelles un navigateur ne peut pas répondre, et la commande exacte pour y répondre vous-même.

Référence uniquement — cette page n'exécute et ne transmet rien
Information:

Pourquoi cette page existe

Un site web ne peut pas voir l'intérieur de votre réseau, et c'est délibéré. Le serveur reçoit une seule chose : l'adresse publique de votre passerelle. Votre adresse privée, votre sous-réseau, votre routeur et les appareils qui y sont connectés ne font jamais partie d'une requête HTTP : aucun code ici ne peut donc les révéler.

Ce que MyIPKit peut faire, c'est vous indiquer exactement quelle commande répond à chaque question sur votre propre machine, là où aucun bac à sable de navigateur ne s'applique. C'est l'objet de cette page.

Votre système d'exploitation

Détecté automatiquement depuis votre navigateur. Modifiez-le si besoin.

Avant d'exécuter quoi que ce soit

  • Toutes les commandes de cette page sont en lecture seule. Aucune ne modifie votre configuration.
  • Les commandes signalées comme nécessitant des privilèges élevés demanderont votre mot de passe. Lisez-les avant de les exécuter.
  • N'analysez ou ne sondez que des réseaux que vous possédez ou que vous êtes autorisé à tester. C'est une limite légale dans la plupart des pays, pas une question de politesse.
  • Ne collez jamais une commande que vous ne comprenez pas, d'où qu'elle vienne — y compris d'ici. Chaque entrée ci-dessous précise ce qu'elle fait.

Vos propres adresses

MyIPKit affiche l'adresse publique que voit Internet. Celles-ci montrent l'adresse privée que votre appareil détient à l'intérieur de votre réseau — la part qu'un site web ne reçoit jamais.

  • Votre adresse IPv4 privée sur l'interface active

    ipconfig getifaddr en0

    Attendez-vous à du 192.168.x.x, 10.x.x.x ou 172.16–31.x.x. Sous macOS, en0 est généralement le Wi-Fi et en1 le port filaire ; essayez les deux.

  • Toutes les interfaces et adresses, y compris IPv6

    ifconfig

    Cherchez les lignes inet (IPv4) et inet6 (IPv6). Une adresse IPv6 commençant par fe80: est locale au lien et ne quitte jamais votre réseau ; une adresse globale commence généralement par 2 ou 3.

  • Si vous disposez réellement de connectivité IPv6

    curl -6 -s https://api64.ipify.org || echo "no IPv6"

    Si une adresse s'affiche, votre connexion dispose d'IPv6 de bout en bout. En cas d'échec, vous êtes en IPv4 uniquement — ce qui reste tout à fait normal.

  • Votre adresse publique, en ligne de commande

    curl -s https://api.ipify.org

    Elle devrait correspondre à ce qu'affiche MyIPKit. Un écart signifie généralement un VPN, un proxy, ou un navigateur empruntant une route différente de curl.

La topologie de votre réseau

Le routeur, le sous-réseau et les appareils qui s'y trouvent. C'est l'information que les gens attendent le plus souvent d'un site web, et celle qu'un navigateur refuse le plus fermement d'exposer.

  • Votre routeur (passerelle par défaut)

    route -n get default

    L'adresse de la passerelle est celle de votre routeur. L'ouvrir dans un navigateur mène généralement à sa page d'administration.

  • La table de routage complète

    netstat -rn

    Indique par quelle interface sortira le trafic vers une destination donnée. Un VPN ajoute généralement une route qui capte la route par défaut.

  • Votre masque de sous-réseau, pour connaître la taille de votre réseau

    ipconfig getpacket en0 | grep subnet_mask

    Reportez l'adresse et le masque dans le calculateur de sous-réseau de ce site pour obtenir la plage utilisable exacte.

  • Les appareils avec lesquels votre machine a récemment communiqué en local

    arp -a

    La table ARP liste les voisins vus récemment, pas tous les appareils présents. Un appareil inactif depuis le démarrage n'y figurera pas.

  • Quels hôtes de votre réseau sont actuellement actifs

    Non installé par défaut
    nmap -sn 192.168.1.0/24

    nmap n'est pas installé par défaut. macOS : brew install nmap. Debian/Ubuntu : sudo apt install nmap. Windows : nmap.org.

    C'est un balayage ping : les hôtes qui ignorent ICMP n'apparaîtront pas, même s'ils sont en ligne.

    Remplacez la plage par la vôtre — lisez-la dans la passerelle et le masque ci-dessus. N'analysez que des réseaux que vous possédez ou administrez. Analyser le réseau d'autrui constitue, selon votre pays, une infraction pénale, et cela sera journalisé.

  • Découvrir les services qui se signalent sur le réseau

    Non installé par défaut
    dns-sd -B _services._dns-sd._udp local.

    Linux : sudo apt install avahi-utils.

    Les imprimantes, enceintes, NAS et équipements similaires s'annoncent via mDNS. C'est une découverte par consentement, pas une analyse.

Le chemin vers la sortie

Le rapport réseau de ce site mesure la latence HTTP jusqu'au point de présence MyIPKit, et rien d'autre. Ces commandes mesurent la route réelle, saut par saut.

  • Un vrai ping ICMP — ce que le navigateur ne peut pas faire

    ping -c 10 1.1.1.1

    Comparez avec le rapport réseau de ce site. Les résultats diffèrent souvent : de nombreux réseaux déprioritisent ICMP par rapport au trafic web ordinaire.

  • Chaque saut entre vous et une destination

    Non installé par défaut
    traceroute 1.1.1.1

    Debian/Ubuntu : sudo apt install traceroute.

    Le premier saut est votre routeur. Les astérisques signalent un saut qui n'a pas répondu, ce qui est courant et n'est pas en soi un défaut. Repérez l'endroit où la latence bondit.

  • Perte et latence continues par saut

    Non installé par défaut
    mtr 1.1.1.1

    macOS : brew install mtr. Debian/Ubuntu : sudo apt install mtr.

    Le meilleur outil pour les problèmes intermittents. Une perte sur un saut qui disparaît aux sauts suivants correspond à ce routeur qui déprioritise ICMP, pas à une vraie perte de paquets.

  • Trouver le plus gros paquet qui passe sans fragmentation

    ping -D -s 1472 -c 3 1.1.1.1

    1472 + 28 octets d'en-tête = 1500, le MTU Ethernet habituel. Si cette taille échoue mais que des tailles plus petites passent, un problème de MTU est probable — cause classique du « certains sites chargent, d'autres restent bloqués » sur les VPN et les liaisons PPPoE.

Le DNS depuis votre propre machine

L'outil de recherche DNS de ce site interroge un résolveur public. Ces commandes interrogent le résolveur que votre réseau vous a réellement fourni, celui qui décide où va vraiment votre trafic.

  • Les résolveurs configurés sur votre machine

    scutil --dns | grep nameserver

    S'il s'agit de votre box ou de votre fournisseur d'accès, vos requêtes leur sont visibles. S'il s'agit de 1.1.1.1 ou 8.8.8.8, vous avez remplacé la configuration par défaut.

  • Résoudre un nom avec votre propre résolveur

    dig example.com

    Comparez avec l'outil de recherche DNS d'ici. Une différence signifie que votre résolveur sert une réponse mise en cache, filtrée ou remplacée.

  • Comparer votre résolveur à un résolveur public

    dig example.com @1.1.1.1

    La façon la plus claire d'identifier un filtrage au niveau DNS, un portail captif ou un cache périmé.

  • Tracer un nom depuis les serveurs racines

    dig +trace example.com

    Affiche la chaîne de délégation complète. L'outil adapté lorsqu'un domaine se résout pour certains et pas pour d'autres.

  • Vider le cache DNS local

    Nécessite les droits administrateur
    sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

    Exécutez ceci après avoir modifié un enregistrement DNS, avant de conclure que le changement n'a pas fonctionné.

Ports et connexions sur cette machine

Ce que votre propre machine écoute et ce à quoi elle est connectée. Entièrement local, et la bonne alternative à un scan de vous-même depuis Internet.

  • Tout ce qui écoute des connexions entrantes

    Nécessite les droits administrateur
    sudo lsof -nP -iTCP -sTCP:LISTEN

    Tout ce qui est lié à 0.0.0.0 ou :: accepte des connexions depuis le réseau. Lié à 127.0.0.1, ce n'est joignable que depuis cette machine.

  • Connexions actuellement établies

    netstat -an | grep ESTABLISHED

    Utile pour répondre à « avec quoi cette machine communique-t-elle réellement en ce moment ? ».

  • Tester si un port précis d'un hôte précis est joignable

    nc -vz example.com 443

    Vérifiez des ports individuels sur des hôtes que vous administrez. Balayer les ports d'hôtes qui ne vous appartiennent pas, c'est ce que fait un scanner de ports, et ce n'est pas une fonction que MyIPKit proposera jamais.

  • Inspecter un certificat TLS tel que votre machine le voit

    openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

    Affiche le sujet, l'émetteur et les dates de validité. Si l'émetteur est inattendu, quelque chose intercepte la connexion — un proxy d'entreprise, ou pire.

Qualité du Wi-Fi

Quand le problème se situe entre votre appareil et le point d'accès, aucune mesure côté Internet ne le trouvera.

  • Force du signal, bruit et débit négocié

    system_profiler SPAirPortDataType | grep -A 10 "Current Network"

    Sous macOS, un RSSI supérieur à −60 dBm est fort et inférieur à −75 dBm est faible. L'écart entre signal et bruit compte davantage que le signal seul.

  • Les canaux utilisés par les réseaux voisins

    system_profiler SPAirPortDataType | grep -i channel

    En 2,4 GHz, seuls les canaux 1, 6 et 11 ne se chevauchent pas. Des voisins entassés sur votre canal est une cause fréquente de latence que l'on prend pour une panne du fournisseur.

Référence uniquement — cette page n'exécute et ne transmet rien

Ce qu'un navigateur donne et ne donne pas à un site

Cela mérite d'être dit précisément, car beaucoup de sites laissent entendre le contraire.

Ce que le serveur reçoit réellement

  • L'adresse IP publique de votre passerelle — une adresse, pour la connexion que vous avez établie.
  • Les en-têtes HTTP que votre navigateur a choisi d'envoyer, comme le User-Agent et la langue.
  • Une géolocalisation approximative, déduite par le réseau de périphérie à partir de cette adresse publique, et toujours approximative.

Ce qu’il ne reçoit jamais

  • Votre adresse privée, votre masque de sous-réseau ou l’adresse de votre routeur.
  • La moindre liste des appareils de votre réseau.
  • Votre adresse MAC, votre nom d’hôte ou votre table ARP.
  • Les ports ouverts sur votre machine ou sur tout autre équipement de votre réseau.

Les deux anciennes fuites, et pourquoi elles sont refermées

WebRTC exposait autrefois les adresses privées dans ses candidats ICE. Depuis 2020, Chrome, Edge, Firefox, Opera et Brave les remplacent par défaut par un nom d'hôte aléatoire se terminant par .local, et Safari fait à peu près de même. L'adresse n'est tout simplement plus là à lire.

L'analyse par temporisation — envoyer des requêtes vers des adresses privées et déduire ce qui existe de la rapidité de l'échec — était l'autre. Chrome 142 a introduit Local Network Access en octobre 2025, qui place toute requête d'un site public vers une adresse privée ou de bouclage derrière une demande d'autorisation. Parmi les raisons invoquées par Google figure la réduction de la capacité des sites à dresser l'empreinte du réseau local d'un visiteur.

MyIPKit n'implémenterait ni l'une ni l'autre de ces techniques, même là où elles fonctionneraient encore. Un site public qui sonde les réseaux de ses visiteurs est un site qui analyse les réseaux de gens qui n'y ont jamais consenti, et il en récolte la réputation correspondante.

Pourquoi ce site ne peut-il pas simplement me montrer mon réseau local ?

Ce n'est pas un problème d'autorisation — un navigateur ne transmet structurellement pas cette information à un site. Le serveur ne reçoit que l'adresse publique de votre passerelle NAT ; votre adresse privée, votre sous-réseau, votre routeur et les appareils connectés ne font jamais partie de la requête. Les navigateurs remplacent aussi les adresses locales dans WebRTC par des noms .local aléatoires, et depuis Chrome 142 un site public ne peut pas joindre une IP locale sans une demande d'autorisation explicite, précisément pour empêcher les sites de dresser l'empreinte de votre réseau.

Est-il sûr d’exécuter ces commandes ?

Toutes les commandes listées ici sont en lecture seule : aucune ne modifie votre configuration. Quelques-unes nécessitent des privilèges administrateur pour voir tous les processus, et elles sont signalées. La seule vraie précaution concerne l'analyse réseau, qui ne doit viser qu'un réseau que vous possédez ou administrez.

La sortie de la commande ne correspond pas à ce qu'affiche MyIPKit. Qui a raison ?

Les deux, en général — ils mesurent des choses différentes. MyIPKit indique l'adresse que voit Internet ; votre machine indique l'adresse qu'elle détient localement. Derrière un NAT, elles diffèrent toujours. Si votre adresse publique diffère entre curl et ce site, la cause habituelle est un VPN ou un proxy appliqué à l'un et pas à l'autre.