Introduction
Le dépannage réseau est plus simple lorsque vous vérifiez chaque couche séparément. Commencez par l’identité de la machine, puis vérifiez ses interfaces et ses adresses, la sélection de la route, 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 ce laboratoire, vous suivrez cette séquence sur un hôte Ubuntu. Un service HTTP préconfiguré écoute uniquement sur le port de bouclage 8088, ce qui fournit une cible sûre pour vous exercer avec ss, curl et les règles UFW. Vous ne modifierez ni la configuration des interfaces de la machine, ni la route par défaut, ni les paramètres DNS, ni l’accès SSH.
Identifier la machine
Dans cette étape, vous examinerez le nom d’hôte ainsi que les enregistrements locaux qui permettent aux programmes d’identifier cette machine.
Accédez à l’espace de travail du laboratoire :
cd /home/labex/project/network-lab
Affichez le nom d’hôte actuel :
hostname
Affichez l’identité statique, transitoire et celle du système d’exploitation connues de systemd :
hostnamectl
Static hostname correspond au nom configuré. Sur les machines d’entraînement hébergées dans le cloud, le nom transitoire peut être attribué au démarrage.
Examinez les correspondances locales des noms d’hôtes :
cat /etc/hosts
Les noms de bouclage localhost, 127.0.0.1 et ::1 désignent cette même machine sans utiliser le réseau externe. Affichez les adresses IP attribuées à l’hôte sous une forme compacte :
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, leurs adresses IPv4, leurs préfixes et la portée des adresses.
Utilisez l’affichage succinct des liaisons :
ip -brief link
lo est l’interface de bouclage. Une autre interface, généralement nommée eth0 ou ens..., relie la machine virtuelle à son réseau. UP signifie que l’interface est activée au niveau administratif.
Affichez les adresses sous une forme compacte :
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 bouclage en détail :
ip address show dev lo
L’adresse IPv4 127.0.0.1/8 possède la portée scope host et n’est donc valide qu’à l’intérieur de cette machine. Recherchez 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"
ifconfig est un ancien outil d’interface qui apparaît encore dans les procédures et guides de dépannage existants. 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é succinct 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 serait utilisée pour atteindre une destination donnée.
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é réseau
Dans cette étape, vous utiliserez ping pour tester des limites réseau de plus en plus éloignées, tout en gardant à l’esprit que certains réseaux bloquent les paquets de diagnostic.
Commencez par le bouclage. Les options -c 2 envoient deux requêtes et -W 2 attend au maximum deux secondes chaque réponse :
ping -c 2 -W 2 127.0.0.1
Un test de bouclage 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 remplacement est important : 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 plutôt que de dépendre de politiques externes :
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ôte
Dans cette étape, vous examinerez la configuration du résolveur et traduirez des noms d’hôte en adresses.
Consultez 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 local intermédiaire plutôt qu’un serveur DNS externe directement.
Résolvez un nom local en utilisant l’ensemble de la configuration de résolution des noms du système :
getent hosts localhost
getent suit /etc/nsswitch.conf et peut donc combiner /etc/hosts, le DNS et d’autres sources configurées. Résolvez un nom externe et demandez les adresses de sockets IPv4 :
getent ahostsv4 example.com
Si le ping vers une adresse IP fonctionne 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 relierez un socket TCP en écoute au processus qui le possède, puis testerez le protocole applicatif.
Le service de démonstration préparé écoute sur le port de bouclage 8088. Utilisez ss pour examiner les sockets TCP en écoute. Les options -l, -t, -n et -p correspondent respectivement à l’écoute, à TCP, aux adresses numériques et aux informations sur les processus :
sudo ss -ltnp | grep ':8088'
Recherchez 127.0.0.1:8088. Une liaison sur l’interface de bouclage signifie que le service n’est accessible que depuis cette machine.
Vérifiez le processus 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 que la seule ouverture du port : l’application a accepté une requête HTTP et 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 allez examiner l’état d’UFW, préserver l’accès d’administration à distance, autoriser le port du service d’exercice et activer le pare-feu.
UFW est une interface pour les règles de filtrage de paquets Linux. Examinez son état actuel :
sudo ufw status verbose
La préparation laisse UFW inactif avec un jeu de règles propre. Avant d’activer à distance un pare-feu hôte, 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’exercice :
sudo ufw allow 8088/tcp
Examinez les changements préparés avant l’activation :
sudo ufw show added
Activez UFW sans demande de confirmation interactive :
sudo ufw --force enable
Confirmez que le pare-feu est actif et que les deux autorisations sont présentes :
sudo ufw status verbose
Le service est lié à l’interface de bouclage ; 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 est important : préservez le chemin d’administration, ajoutez les règles de service nécessaires, 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 le véritable chemin d’administration au lieu de supposer le 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 étape permet de mieux cibler l’analyse suivante.
Vous avez également examiné l’état d’UFW et géré sans risque une règle limitée au bouclage, sans compromettre l’accès distant. Ces méthodes vous aideront à diagnostiquer et à sécuriser un service réseau sans effectuer de modifications générales susceptibles de perturber le système.
