Pare-feu : diagnostic et règles réelles

Quand une connexion échoue, vérifier ce que le noyau applique réellement.

Couches à vérifier, dans l’ordre

Couche	Question	Commande
Service	Écoute-t-il, sur quelle adresse ?	`sudo ss -tlnp`
UFW	Une règle l’autorise-t-elle ?	`sudo ufw status verbose`
Fail2ban	L’adresse est-elle bannie ?	`sudo fail2ban-client status`
Noyau	Quelles règles sont actives ?	`sudo nft list ruleset`
Extérieur	Pare-feu de l’hébergeur, DNS ?	test depuis une autre machine

Ports en écoute

sudo ss -tlnp                         # TCP en écoute, avec processus
sudo ss -ulnp                         # UDP
sudo ss -tn state established

Adresse locale	Signification
`0.0.0.0:22`, `[::]:22`	Toutes les interfaces
`127.0.0.1:3000`	Local uniquement : jamais joignable de l’extérieur

Règles réelles

sudo nft list tables
sudo nft list table inet f2b-table      # règles de Fail2ban
sudo iptables -S ufw-user-input         # règles utilisateur d'UFW
sudo iptables -L -n -v --line-numbers   # avec compteurs
sudo ufw show raw

Avec iptables-nft, les règles d’UFW apparaissent aussi dans nft list ruleset, dans des chaînes nommées ufw-*. Les compteurs (-v) indiquent combien de paquets ont frappé chaque règle.

iptables-nft et iptables-legacy

iptables --version                                      # (nf_tables)
update-alternatives --query iptables | grep '^Value'    # /usr/sbin/iptables-nft

Les jeux de règles legacy et nft ne se voient pas : les mélanger crée des règles invisibles ou contradictoires. Rester sur iptables-nft.

Journaux de blocage

sudo ufw logging medium
sudo journalctl -k --since "10 minutes ago" | grep "UFW BLOCK"
sudo journalctl -k | grep "UFW BLOCK" | grep -oE "DPT=[0-9]+" | sort | uniq -c | sort -rn | head

La dernière commande classe les ports les plus visés ; remplacer DPT=[0-9]+ par SRC=[0-9a-f.:]+ pour les adresses les plus actives.

Tester la connectivité

Depuis le serveur :

curl -I http://127.0.0.1:3000
sudo tcpdump -ni eth0 'tcp port 443' -c 10

Depuis une autre machine :

nc -vz -w 3 serveur.exemple.com 443
nmap -Pn -p 22,80,443 serveur.exemple.com
mtr -rwc 20 serveur.exemple.com

Résultat	Interprétation
Connexion immédiate	Port ouvert, service actif
`Connection refused`	Le serveur répond, aucun service n’écoute (ou règle `reject`)
Délai dépassé	Paquets ignorés : pare-feu ou mauvaise adresse

Sauvegarder les règles

sudo cp -a /etc/ufw /root/ufw-sauvegarde
sudo nft list ruleset | sudo tee /root/nft-sauvegarde.txt >/dev/null

Les règles saisies à la main avec iptables ou nft ne survivent pas au redémarrage ; celles d’UFW, si.

Problèmes fréquents

Symptôme	Cause probable
Joignable en local, pas de l’extérieur	Pare-feu de l’hébergeur, UFW sans règle, service sur `127.0.0.1`
Port ouvert dans UFW mais délai dépassé	Pare-feu de l’hébergeur
Port « fermé » dans UFW qui répond	Conteneur Docker (voir UFW et Docker)
Seul IPv4 ou IPv6 fonctionne	Règles ou service sur une seule famille : `ss -tlnp`
Coupures par moments	Fail2ban ou `ufw limit`
Règles perdues au redémarrage	Règles manuelles non persistantes
Sorties bloquées	`ufw default allow outgoing`

Remise à zéro

Avec une session de secours :

sudo ufw --force reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Ubuntu 24.04 et 26.04 : différences à connaître

Mêmes commandes et même moteur (iptables-nft) sur les deux versions ; seule la version d’iptables change (1.8.10 puis 1.8.11).

Pour aller plus loin

Manuel : man nft, man ss
Suite : Exemple : VPS avec Caddy