Module 2 :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 ? Ce module vous donne les 10 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.

TL;DR — L’essentiel en 30 secondes

• ip addr : voir vos interfaces et adresses IP
• ss -tlnp : voir les ports en écoute
• ping : tester la connectivité de base
• nc -zv : tester si un port TCP répond
• dig : résoudre un nom DNS

Je sais que c’est bon si…

• ip addr me montre mes interfaces réseau
• ss -tlnp me montre les services en écoute
• dig +short google.com retourne une IP

Les 5 commandes à connaître par cœur

# 1. Mon IP et mes interfaces
ip addr

# 2. Ports ouverts localement
ss -tlnp

# 3. Test de connectivité
ping -c 2 8.8.8.8

# 4. Test d'un port TCP
nc -zv google.com 443

# 5. Résolution DNS
dig +short github.com

Prérequis

• Module 1 complété : vous savez ce qu’est une IP, une passerelle, et vous avez déjà utilisé ping
• 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 4 concepts fondamentaux. Sans eux, les commandes n’auront pas de sens.

Qu’est-ce qu’un port ?

Dans le module 1, 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.

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.

Analogie : si l’adresse IP est l’adresse d’un immeuble, le port est le numéro d’appartement. L’immeuble (la machine) peut héberger plusieurs résidents (services), chacun à un numéro différent.

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” : seul l’utilisateur root peut démarrer un service qui écoute sur ces ports. 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. C’est comme une langue commune : si vous parlez français et votre interlocuteur parle chinois, vous ne vous comprendrez pas.

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

Analogie :

• TCP = courrier recommandé avec accusé de réception. Plus lent, mais vous êtes sûr que ça arrive.
• UDP = carte postale. Rapide, mais pas de garantie de livraison ni d’ordre.

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).

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 du Module 1. 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

Rappel du Module 1 — 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 du Module 1. 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 des paquets de 1400 octets au lieu de 56. Utile pour tester les problèmes de MTU.

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

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: Fri, 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

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 est le couteau suisse du réseau. Son usage le plus courant : tester si un port est ouvert.

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é :

nc: connect to google.com port 12345 (tcp) failed: Connection refused

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

nc: connect to google.com port 12345 (tcp) failed: Connection timed out

refused vs timeout

• Connection refused : le port est fermé (pas de service qui écoute)
• Connection timed out : le port est filtré (un pare-feu bloque les paquets)

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

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

Service inaccessible ?
│
├─► ping <ip> échoue ?
│   └─► Problème réseau (Module 1 : diagnostic en 3 étapes)
│
├─► nslookup <nom> échoue ?
│   └─► Problème DNS (tester avec @8.8.8.8)
│
├─► nc -zv <host> <port> timeout ?
│   └─► Port filtré (pare-feu)
│
├─► nc -zv <host> <port> refused ?
│   └─► Service non démarré (vérifier avec ss -tuln sur le serveur)
│
└─► curl -I <url> erreur 5xx ?
    └─► Problème applicatif (logs du serveur)

TP : diagnostiquer un serveur web

Mettons en pratique toutes les commandes vues dans ce module. 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, revenez au Module 1 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 = port fermé, timeout = port filtré (pare-feu)

Testez vos connaissances

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

Prochaines étapes

Module 3 : Adresses IP et sous-réseaux Comprendre CIDR, les masques et calculer un sous-réseau

Module 4 : Le routage Tables de routage, passerelles et traceroute

Retour au parcours Vue d'ensemble de la formation réseau

×

📖 Voir la documentation →