RousselTMLEARNING

Systèmes & Linux

Réseau sous Linux : configuration, diagnostic, pare-feu et SSH

Configurer et dépanner le réseau Linux : ip, ss, netplan et NetworkManager, DNS, diagnostic par couches avec ping, dig, curl, tcpdump, pare-feu nftables, ufw et firewalld, et SSH (clés, configuration, tunnels).

1. Configuration #

Interfaces, adresses et routes.

Lire l'état #

Couches réseau et commandes
Un ping qui passe valide la couche réseau, pas le port ni l'application.
ip -br addr               # interfaces et adresses, format court
ip link                   # état des liens (UP/DOWN), MAC
ip route                  # table de routage, passerelle par défaut
ip -s link show eth0      # compteurs, erreurs
hostname -I
resolvectl status         # serveurs DNS utilisés (systemd-resolved)
cat /etc/hosts /etc/resolv.conf

Configurer de façon persistante #

Les commandes ip modifient la configuration en mémoire uniquement. La configuration permanente dépend de la distribution : netplan (Ubuntu), NetworkManager (RHEL, postes), /etc/network/interfaces (Debian classique).

# /etc/netplan/50-static.yaml (Ubuntu)
network:
  version: 2
  ethernets:
    eth0:
      addresses: [192.168.10.20/24]
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses: [192.168.10.1, 1.1.1.1]
sudo netplan try          # applique avec retour arrière automatique après 120 s sans confirmation
nmcli con show            # NetworkManager
sudo nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.20/24 ipv4.gateway 192.168.10.1 ipv4.dns 1.1.1.1
sudo nmcli con up eth0
sudo hostnamectl set-hostname app01
Bonne Pratique : À distance, préférez netplan try ou gardez une console hors bande (iLO, console du cloud) : une erreur réseau coupe votre propre session SSH.

2. Diagnostiquer #

Une méthode par couches.

La méthode #

Méthode de diagnostic réseau
On remonte les couches et on s'arrête à la première qui échoue.

Les outils #

ping -c 3 192.168.10.1            # joignabilité
tracepath 8.8.8.8 ; mtr -rw example.com   # chemin et pertes
dig +short example.com ; dig @1.1.1.1 example.com MX
getent hosts api.interne           # résolution comme le fait le système (inclut /etc/hosts)
ss -tlnp                           # ports TCP en écoute et processus
ss -tnp state established          # connexions établies
nc -zv db.interne 5432             # le port distant est-il ouvert ?
curl -v https://api.interne/health # TLS, en-têtes, code HTTP
curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{http_code}\n' https://example.com
sudo tcpdump -i eth0 -nn port 53   # capturer le trafic DNS
sudo tcpdump -i any -w capture.pcap host 10.0.0.5   # pour Wireshark

Lire ss -tlnp #

0.0.0.0:8080 ou *:8080 : écoute sur toutes les interfaces. 127.0.0.1:8080 : uniquement en local, invisible depuis le réseau — cause fréquente du « ça marche sur le serveur mais pas depuis mon poste ».

3. Pare-feu #

Tout refuser, puis ouvrir le nécessaire.

ufw et firewalld #

# Ubuntu : ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow from 10.0.0.0/8 to any port 5432 proto tcp
sudo ufw enable && sudo ufw status numbered

# RHEL : firewalld
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 port port=5432 protocol=tcp accept'
sudo firewall-cmd --reload && sudo firewall-cmd --list-all
Erreur Courante : Autorisez SSH avant d'activer le pare-feu, sinon vous vous enfermez dehors.

nftables #

Évaluation des règles nftables
Accepter les connexions établies en premier évite de bloquer les réponses.

ufw et firewalld sont des surcouches de nftables, le pare-feu du noyau (successeur d'iptables).

# /etc/nftables.conf
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport { 22, 443 } accept
    icmp type echo-request limit rate 5/second accept
  }
}
sudo nft -c -f /etc/nftables.conf && sudo nft -f /etc/nftables.conf   # vérifier puis charger
sudo nft list ruleset

4. SSH #

Administrer à distance en sécurité.

Clés #

Connexion SSH par clé et bastion
La clé privée ne quitte jamais le poste de l'administrateur.
ssh-keygen -t ed25519 -C "alice@poste"     # paire de clés (avec phrase de passe)
ssh-copy-id alice@app01                     # installer la clé publique
ssh-add ~/.ssh/id_ed25519                   # agent : saisir la phrase une fois
chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys

Configuration cliente #

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
Host app*
    User alice
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Copier et tunnels #

Tunnel SSH local
psql -h localhost -p 5433 sur le poste atteint la base distante.
scp fichier app01:/tmp/ ; rsync -avz --progress dossier/ app01:/srv/dossier/
ssh -L 5433:localhost:5432 app01   # tunnel : la base distante devient localhost:5433
ssh -D 1080 bastion                # proxy SOCKS
ssh app01 'df -h /'                # commande ponctuelle

Articles liés

Architecture d'un système Linux : noyau, démarrage et arborescence

Comprendre comment fonctionne un serveur Linux : noyau et espace utilisateur, séquence de démarrage UEFI, GRU…

Le shell Bash et les fichiers : navigation, redirections, pipes et traitement de texte

Maîtriser la ligne de commande Linux : chemins, manipulation de fichiers, jokers, redirections, pipes, recher…

Utilisateurs, groupes, sudo et permissions sous Linux

Gérer les comptes Linux (useradd, usermod, passwd, chage), les groupes, sudo et visudo, les permissions rwx e…

Pour aller plus loin