Trouver son adresse IP publique sous Linux sans se tromper

Quand un service ne répond plus depuis l’extérieur, la première question n’est pas “Linux est-il mal configuré ?”. C’est souvent plus simple : quelle adresse votre réseau présente-t-il vraiment sur Internet ? Sous Linux, le terminal permet de trouver l’adresse IP publique en quelques secondes, mais il faut choisir la bonne commande et comprendre ce qu’elle mesure.

Le piège classique consiste à confondre l’adresse de la carte réseau avec celle vue depuis Internet. Sur un poste derrière une box, ip addr affiche surtout l’adresse locale. Pour connaître l’adresse publique, il faut interroger un service externe ou un résolveur DNS capable de voir la requête sortir de votre réseau.

Commencer par distinguer IP locale et IP publique

Le terminal donne vite une réponse. Encore faut-il poser la bonne question avant de comparer deux adresses qui ne jouent pas le même rôle.

Sur Linux, ip addr ou hostname -I affichent les adresses configurées sur les interfaces de la machine. C’est utile pour diagnostiquer un réseau local, trouver l’IP d’un serveur dans un LAN ou vérifier une interface Ethernet. Mais si la machine sort vers Internet via une box, un pare-feu ou un routeur, cette adresse n’est pas forcément l’adresse publique.

Dans un réseau domestique ou PME, la machine porte souvent une adresse privée en 192.168.x.x, 10.x.x.x ou 172.16.x.x. Le routeur effectue ensuite la traduction d’adresse, le fameux NAT. Depuis Internet, les services externes voient l’adresse du routeur, pas celle de votre poste Linux. C’est exactement cette adresse qu’il faut connaître pour un accès distant, un DNS dynamique ou un diagnostic de pare-feu.

ip addr
hostname -I

Ces deux commandes restent utiles, mais elles répondent à la question locale. Pour la question publique, vous devez demander à un service extérieur ce qu’il voit. Ce détour par l’extérieur n’est pas une astuce : c’est la seule façon fiable de voir votre sortie Internet réelle.

La méthode la plus simple avec curl

Pour une vérification rapide, curl reste le bon réflexe. Il est lisible, scriptable et disponible sur la plupart des distributions ou facile à installer.

La commande la plus directe consiste à interroger un service qui renvoie seulement l’adresse IP. L’option -s évite la barre de progression, tandis que -4 force l’IPv4. Vous obtenez une réponse compacte, exploitable à l’écran ou dans un script.

curl -4 -s https://api.ipify.org
curl -4 -s ifconfig.me
curl -4 -s icanhazip.com

Ne multipliez pas les services au hasard dans un script de production. Choisissez une ou deux sources connues, ajoutez un délai maximum, puis gérez l’échec proprement. Un service externe peut être indisponible, lent, filtré par un proxy ou bloqué par une politique réseau. Un script robuste doit répondre “je ne sais pas” plutôt que retourner une valeur vide comme si tout allait bien, surtout si une mise à jour DNS dépend ensuite de cette valeur.

Pour une lecture humaine, ajoutez simplement un saut de ligne si le service n’en renvoie pas. C’est un détail, mais il évite des sorties collées au prompt, surtout dans les procédures partagées avec une équipe moins habituée au terminal.

curl -4 -s https://api.ipify.org; echo

Utiliser dig quand vous préférez une réponse DNS

dig offre une alternative propre. Elle plaît souvent aux profils réseau, car elle évite d’appeler une page HTTP et interroge directement un résolveur.

La commande la plus connue utilise OpenDNS. Le domaine myip.opendns.com, interrogé via resolver1.opendns.com, renvoie l’adresse publique vue par ce résolveur. L’option +short garde uniquement la valeur utile.

dig +short myip.opendns.com @resolver1.opendns.com

Cette méthode est pratique sur un serveur minimal où les outils DNS sont déjà installés, ou dans un contexte où vous voulez comparer une sortie HTTP et une sortie DNS. Elle ne rend pas le diagnostic magique : si un VPN capte la requête DNS, si un proxy force une résolution particulière ou si le pare-feu filtre la sortie, le résultat peut encore raconter l’architecture réseau plus que la machine elle-même.

Le bon réflexe consiste donc à comparer au moins deux chemins réseau quand l’enjeu est sérieux. Si curl et dig donnent la même adresse, vous avez un signal solide. S’ils divergent, cherchez d’abord un VPN actif, un proxy, une sortie multi-WAN ou une politique DNS particulière.

Pour approfondir ce point, consultez Savoir si la fibre est disponible à, qui traite plus précisément de savoir si la fibre est disponible à son adresse.

Tester IPv4 et IPv6 séparément

Une seule adresse ne raconte pas toujours toute l’histoire, surtout sur une ligne moderne où IPv4 et IPv6 cohabitent.

Beaucoup de postes Linux disposent aujourd’hui d’une connectivité IPv6 en plus de l’IPv4. Selon le fournisseur, le routeur et la configuration locale, l’adresse IPv6 publique peut être directement portée par la machine, tandis que l’IPv4 reste partagée ou traduite par NAT. Pour diagnostiquer proprement, forcez donc la famille d’adresse.

curl -4 -s https://api.ipify.org; echo
curl -6 -s https://api64.ipify.org; echo

Si la commande IPv6 échoue, cela ne signifie pas que Linux est en panne. Votre accès peut simplement ne pas fournir d’IPv6, votre pare-feu peut bloquer la sortie, ou le service interrogé peut être inaccessible sur cette pile. À l’inverse, une IPv6 publique visible peut expliquer pourquoi une machine semble joignable alors que l’IPv4 paraît correctement filtrée.

Pour un serveur exposé, ce point mérite une vraie attention. Des règles de pare-feu complètes en IPv4 mais oubliées en IPv6 créent une surface d’exposition discrète. Vérifier les deux familles d’adresses doit donc faire partie du contrôle de base, surtout après migration de box, changement d’hébergeur ou activation d’un nouveau routeur.

Repérer les cas qui faussent le résultat

Quand l’adresse affichée surprend, ne concluez pas trop vite. Le terminal mesure le chemin réellement utilisé à cet instant.

Le cas le plus fréquent est le VPN. Si le tunnel est actif, votre requête sort probablement par l’infrastructure du VPN. Le résultat est alors correct pour cette session, mais il ne représente pas votre ligne Internet directe. Même logique avec un proxy d’entreprise, un bastion, un conteneur configuré avec une passerelle différente ou un serveur qui sort par plusieurs interfaces. Le résultat reste vrai, mais il décrit le chemin actif, pas nécessairement la ligne que vous aviez en tête.

Sur un VPS, l’adresse publique peut être configurée directement sur l’interface, mais ce n’est pas toujours le cas. Certains hébergeurs utilisent du NAT, des IP flottantes, des load balancers ou des règles de sortie spécifiques. Dans ce cas, comparez ce que dit le système, ce que dit l’interface cloud et ce que voit un service externe. Le diagnostic fiable vient de la concordance, pas d’une seule commande.

Dans un réseau PME, pensez aussi aux sorties multiples. Une connexion fibre principale, une 4G de secours, un SD-WAN ou une règle de routage par VLAN peuvent changer l’adresse publique selon la machine, le port ou le moment. Si deux postes Linux donnent deux adresses différentes, ce n’est pas forcément une anomalie ; cela peut refléter une architecture réseau volontaire.

Quand l’adresse publique ne suffit pas à joindre un service

Connaître l’IP publique ne garantit pas qu’un service est accessible. C’est une information de départ, pas une preuve d’ouverture.

Pour exposer un service hébergé derrière une box, il faut généralement une redirection de port, une règle de pare-feu locale et un service réellement à l’écoute sur la machine. Si l’adresse publique est correcte mais que la connexion échoue depuis l’extérieur, vérifiez le port écouté, la règle NAT, le pare-feu Linux et le pare-feu du routeur. Une seule couche fermée suffit à bloquer le trafic, même si l’adresse publique affichée est parfaitement correcte.

Depuis la machine Linux, ss -lntup permet de voir les ports en écoute. Depuis un autre réseau, un test externe confirme si le port répond vraiment. Évitez de tester uniquement depuis le même Wi-Fi, car certaines box ne gèrent pas correctement le retour vers leur propre IP publique. Ce comportement, souvent appelé hairpin NAT, peut faire croire à une panne alors que l’accès externe fonctionne pour un utilisateur réellement hors site.

ss -lntup
sudo ufw status
sudo nft list ruleset

Si votre fournisseur utilise du CGNAT, la situation change encore. Vous pouvez voir une adresse publique côté sortie, mais ne pas disposer d’une vraie adresse routable directement vers votre box. Dans ce cas, la redirection de port peut rester impossible sans option opérateur, IPv6 correctement filtrée, VPN entrant, tunnel ou service relais.

Stocker l’adresse dans un script Bash

Pour automatiser, commencez simple. Puis ajoutez les garde-fous avant de déclencher une action externe.

Capturer l’adresse dans une variable Bash permet de l’utiliser dans un script de notification, une mise à jour DNS ou un journal de diagnostic. Le minimum consiste à récupérer la valeur, vérifier qu’elle n’est pas vide, puis l’afficher ou la comparer.

ip_publique=$(curl -4 -s --max-time 5 https://api.ipify.org)

if [ -z "$ip_publique" ]; then
  echo "Impossible de récupérer l'adresse IP publique" >&2
  exit 1
fi

echo "IP publique IPv4: $ip_publique"

Le détail important est le timeout. Sans --max-time, un script peut rester bloqué plus longtemps que prévu si le service externe ne répond pas. En supervision, c’est rarement acceptable. Ajoutez aussi une validation de format si vous utilisez la valeur pour modifier un pare-feu, un DNS ou une règle d’accès.

Pour IPv6, gardez une variable séparée. Mélanger les formats complique les validations et les logs. Une adresse IPv6 contient des deux-points, peut être abrégée, et ne se manipule pas comme une IPv4. Un script lisible traite IPv4 et IPv6 comme deux informations voisines, mais distinctes.

Durcir un script qui tourne en tâche planifiée

Un script lancé à la main peut se permettre d’être bavard. Un script lancé par cron ou systemd doit être prévisible.

Pour approfondir ce point, consultez liste utilisateurs Linux, qui traite plus précisément de afficher la liste des utilisateurs linux sans se tromper.

Ajoutez d’abord une sortie d’erreur claire. Si la récupération échoue, le script doit écrire dans les logs et s’arrêter sans modifier l’état connu. Ensuite, validez la forme de l’adresse avant de l’utiliser. Pour une IPv4, un test strict évite d’envoyer une page HTML d’erreur ou une chaîne vide vers un fournisseur DNS dynamique. Pour une IPv6, utilisez un contrôle adapté ou déléguez la validation à un outil fiable.

La deuxième règle est la limitation de fréquence. Une panne du service externe, une coupure Internet ou une réponse temporaire ne doit pas déclencher vingt mises à jour DNS en cinq minutes. Conservez la dernière valeur valide, journalisez le changement avec une date, puis appliquez une politique de retry raisonnable. C’est moins séduisant qu’un one-liner, mais beaucoup plus sûr en production.

logger -t ip-public-check "IP publique modifiée: $actuelle"

Enfin, évitez de stocker des secrets directement dans le script. Si une mise à jour DNS nécessite un token, placez-le dans un fichier de configuration protégé, une variable d’environnement de service ou un gestionnaire de secrets adapté. L’adresse IP publique n’est pas un secret fort, mais le jeton d’automatisation, lui, mérite une vraie protection.

1. Ajouter un timeout à chaque appel externe.
2. Refuser une valeur vide ou manifestement invalide.
3. Journaliser l’ancienne IP, la nouvelle IP et l’heure du changement.
4. Limiter les retries pour éviter les mises à jour en boucle.
5. Protéger les tokens DNS hors du script principal.

Surveiller une IP dynamique sans bricoler

Une IP dynamique n’est pas un problème si le changement est détecté proprement et relié à une action maîtrisée.

Beaucoup de lignes résidentielles ou petites entreprises peuvent changer d’adresse publique après redémarrage de la box, maintenance opérateur ou renouvellement périodique. Si vous hébergez un service, un accès VPN entrant ou une redirection de port, ce changement peut couper l’accès sans que Linux signale une erreur locale.

La méthode consiste à stocker la dernière valeur connue, récupérer la valeur actuelle, puis comparer. En cas de différence, vous déclenchez une action : écrire dans un log, envoyer une notification, mettre à jour un enregistrement DNS dynamique ou alerter l’administrateur. Le script doit rester sobre, car une mise à jour DNS automatique mal contrôlée peut propager une mauvaise valeur.

fichier="/var/tmp/ip-publique.txt"
actuelle=$(curl -4 -s --max-time 5 https://api.ipify.org)
ancienne=$(cat "$fichier" 2>/dev/null)

if [ -n "$actuelle" ] && [ "$actuelle" != "$ancienne" ]; then
  echo "$actuelle" > "$fichier"
  echo "Nouvelle IP publique: $actuelle"
fi

Ce script est volontairement minimal. En production, ajoutez un contrôle de format, une journalisation avec date, une gestion des erreurs et une limitation de fréquence. Le but n’est pas de remplacer une solution de supervision, mais de poser un point de contrôle fiable avant d’automatiser davantage.

Confidentialité et dépendance aux services externes

Demander son IP publique à un service externe crée une trace. Ce n’est pas dramatique pour un usage ponctuel, mais ce n’est pas neutre non plus.

Chaque requête envoyée à un service tiers lui expose au minimum votre adresse source, l’heure et parfois quelques informations de client HTTP. Pour un poste personnel, le risque reste limité si vous utilisez un service connu avec parcimonie. Pour une infrastructure d’entreprise, choisissez explicitement vos dépendances externes, évitez d’appeler dix services différents et documentez ce que le script contacte.

Si la confidentialité est critique, vous pouvez interroger une ressource que vous contrôlez : un endpoint minimal sur un serveur externe, un journal côté reverse proxy, ou un DNS resolver maîtrisé. La logique reste la même : l’information doit venir d’un point situé hors du réseau à tester. La différence est que vous contrôlez le journal d’accès et la durée de conservation.

Choisir la bonne commande selon le besoin

Pour une vérification ponctuelle, ne compliquez pas. Pour un script récurrent, durcissez avant d’automatiser.

Mon ordre de priorité est simple : curl pour une lecture rapide, dig pour comparer le chemin DNS, puis un script avec timeout et validation dès qu’une action automatique dépend du résultat. C’est moins spectaculaire qu’un gros outil réseau, mais beaucoup plus robuste au quotidien.

Décider quoi faire après avoir trouvé l’IP

L’adresse seule ne suffit pas. Elle doit conduire à une décision claire et vérifiable.

Si vous faites un simple diagnostic, notez l’adresse, le contexte et la présence éventuelle d’un VPN. Si vous préparez un accès distant, vérifiez ensuite le pare-feu, la redirection de port et le service qui écoute. Si vous gérez une IP dynamique, mettez en place une surveillance avec journalisation avant de brancher une mise à jour DNS automatique.

Cette séparation évite les corrections au mauvais endroit. Une IP publique correcte ne répare pas un port fermé. Une IP changée n’explique pas une application arrêtée. Un VPN actif ne prouve pas que la box a changé d’adresse. Le bon diagnostic consiste à avancer couche par couche.

Ce qu’il faut retenir

Trouver son adresse IP publique sous Linux est simple si vous mesurez la bonne chose. ip addr décrit la machine ; curl ou dig montrent ce que voit l’extérieur. La différence devient décisive dès qu’il y a NAT, VPN, IPv6, box opérateur ou infrastructure multi-sortie.

La prochaine action utile : testez IPv4 et IPv6 séparément, notez le contexte réseau, puis automatisez seulement quand la commande est fiable.

Pour approfondir ce point, consultez identifier les ports ouverts sous Linux avec, qui traite plus précisément de comment identifier les ports ouverts sous linux avec ss, lsof et netstat.