UFW sans perdre l’accès SSH
La cible est la suivante : TCP 80 et 443 publics, SSH uniquement sur tailscale0, refus des connexions entrantes par défaut et autorisation des sorties. Gardez une session publique fiable et une session Tailscale vérifiée. Une connexion déjà établie peut survivre à la suppression d’une règle ; seule une nouvelle connexion prouve que la nouvelle politique fonctionne.
Inspectez l’état actuel sans réinitialiser le pare-feu :
sudo ufw status verbose
sudo ufw status numbered
Préparez ensuite les règles :
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp # temporary fallback
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow in on tailscale0 to any port 22 proto tcp
sudo ufw --force enable
sudo ufw status verbose
Ouvrez de nouvelles sessions SSH publique et Tailscale. Si les deux fonctionnent, inspectez une nouvelle fois les règles, puis supprimez la règle générique par sa signification :
sudo ufw delete allow 22/tcp
sudo ufw status numbered
Ne réutilisez pas un numéro enregistré auparavant : la numérotation change, et une suppression par numéro ne retire généralement que l’entrée IPv4 ou IPv6 correspondante.
# Must pass
ssh -o ConnectTimeout=10 "$VPS_USER@$TAILSCALE_IPV4"
# Must time out or be rejected
ssh -o ConnectionAttempts=1 -o ConnectTimeout=5 \
"$VPS_USER@$VPS_PUBLIC_IPV4"
Les ports de conteneurs publiés par Docker peuvent contourner les règles UFW ordinaires. Examinez les ports de Compose, les adresses d’écoute et docker ps, puis effectuez les contrôles adaptés au backend de pare-feu configuré dans Docker. DOCKER-USER s’applique au backend iptables ; le backend nftables natif de Docker ne possède pas de chaîne DOCKER-USER. Ne changez pas de backend et ne désactivez pas la gestion du pare-feu par Docker pour contourner le problème : ces deux actions peuvent casser le réseau ou modifier l’exposition des ports.
Si le transport SSH par Tailscale cesse de fonctionner après la suppression, gardez la session encore ouverte, restaurez sudo ufw allow 22/tcp, vérifiez une nouvelle connexion SSH publique par clé, rassemblez les diagnostics et arrêtez les modifications. Récupérer signifie rétablir un chemin vérifié, pas réinitialiser le pare-feu.