Introduction
Le dépannage réseau est plus simple lorsque vous vérifiez une couche à la fois. Commencez par l’identité de l’hôte, puis vérifiez ses interfaces et ses adresses, la sélection des routes, l’accessibilité de base, la résolution des noms, les sockets en écoute, la réponse de l’application et, enfin, la politique du pare-feu local.
Dans cet atelier, vous suivrez cette séquence sur un hôte Ubuntu. Un service HTTP préparé écoute uniquement sur le port de loopback 8088, ce qui vous fournit une cible sûre pour vous exercer avec ss, curl et les règles UFW. Vous ne modifierez pas la configuration des interfaces de l’hôte, la route par défaut, les paramètres DNS ni le service SSH. Avant d’activer UFW, vous préserverez explicitement l’accès SSH.
Identifier l’hôte
Dans cette étape, vous examinerez le nom d’hôte et les enregistrements de noms locaux qui permettent aux programmes d’identifier cette machine.
Accédez à l’espace de travail de l’atelier :
cd /home/labex/project/network-lab
Affichez le nom d’hôte actuel :
hostname
Affichez les identités statique, transitoire et du système d’exploitation connues de systemd :
hostnamectl
Static hostname correspond au nom configuré. Sur les machines d’entraînement dans le cloud, le nom transitoire peut être attribué au démarrage.
Examinez les associations de noms d’hôtes locales :
cat /etc/hosts
Les noms de loopback localhost, 127.0.0.1 et ::1 identifient ce même hôte sans utiliser de réseau externe. Affichez les adresses IP attribuées à l’hôte dans un format compact :
hostname -I
Enregistrez le nom d’hôte et la liste des adresses :
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
Examiner les interfaces et les adresses IP
Dans cette étape, vous identifierez les interfaces réseau, leur état de liaison, les adresses IPv4, les préfixes et la portée des adresses.
Utilisez l’affichage synthétique des liaisons :
ip -brief link
lo est l’interface de loopback. Une autre interface, généralement nommée eth0 ou ens..., connecte la machine virtuelle à son réseau. UP signifie que l’interface est activée administrativement.
Affichez les adresses dans un format compact :
ip -brief address
Une adresse telle que 192.0.2.10/24 combine une adresse IPv4 et une longueur de préfixe. Le préfixe indique quels bits de tête identifient le réseau local.
Examinez l’interface de loopback en détail :
ip address show dev lo
L’adresse IPv4 127.0.0.1/8 possède scope host ; elle n’est donc valide qu’à l’intérieur de cet hôte. Trouvez l’interface utilisée par la route par défaut :
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
La commande ifconfig est un ancien outil de gestion des interfaces, encore présent dans des procédures d’exploitation et des consignes de dépannage. Comparez sa sortie avec celle de la commande moderne ip que vous venez d’examiner :
ifconfig
Enregistrez également cette vue historique :
ifconfig > ifconfig-addresses.txt
Enregistrez un instantané synthétique des interfaces :
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Lire la table de routage
Dans cette étape, vous identifierez la passerelle par défaut et demanderez à Linux quelle route il utiliserait pour atteindre une destination.
Affichez la table de routage principale :
ip route
Les routes connectées décrivent les réseaux directement attachés. Une ligne commençant par default via est utilisée lorsqu’aucune route plus spécifique ne correspond.
Demandez au noyau comment il atteindrait une destination publique. Cette commande indique la passerelle, l’interface et l’adresse source sélectionnées sans envoyer de paquet :
ip route get 1.1.1.1
Extrayez la passerelle et l’interface par défaut :
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
Enregistrez le résumé de la route :
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
Tester l’accessibilité du réseau
Dans cette étape, vous utiliserez ping pour tester des limites de plus en plus éloignées, tout en tenant compte du fait que certains réseaux bloquent les paquets de diagnostic.
Commencez par le loopback. L’option -c 2 envoie deux requêtes et -W 2 attend au maximum deux secondes pour chaque réponse :
ping -c 2 -W 2 127.0.0.1
Un test de loopback réussi prouve que la pile IP locale répond. Récupérez et testez ensuite la passerelle par défaut :
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
Le message de repli est important, car un routeur peut transférer le trafic tout en refusant les requêtes ping. Testez une adresse IP publique sans dépendre du DNS :
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
Enregistrez un résultat stable de connectivité locale au lieu de dépendre de la politique du réseau externe :
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
Tester la résolution des noms d’hôtes
Dans cette étape, vous examinerez la configuration du résolveur et traduirez des noms d’hôtes en adresses.
Affichez le fichier du résolveur utilisé par les applications Linux standard :
cat /etc/resolv.conf
Il contient généralement une ou plusieurs lignes nameserver. Sur les hôtes utilisant systemd-resolved, l’adresse peut désigner un résolveur stub local plutôt qu’un serveur DNS externe directement.
Résolvez un nom local à l’aide de la configuration complète des services de noms du système :
getent hosts localhost
getent suit /etc/nsswitch.conf ; il peut donc combiner /etc/hosts, le DNS et d’autres sources configurées. Résolvez un nom externe et demandez les adresses de socket IPv4 :
getent ahostsv4 example.com
Si le ping vers une adresse IP réussit mais que cette recherche échoue, concentrez votre analyse sur la configuration du résolveur ou l’accessibilité du DNS. Enregistrez le premier enregistrement IPv4 résolu :
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Examiner un port en écoute et une réponse HTTP
Dans cette étape, vous associerez un socket TCP en écoute au processus qui le possède, puis vous testerez le protocole applicatif.
Le service de démonstration préparé écoute sur le port de loopback 8088. Utilisez ss pour examiner les sockets TCP en écoute. Les options -l, -t, -n et -p signifient respectivement écoute, TCP, adresses numériques et informations sur le processus :
sudo ss -ltnp | grep ':8088'
Recherchez 127.0.0.1:8088. Une liaison sur le loopback signifie que le service est accessible uniquement depuis cet hôte.
Vérifiez le processus du service associé au socket :
systemctl status labex-network-demo.service --no-pager
Utilisez curl -i pour afficher les en-têtes et le corps de la réponse HTTP :
curl -i http://127.0.0.1:8088/
Un statut HTTP 200 OK prouve davantage qu’un simple port ouvert : l’application a accepté une requête HTTP et a renvoyé du contenu. Enregistrez uniquement le corps de la réponse avec le mode silencieux -s :
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
Préserver l’accès et activer UFW
Dans cette étape, vous examinerez l’état d’UFW, préserverez l’accès à l’administration distante, autoriserez le port du service d’entraînement et activerez le pare-feu.
UFW est une interface pour les règles de filtrage de paquets de Linux. Examinez son état actuel :
sudo ufw status verbose
La configuration laisse UFW inactif avec un jeu de règles vierge. Avant d’activer un pare-feu sur un hôte distant, autorisez le chemin d’administration dont vous dépendez. Cette machine virtuelle utilise le port TCP 22 pour SSH :
sudo ufw allow 22/tcp
Autorisez maintenant le trafic TCP entrant vers le port du service d’entraînement :
sudo ufw allow 8088/tcp
Examinez les modifications préparées avant l’activation :
sudo ufw show added
Activez UFW sans afficher de demande de confirmation interactive :
sudo ufw --force enable
Vérifiez que le pare-feu est actif et que les deux autorisations sont présentes :
sudo ufw status verbose
Le service est lié au loopback ; testez-le donc localement après la modification du pare-feu :
curl -fsS http://127.0.0.1:8088/
Enregistrez l’état actif comme résultat observable :
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
L’ordre des opérations est important : préservez le chemin d’administration, ajoutez les règles nécessaires au service, activez le pare-feu, puis vérifiez immédiatement la politique et l’accessibilité de l’application. Les hôtes de production peuvent utiliser un autre port SSH ; confirmez donc le véritable chemin d’administration au lieu de supposer qu’il s’agit du port 22.
Résumé
Vous avez suivi une chaîne structurée de diagnostic réseau sous Linux : identité de l’hôte, interfaces et adresses IP, sélection des routes, accessibilité, résolution des noms, sockets en écoute et réponse HTTP. Vous avez appris que chaque couche répond à une question différente et qu’un échec à une limite donnée permet de cibler l’étape suivante de l’analyse.
Vous avez également préservé l’accès SSH, autorisé le port d’un service d’entraînement, activé UFW et vérifié à la fois la politique active et la réponse de l’application. Ces habitudes vous préparent à diagnostiquer et à sécuriser un service réseau sans effectuer de modifications générales et perturbatrices.
