RousselTMLEARNING

Article · Linux administration: from discovery to expertise

Networking, firewall and SSH

This article is available in French.

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

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

My progress

  • ⏱ Estimated time : ≈ 13 min

Sign in to track your progress and take notes. Sign in

✉️ Ask a question

Recommended Articles

Package managers

The different package managers for Kubernetes and their advantages.