SysMentor

J'utilise la connectivité réseau de mon serveur

Vous êtes détaché par l'ESN Green Data sur le salon TechByte. Un exposant vous signale que son application d'intelligence artificielle « ne répond plus ». Avant de soupçonner l'application elle-même, vous devez répondre à une question plus élémentaire : le serveur est-il seulement joignable ? Un service parfaitement démarré sur une machine dont l'interface réseau est tombée produit exactement le même symptôme qu'une application plantée. Ce chapitre vous apprend à trancher.

Le modèle mental : quatre couches à vérifier dans l'ordre

Un diagnostic réseau efficace se fait de bas en haut. À chaque étage, une commande, et une seule question à laquelle répondre par oui ou non.

Étage	Question	Commande de référence
Interface	La carte réseau est-elle active et adressée ?	`ip addr show`
Routage	Le serveur sait-il sortir de son réseau local ?	`ip route show`
Résolution	Les noms se traduisent-ils en adresses ?	`dig`, `host`, `resolvectl status`
Service	Le port applicatif est-il en écoute ?	`ss -tulpn`

Ne sautez jamais d'étage. Beaucoup de temps est perdu à débattre d'un problème DNS alors que l'interface est simplement DOWN.

Je consulte l'état des interfaces

La suite iproute2 a remplacé les anciens outils ifconfig, route et netstat, qui ne sont plus installés par défaut sur une Debian ou une Ubuntu récente. Prenez dès maintenant l'habitude de la syntaxe moderne.

ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    inet 127.0.0.1/8 scope host lo
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default
    link/ether 92:1a:4f:0c:33:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.24/24 brd 192.168.10.255 scope global ens18

Trois informations comptent ici :

state UP : l'interface est administrativement active. Un state DOWN se corrige par ip link set ens18 up.
LOWER_UP : le lien physique est établi (câble branché, lien virtuel présent). UP sans LOWER_UP signale un problème de câblage ou de commutateur — sur un salon, c'est un incident fréquent.
inet 192.168.10.24/24 : l'adresse IPv4 et son masque en notation CIDR. Le /24 signifie que les 24 premiers bits identifient le réseau ; les hôtes joignables directement vont donc de 192.168.10.1 à 192.168.10.254.

Les commandes courtes ip a et ip r sont acceptées et vous feront gagner du temps en intervention.

Je vérifie et je corrige le routage

ip route show

default via 192.168.10.1 dev ens18 proto static metric 100
192.168.10.0/24 dev ens18 proto kernel scope link src 192.168.10.24

La ligne default via est la passerelle par défaut : tout paquet dont la destination n'appartient à aucune route plus précise lui est confié. Son absence est un diagnostic à elle seule — le serveur parle à son réseau local mais reste muet vers l'extérieur.

Pour ajouter à chaud une adresse ou une route :

sudo ip addr add 192.168.10.24/24 dev ens18
sudo ip route add default via 192.168.10.1
sudo ip link set ens18 up

⚠️ Ces modifications sont volatiles. Elles disparaissent au premier redémarrage. Elles servent à tester une hypothèse, jamais à corriger durablement. La correction définitive passe toujours par un fichier de configuration.

Je rends la configuration persistante

Selon la distribution et le rôle de la machine, trois mécanismes coexistent. Identifiez celui en place avant de modifier quoi que ce soit.

Debian avec ifupdown — `/etc/network/interfaces`

C'est la méthode historique, toujours celle d'une Debian installée sans environnement de bureau.

auto ens18
iface ens18 inet static
    address 192.168.10.24
    netmask 255.255.255.0
    gateway 192.168.10.1
    dns-nameservers 192.168.10.1 9.9.9.9

En DHCP, la déclaration se réduit à iface ens18 inet dhcp. On applique par sudo ifup ens18 / sudo ifdown ens18, ou en rechargeant le service networking.

Ubuntu Server — Netplan

Ubuntu décrit le réseau en YAML dans /etc/netplan/*.yaml, puis délègue le travail à systemd-networkd.

network:
  version: 2
  ethernets:
    ens18:
      addresses: [192.168.10.24/24]
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses: [192.168.10.1, 9.9.9.9]

Le YAML est sensible à l'indentation, qui se fait en espaces, jamais en tabulations. Validez avant d'appliquer :

sudo netplan try     # applique, puis annule seul après 120 s si vous ne confirmez pas
sudo netplan apply   # applique définitivement

netplan try est votre filet de sécurité en administration distante : une erreur d'adressage qui vous couperait votre propre session SSH est automatiquement annulée.

NetworkManager — `nmcli`

Présent sur les postes de travail et certaines images serveur, il se pilote en ligne de commande :

nmcli connection show
nmcli device status
sudo nmcli connection modify "Wired connection 1" ipv4.addresses 192.168.10.24/24 \
     ipv4.gateway 192.168.10.1 ipv4.dns "192.168.10.1" ipv4.method manual
sudo nmcli connection up "Wired connection 1"

Règle d'or : un seul gestionnaire à la fois. Configurer une interface dans /etc/network/interfaces alors que NetworkManager la pilote déjà produit des comportements erratiques, très coûteux à diagnostiquer.

Je teste la connectivité de proche en proche

Reprenons le serveur de l'exposant TechByte. Vous progressez par cercles concentriques :

ping -c 3 192.168.10.1        # la passerelle répond-elle ?
ping -c 3 9.9.9.9             # l'Internet est-il joignable par adresse IP ?
ping -c 3 www.debian.org      # et par nom ?

L'interprétation est mécanique :

Les deux premiers réussissent, le troisième échoue → le réseau fonctionne, le DNS est en cause.
Le premier réussit, le deuxième échoue → problème de passerelle, de routage ou de pare-feu en amont.
Le premier échoue → problème local : interface, adressage, ou VLAN du salon mal affecté.

traceroute (ou tracepath, qui ne demande pas de privilèges) affiche les routeurs traversés et révèle où le chemin s'interrompt :

tracepath 9.9.9.9

mtr combine les deux en une vue continue, précieuse pour objectiver une perte de paquets intermittente sur un réseau de salon.

Je diagnostique la résolution de noms

La résolution suit l'ordre défini dans /etc/nsswitch.conf (typiquement hosts: files dns) : le fichier /etc/hosts d'abord, les serveurs DNS ensuite.

dig www.exposant-techbyte.fr +short
host www.exposant-techbyte.fr
cat /etc/resolv.conf

Sur les systèmes utilisant systemd-resolved, /etc/resolv.conf est un lien symbolique vers un fichier généré : ne l'éditez pas à la main, vos modifications seraient écrasées. Interrogez plutôt l'état réel :

resolvectl status

Je vérifie que le service écoute vraiment

Dernier étage : le réseau est bon, mais l'application répond-elle sur son port ?

sudo ss -tulpn

Netid  State   Local Address:Port   Peer Address:Port  Process
tcp    LISTEN  0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=712,fd=3))
tcp    LISTEN  127.0.0.1:8080       0.0.0.0:*          users:(("python3",pid=1841,fd=6))

Les options se retiennent facilement : -t TCP, -u UDP, -l en écoute seulement, -p processus propriétaire, -n numéros de ports plutôt que noms.

Ici, l'application IA écoute sur 127.0.0.1:8080 : elle n'accepte que les connexions locales. Depuis un autre poste du salon, elle paraîtra injoignable alors que le service tourne. Pour être accessible sur le réseau, elle devrait écouter sur 0.0.0.0:8080 — c'est un défaut de configuration applicative, pas une panne réseau.

Si aucune ligne n'apparaît pour le port attendu, le réseau est hors de cause : le service n'est pas démarré. Vous savez désormais que le problème appartient au chapitre suivant, celui de SystemD.