La boîte à outils réseau

Vous savez ce qu'est une IP et comment faire un ping, mais face à un problème réseau vous ne savez pas par où commencer ? Cette leçon vous donne les 8 commandes essentielles pour diagnostiquer n'importe quel problème réseau sur Linux. Chaque commande est expliquée avec des exemples concrets et des sorties commentées.

Prérequis

• Les bases absolues : vous savez ce qu'est une IP, une passerelle, et vous avez déjà utilisé ping → Revoir les bases absolues
• Une machine Linux connectée à votre réseau local
• Un terminal ouvert

Installation des outils

La plupart de ces commandes sont préinstallées sur les distributions Linux. Si une commande manque :

# Debian/Ubuntu
sudo apt install iproute2 dnsutils curl netcat-openbsd

# Fedora/RHEL
sudo dnf install iproute bind-utils curl nmap-ncat

Ce que vous allez apprendre

• Concepts clés : port, protocole, DNS, les bases pour comprendre les commandes
• ip : voir et configurer les interfaces réseau
• ss : lister les ports ouverts et connexions actives
• ping : tester la connectivité (rappel + options avancées)
• nslookup / dig : résoudre un nom de domaine en IP
• curl / wget : tester un service HTTP
• nc (netcat) : tester si un port TCP est ouvert

Les concepts clés à maîtriser

Avant de plonger dans les commandes, assurez-vous de comprendre ces trois concepts fondamentaux : le port, le protocole et le DNS. Sans eux, les commandes n'auront pas de sens.

Qu'est-ce qu'un port ?

Dans la leçon sur les bases, vous avez appris qu'une adresse IP identifie une machine sur le réseau. Mais une machine peut faire tourner plusieurs services en même temps : un serveur web, une base de données, un serveur SSH...

Comment distinguer ces services ? C'est là qu'intervient le port.

Adresse IP + port = adresse complète d'un service, par exemple 192.168.1.100:443. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Un port est un numéro (de 0 à 65535) qui identifie un service sur une machine. L'adresse complète d'un service, c'est donc :

IP:PORT

Par exemple : 192.168.1.100:80 désigne le service HTTP (port 80) sur la machine 192.168.1.100.

Les ports bien connus

Certains ports sont réservés par convention pour des services standards. Vous les rencontrerez constamment :

Port	Service	Description
22	SSH	Connexion à distance sécurisée
80	HTTP	Sites web (non chiffré)
443	HTTPS	Sites web (chiffré TLS/SSL)
53	DNS	Résolution de noms
25	SMTP	Envoi d'emails
3306	MySQL	Base de données MySQL
5432	PostgreSQL	Base de données PostgreSQL
6379	Redis	Cache/base de données Redis
8080	HTTP alternatif	Souvent utilisé pour les tests

Glissez pour voir

Ports privilégiés

Les ports inférieurs à 1024 sont dits « privilégiés » : écouter dessus demande les droits root ou la capability CAP_NET_BIND_SERVICE. C'est pourquoi les applications de test utilisent souvent des ports comme 3000, 8000 ou 8080.

Qu'est-ce qu'un protocole ?

Un protocole est un ensemble de règles qui définissent comment deux machines communiquent : le format exact des messages, l'ordre dans lequel ils sont échangés, et ce que chaque partie doit répondre. Les deux extrémités doivent implémenter le même protocole, sinon les octets reçus n'ont aucun sens pour le destinataire.

Les deux protocoles de transport que vous rencontrerez sont :

Protocole	Caractéristiques	Utilisé pour
TCP	Fiable, connexion établie, ordre garanti	HTTP, SSH, email, bases de données
UDP	Rapide, sans connexion, pas de garantie	DNS, streaming vidéo, jeux en ligne

Glissez pour voir

Quand vous verrez tcp ou udp dans les sorties de commandes, vous saurez de quoi il s'agit.

Qu'est-ce que le DNS ?

Vous tapez google.com dans votre navigateur, mais les machines ne comprennent que les adresses IP. Qui fait la traduction ? Le DNS (Domain Name System).

Sans résolution, la connexion échoue. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Le DNS est un système qui traduit les noms de domaine (google.com, github.com) en adresses IP (142.250.178.142). C'est l'annuaire d'Internet.

Le processus :

1. Vous tapez google.com dans votre navigateur
2. Votre machine demande au serveur DNS : « Quelle est l'IP de google.com ? »
3. Le serveur DNS répond : « 142.250.178.142 »
4. Votre navigateur peut maintenant contacter cette IP

Pourquoi c'est important ?

Le DNS est souvent la cause numéro 1 des problèmes réseau. Si la résolution DNS échoue, impossible d'accéder aux sites par leur nom, même si votre connexion Internet fonctionne parfaitement.

Quand vous faites ping google.com et que ça échoue, la première question à se poser est : « Est-ce un problème de DNS ou de connectivité ? » Pour le savoir, testez avec une IP directe : ping 8.8.8.8.

Le fichier /etc/resolv.conf

Sur Linux, le serveur DNS utilisé par votre machine est configuré dans /etc/resolv.conf :

cat /etc/resolv.conf

Sortie typique :

nameserver 192.168.1.1
nameserver 8.8.8.8

• 192.168.1.1 : votre box fait souvent office de serveur DNS local
• 8.8.8.8 : serveur DNS de Google (en secours)

Si ce fichier est vide ou mal configuré, aucune résolution DNS ne fonctionnera.

Pourquoi ces commandes ? Le scénario type

Imaginez : vous venez de déployer une application, mais elle ne répond pas. Avant de paniquer, vous devez diagnostiquer méthodiquement. Voici les questions que vous allez vous poser, et les commandes qui y répondent :

Question	Commande	Section
Ma machine a-t-elle une IP ? Est-elle connectée ?	ip addr, ip link	La commande ip
Quels services tournent sur ma machine ? Sur quels ports ?	ss -tlnp	La commande ss
Mon serveur répond-il sur le réseau ?	ping	La commande ping
Le nom de domaine est-il résolu correctement ?	nslookup, dig	Résolution DNS
Le service HTTP répond-il ? Quel code retour ?	curl, wget	Tester HTTP
Le port est-il ouvert et accessible ?	nc (netcat)	La commande nc

Glissez pour voir

L'ordre compte

Quand vous diagnostiquez un problème, suivez cet ordre logique :

1. Vérifier votre propre machine (IP, interfaces)
2. Vérifier la connectivité réseau (ping)
3. Vérifier la résolution DNS (nslookup/dig)
4. Vérifier le service (curl, nc)

Tester dans le désordre vous fera perdre du temps. Si vous n'avez pas d'IP, inutile de tester le DNS !

La commande ip : tout sur vos interfaces

La commande ip remplace les anciennes commandes ifconfig et route. C'est la commande moderne pour gérer le réseau sur Linux.

Voir vos interfaces : ip link show

Cette commande liste toutes les interfaces réseau de votre machine, qu'elles soient actives ou non :

ip link show

Sortie :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff

Lecture :

Élément	Signification
lo	Interface loopback (votre machine qui parle à elle-même)
eth0	Carte réseau Ethernet filaire
wlan0	Carte réseau Wi-Fi
state UP	Interface active et connectée
state DOWN	Interface inactive (câble débranché ou désactivée)
link/ether 52:54:00:...	Adresse MAC (identifiant physique unique de la carte)

Glissez pour voir

UP vs DOWN : la première chose à vérifier

Si votre interface est en state DOWN, elle ne peut pas communiquer. C'est souvent la première cause de « pas de réseau » : câble débranché, Wi-Fi non connecté, ou interface désactivée.

Voir vos adresses IP : ip addr show

Vous connaissez déjà cette commande de la leçon sur les bases. Elle affiche les adresses IP attribuées à chaque interface :

ip addr show

Sortie :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 192.168.1.45/24 brd 192.168.1.255 scope global dynamic eth0
    inet6 fe80::5054:ff:fe12:3456/64 scope link

Nouveaux éléments :

Élément	Signification
inet 192.168.1.45/24	Adresse IPv4 attribuée par votre box (DHCP)
inet6 fe80::...	Adresse IPv6 locale (auto-générée)
dynamic	L'adresse a été obtenue par DHCP (automatiquement)
brd 192.168.1.255	Adresse de broadcast (pour envoyer à tout le réseau)

Glissez pour voir

Raccourci : ip a fait la même chose que ip addr show.

Voir les routes : ip route show

Déjà croisée dans la leçon sur les bases, cette commande montre comment votre machine sait où envoyer les paquets :

ip route show

Sortie :

default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.45

Lecture rapide :

• default via 192.168.1.1 : pour Internet, envoyer à la box (192.168.1.1)
• 192.168.1.0/24 dev eth0 : pour le réseau local, envoyer directement via eth0

Raccourci : ip r fait la même chose.

La commande ss : qui écoute sur quoi ?

ss (Socket Statistics) remplace l'ancienne commande netstat. Elle permet de voir quels programmes écoutent sur quels ports et quelles connexions sont actives.

Lister les ports en écoute : ss -tuln

C'est LA commande à connaître pour savoir ce qui tourne sur votre machine :

ss -tuln

Signification des options :

Option	Signification
-t	Afficher les connexions TCP
-u	Afficher les connexions UDP
-l	Afficher uniquement les ports en écoute (listening)
-n	Afficher les numéros de port (pas les noms de service)

Glissez pour voir

Sortie :

Netid  State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port
tcp    LISTEN  0       128     0.0.0.0:22            0.0.0.0:*
tcp    LISTEN  0       511     0.0.0.0:80            0.0.0.0:*
tcp    LISTEN  0       128     127.0.0.1:5432        0.0.0.0:*
udp    UNCONN  0       0       0.0.0.0:68            0.0.0.0:*

Lecture :

Local Address:Port	Ce que ça signifie
0.0.0.0:22	SSH écoute sur toutes les interfaces, port 22
0.0.0.0:80	Un serveur web écoute sur toutes les interfaces, port 80
127.0.0.1:5432	PostgreSQL écoute uniquement en local (pas accessible de l'extérieur)
0.0.0.0:68	Client DHCP (UDP) en attente

Glissez pour voir

0.0.0.0 vs 127.0.0.1

• 0.0.0.0 : le service est accessible depuis n'importe quelle interface (potentiellement depuis l'extérieur)
• 127.0.0.1 : le service n'est accessible que localement (depuis la machine elle-même)

Un service en 127.0.0.1 ne peut jamais être atteint depuis une autre machine du réseau.

Voir quel programme utilise un port : ss -tulnp

Ajoutez -p pour voir le nom du processus qui utilise chaque port :

sudo ss -tulnp

Sortie :

Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:22           users:(("sshd",pid=1234,fd=3))
tcp    LISTEN  0.0.0.0:80           users:(("nginx",pid=5678,fd=6))
tcp    LISTEN  127.0.0.1:5432       users:(("postgres",pid=9012,fd=5))

Maintenant vous savez que :

• sshd écoute sur le port 22
• nginx écoute sur le port 80
• postgres écoute sur le port 5432

Pourquoi sudo ?

L'option -p nécessite les droits root pour voir les processus des autres utilisateurs. Sans sudo, vous ne verrez que vos propres processus.

Voir les connexions actives : ss -tan

Pour voir les connexions établies (pas seulement les ports en écoute) :

ss -tan

Sortie :

State      Recv-Q  Send-Q  Local Address:Port   Peer Address:Port
LISTEN     0       128     0.0.0.0:22            0.0.0.0:*
ESTAB      0       0       192.168.1.45:22       192.168.1.100:54321
ESTAB      0       0       192.168.1.45:80       203.0.113.50:12345

Lecture :

• LISTEN : le service attend des connexions
• ESTAB (Established) : une connexion est active
• 192.168.1.100:54321 → 192.168.1.45:22 : quelqu'un est connecté en SSH depuis 192.168.1.100

La commande ping : options avancées

Vous connaissez ping depuis la leçon sur les bases. Voici quelques options utiles :

Ping continu (jusqu'à Ctrl+C)

ping 8.8.8.8

Sans -c, le ping continue indéfiniment. Utile pour surveiller une connexion.

Ping avec intervalle personnalisé

ping -i 0.2 8.8.8.8

Envoie un ping toutes les 0.2 secondes au lieu d'une seconde (utile pour détecter des micro-coupures).

Ping avec taille de paquet

ping -s 1400 8.8.8.8

Envoie 1400 octets de données au lieu de 56. Seul, ce test ne prouve rien sur la MTU, car le noyau peut fragmenter les gros paquets ; ajoutez -M do, qui interdit la fragmentation, comme le détaille la leçon MTU, MSS et PMTUD.

Les commandes DNS : nslookup et dig

Le DNS traduit les noms de domaine (google.com) en adresses IP. Quand un site « ne répond pas », c'est souvent un problème DNS.

Résolution simple : nslookup

nslookup google.com

Sortie :

Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.185.46

Lecture :

Ligne	Signification
Server: 192.168.1.1	Votre box a répondu à la requête DNS
Address: 142.250.185.46	L'adresse IP de google.com

Glissez pour voir

Préférez dig

nslookup reste disponible partout, mais dig affiche la réponse DNS complète (sections, TTL, serveur interrogé, temps de réponse) et host donne la forme la plus courte : préférez-les dès que vous dépannez.

Résolution détaillée : dig

dig donne beaucoup plus d'informations :

dig google.com

Sortie (simplifiée) :

; <<>> DiG 9.18.1 <<>> google.com
;; ANSWER SECTION:
google.com.             300     IN      A       142.250.185.46

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

Éléments importants :

Élément	Signification
A 142.250.185.46	Enregistrement de type A (IPv4)
300	TTL (Time To Live) : le cache garde cette info 300 secondes
Query time: 12 msec	Temps de réponse du serveur DNS

Glissez pour voir

Forcer un serveur DNS spécifique

Si vous suspectez un problème avec le DNS de votre box, testez avec Google ou Cloudflare :

dig @8.8.8.8 google.com
dig @1.1.1.1 google.com

Le @ indique quel serveur DNS interroger.

Cas pratique : site inaccessible

1. Tester la résolution DNS

   nslookup monsite.com

   Si « server can't find monsite.com » → problème DNS ou nom inexistant.

2. Tester avec un autre serveur DNS

   dig @8.8.8.8 monsite.com

   Si ça marche ici mais pas avec votre box → problème de configuration DNS locale.

3. Vérifier quel DNS votre machine utilise

   cat /etc/resolv.conf

   Vous verrez les serveurs DNS configurés (ligne nameserver).

Les commandes HTTP : curl et wget

Pour tester si un service web répond, curl et wget sont indispensables.

Tester une URL : curl

curl -I https://google.com

L'option -I récupère uniquement les en-têtes (sans télécharger la page) :

Sortie :

HTTP/2 200
content-type: text/html; charset=ISO-8859-1
date: Sat, 24 Jan 2026 08:00:00 GMT

Lecture :

Élément	Signification
HTTP/2 200	Le serveur répond avec le code 200 OK (succès)
content-type: text/html	Le serveur renvoie du HTML

Glissez pour voir

Codes de réponse HTTP courants

La première ligne de la sortie de curl -I porte le code de statut, et c'est la donnée la plus riche du diagnostic web. Retenez surtout le classement par centaine : un 2xx signale un succès, un 3xx une redirection, un 4xx une erreur côté client (mauvaise URL, droits insuffisants), un 5xx une erreur côté serveur. Cette distinction 4xx contre 5xx oriente immédiatement la recherche : un 404 se corrige dans l'URL, un 502 se corrige sur le serveur ou son backend.

Code	Signification	Cause probable
200	OK	Tout fonctionne
301/302	Redirection	Le site redirige vers une autre URL
403	Forbidden	Accès interdit (permissions)
404	Not Found	La page n'existe pas
500	Internal Server Error	Erreur côté serveur
502	Bad Gateway	Le reverse proxy ne peut pas joindre le backend
503	Service Unavailable	Service surchargé ou en maintenance

Glissez pour voir

Voir les détails de connexion : curl -v

Pour débugger, l'option -v (verbose) montre tout le processus :

curl -v https://google.com

Vous verrez :

• La résolution DNS
• La connexion TCP
• La négociation TLS
• Les en-têtes envoyés et reçus

Télécharger un fichier : wget

wget https://example.com/fichier.zip

wget télécharge le fichier dans le répertoire courant. Utile pour tester si le téléchargement fonctionne.

La commande nc (netcat) : tester un port TCP

Netcat ouvre, lit et écrit des connexions TCP et UDP brutes depuis la ligne de commande. C'est cette polyvalence qui en fait un outil de diagnostic très répandu, mais son usage le plus courant reste le plus simple : vérifier si un port distant accepte les connexions.

Tester si un port répond : nc -zv

nc -zv google.com 443

Options :

Option	Signification
-z	Mode scan : teste juste si le port est ouvert, sans envoyer de données
-v	Mode verbose : affiche le résultat

Glissez pour voir

Sortie si le port est ouvert :

Connection to google.com 443 port [tcp/https] succeeded!

Sortie si le port est fermé :

Pour l'observer, visez un port où rien n'écoute sur votre propre machine, avec nc -zv localhost 12345 :

nc: connect to localhost (127.0.0.1) port 12345 (tcp) failed: Connection refused

Sortie si le port est filtré (pare-feu) :

Visez une adresse qui ne répond jamais, 192.0.2.1, réservée à la documentation, en bornant l'attente à trois secondes avec nc -zv -w 3 192.0.2.1 80 :

nc: connect to 192.0.2.1 port 80 (tcp) timed out: Operation now in progress

refused vs timeout

• Connection refused : une réponse négative immédiate, le plus souvent un port fermé (pas de service qui écoute), mais un pare-feu qui rejette produit le même message
• Connection timed out : le port est le plus souvent filtré (un pare-feu jette les paquets), mais une perte ou un routage cassé donnent le même silence

Cette distinction est cruciale pour le diagnostic !

Tester plusieurs ports

nc -zv google.com 80 443

Ou une plage de ports :

nc -zv 192.168.1.1 20-25

Cas pratique : service inaccessible

1. Vérifier que le DNS fonctionne

   nslookup api.example.com

2. Tester si le port est ouvert

   nc -zv api.example.com 443

3. Tester la réponse HTTP

   curl -I https://api.example.com

Si le port est ouvert mais curl échoue → problème applicatif (pas réseau).

Récapitulatif des commandes

Ce tableau condense toute la leçon en une seule vue à garder ouverte pendant vos premiers diagnostics. Lisez-le de haut en bas : l'ordre reprend la progression logique du dépannage, de votre machine (ip) vers les services distants (nc, curl). La colonne « Quand l'utiliser » est la plus utile au début, elle vous dit quelle commande dégainer face à un symptôme donné plutôt que de toutes les essayer au hasard.

Commande	Ce qu'elle fait	Quand l'utiliser
ip link show	Liste les interfaces	Vérifier si une interface est UP
ip addr show	Affiche les adresses IP	Voir quelle IP a été attribuée
ip route show	Affiche les routes	Vérifier la passerelle par défaut
ss -tuln	Ports en écoute	Voir quels services tournent
ss -tulnp	Ports + processus	Identifier quel programme écoute
ss -tan	Connexions actives	Voir qui est connecté
ping -c 4 <ip>	Test connectivité	Vérifier qu'une machine répond
nslookup <nom>	Résolution DNS simple	Traduire un nom en IP
dig <nom>	Résolution DNS détaillée	Débugger un problème DNS
curl -I <url>	En-têtes HTTP	Tester si un site répond
curl -v <url>	Détails connexion	Débugger une connexion HTTP
nc -zv <host> <port>	Test port TCP	Vérifier si un port est ouvert

Glissez pour voir

Dépannage : arbre de décision

Cet arbre transforme les commandes de la leçon en une méthode. Suivez-le de haut en bas et arrêtez-vous à la première branche qui répond : chaque niveau ne se teste que si le précédent a réussi. Inutile de vérifier le DNS si le ping échoue déjà, ni le service HTTP si le port est filtré. Cette discipline évite le piège classique du débutant, qui teste tout dans le désordre et tire de mauvaises conclusions.

Dans le schéma, chaque question porte une commande de la leçon, et sa sortie « oui », à droite sur la même ligne, donne le diagnostic et le geste suivant. Seul un « non » fait descendre au test suivant. Les deux questions sur nc portent sur la même commande : elles distinguent un timeout, le silence d'un pare-feu qui jette, d'un refused, une réponse négative immédiate.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

TP : diagnostiquer un serveur web

Mettons en pratique toutes les commandes vues dans cette leçon. Vous allez diagnostiquer un serveur web étape par étape, comme si vous deviez débugger un problème en production.

Scénario

Vous devez vérifier qu'un serveur web est accessible. Nous allons utiliser GitHub (github.com) comme cible, un service que vous utiliserez souvent dans un contexte DevOps.

Étape 1 : Vérifier votre propre machine

Avant de tester un serveur distant, assurez-vous que votre machine est bien configurée.

1. Vérifiez que vous avez une IP

   ip addr show | grep "inet "

   Vous devez voir une ligne avec votre IP locale (ex: 192.168.1.x).

2. Vérifiez que votre interface est UP

   ip link show | grep -E "state UP|state DOWN"

   Votre interface principale (eth0, wlan0, ens33...) doit être UP.

3. Vérifiez votre passerelle

   ip route | grep default

   Vous devez voir default via <IP de votre box>.

Résultat attendu

Si ces 3 commandes montrent une IP, une interface UP et une passerelle, votre machine est prête. Sinon, reprenez la leçon sur les bases pour diagnostiquer le problème local.

Étape 2 : Tester la connectivité réseau

1. Ping vers votre passerelle (votre box)

   ping -c 3 $(ip route | grep default | awk '{print $3}')

   Cette commande récupère automatiquement l'IP de votre passerelle et la ping.

2. Ping vers Internet (IP publique)

   ping -c 3 8.8.8.8

   Si ça fonctionne, vous avez accès à Internet.

3. Ping vers un nom de domaine

   ping -c 3 google.com

   Si ça fonctionne, le DNS fonctionne aussi (Google résout et répond au ping).

Étape 3 : Diagnostiquer le DNS

1. Résoudre le nom de domaine

   nslookup github.com

   Vous devez obtenir une ou plusieurs IP (GitHub utilise plusieurs serveurs).

2. Vérifier avec un serveur DNS spécifique

   dig github.com @8.8.8.8 +short

   Comparez le résultat avec la commande précédente. Les IP peuvent différer selon la localisation.

3. Voir les détails de la résolution

   dig github.com

   Repérez la section ANSWER SECTION et le Query time.

Étape 4 : Tester le service web

1. Vérifier que le port 443 (HTTPS) est ouvert

   nc -zv github.com 443

   Vous devez voir Connection to github.com 443 port [tcp/https] succeeded!.

2. Tester le port SSH de GitHub (pour git clone en SSH)

   nc -zv github.com 22

   GitHub accepte les connexions SSH sur le port 22.

3. Tester la réponse HTTPS

   curl -I https://github.com

   Vous devez voir HTTP/2 200 (GitHub utilise HTTP/2).

4. Tester l'API GitHub

   curl -I https://api.github.com

   L'API répond aussi en HTTP/2 200. Notez les headers X-RateLimit-*.

Étape 5 : Explorer votre propre machine

Maintenant, regardons ce qui tourne sur votre machine :

1. Lister tous les ports en écoute

   ss -tuln

   Notez les ports ouverts sur votre machine.

2. Identifier les processus (nécessite sudo)

   sudo ss -tulnp

   Vous voyez maintenant quel programme écoute sur chaque port.

3. Filtrer un port spécifique (exemple : SSH)

   ss -tuln | grep :22

   Si le port 22 apparaît, un serveur SSH tourne.

Récapitulatif du TP

Vous venez de réaliser un diagnostic complet. Voici ce que vous avez vérifié :

Étape	Commandes utilisées	Ce que vous avez vérifié
1	ip addr, ip link, ip route	Configuration locale
2	ping	Connectivité réseau
3	nslookup, dig	Résolution DNS
4	nc -zv, curl -I	Accessibilité du service
5	ss -tuln, ss -tulnp	Services locaux

Glissez pour voir

Exercice bonus

Essayez de diagnostiquer un vrai problème :

1. Déconnectez temporairement votre câble réseau ou Wi-Fi
2. Relancez les commandes de l'étape 1 et 2
3. Observez les messages d'erreur
4. Reconnectez et vérifiez que tout fonctionne à nouveau

Cet exercice vous apprend à reconnaître les symptômes d'une panne réseau.

À retenir

1. ip remplace ifconfig et route, commande moderne pour tout
2. ss -tuln : première commande pour voir ce qui tourne sur une machine
3. ss -tulnp avec sudo pour voir les processus associés aux ports
4. 0.0.0.0 = accessible de partout, 127.0.0.1 = local uniquement
5. nslookup pour tester DNS rapidement, dig pour débugger
6. curl -I pour tester un service HTTP sans télécharger
7. nc -zv pour tester si un port TCP est ouvert
8. refused = réponse négative immédiate (port fermé, ou rejet d'un pare-feu), timeout = silence (le plus souvent un pare-feu qui jette)

Testez vos connaissances

Ce contrôle vous demande surtout de choisir la bonne commande face à un symptôme, et de lire ses sorties : une ligne de ss, un refused contre un timeout, un code HTTP. Les erreurs de lecture se corrigent en reprenant le récapitulatif des commandes.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes sur les commandes réseau

Ces questions reviennent souvent chez les débutants qui découvrent ces outils : l'équivalent moderne d'une commande ancienne (ifconfig, netstat, arp), le test d'un port, la résolution d'un nom. Parcourez-les pour lever les derniers doutes avant de continuer.

Comment voir les ports ouverts et qui écoute dessus ?

Quel est l'équivalent moderne de ifconfig ?

Comment tester si un port distant est ouvert ?

Comment résoudre un nom de domaine en ligne de commande ?

Comment voir la table de routage et la passerelle par défaut ?

Comment consulter la table ARP sous Linux ?

×

📖 Voir la documentation →