Le coupe-circuit d'UFW bloque votre VPN ? Autorisez le pair

Vous avez suivi la liste de contrôle : refuser la sortie, autoriser le tunnel, activer ufw. Ensuite le client attend à la poignée de main et ne se connecte jamais, ou il se connecte et aucune page ne se charge. Les deux échecs viennent du même manque. La règle qui permet au tunnel d'exister manque, parce que le tunnel n'est pas une interface par laquelle vos paquets sortent.

Pourquoi une autorisation sur tun0 ne correspond à rien au début

tun0 est créé par le client une fois qu'une session existe. Les datagrammes qui construisent cette session sont de simples paquets UDP adressés au fournisseur sur le port 1194, et ils sortent par wlan0 ou eth0 avec l'adresse source physique. allow out on tun0 ne correspond qu'au trafic dont l'interface de sortie est tun0, donc pendant la poignée de main il ne correspond à rien du tout.

Posez default deny outgoing par-dessus et les paquets extérieurs sont supprimés avant même que l'interface apparaisse. Le client réessaie, expire et signale un échec TLS ou de poignée de main, ce qui envoie les gens fouiller dans les certificats et le MTU pendant que le pare-feu mange la connexion en silence. La règle censée contenir votre trafic empêche ce trafic d'être contenu.

Le correctif réflexe rend la fuite permanente. sudo ufw allow out on wlan0, ou repasser la valeur par défaut sur autoriser, monte le tunnel et laisse la machine sans coupe-circuit : la prochaine fois que le tunnel tombe, tout reprend par l'adaptateur physique. J'ai perdu un après-midi exactement sur cette paire de modifications avant de comprendre quel paquet je filtrais réellement.

Ce dont les deux ensembles de paquets ont besoin

Votre trafic traverse le pare-feu deux fois, sous deux formes. Le paquet intérieur part de l'adresse du tunnel vers l'extérieur par tun0. Le paquet extérieur part de l'adresse physique vers le pair, et c'est la seule chose visible sur le fil. Une règle par forme :

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Remplacez l'adresse et le port par ceux de votre propre profil. Les pairs WireGuard répondent généralement sur 51820/udp ; les profils OpenVPN qui passent par TCP 443 ont besoin de ce port à la place. Les détails diffèrent, la forme non : les deux règles sont étroites et ensemble elles définissent les seules destinations que la machine peut atteindre tant que le tunnel est en panne.

L'ordre est le deuxième mythe. Avec iptables brut, on lit la chaîne de haut en bas et on raisonne sur la règle qui gagne. ufw n'est pas un mince emballage autour de la liste que vous avez tapée ; il compile vos règles dans ses propres chaînes et choisit les points d'insertion. ufw status les affiche dans l'ordre d'ufw, pas le vôtre. Quand une règle semble ignorée, comparez ufw show added à l'ensemble compilé depuis iptables -S | grep ufw avant de réécrire quoi que ce soit.

L'exception doit rester large d'une seule adresse

Une règle de pair n'est correcte que tant qu'elle nomme l'adresse que le client compose. Les fournisseurs font tourner les points de terminaison, et un profil qui résout un nom d'hôte suivra un changement DNS vers une nouvelle adresse tandis que la règle continue de pointer vers l'ancienne. Quand un tunnel qui marchait depuis des mois cesse de monter, comparez l'adresse de la règle avec celle que le client cherche avant d'élargir quoi que ce soit.

Élargir à tout un sous-réseau, ou à chaque destination sur le port 1194, retransforme la politique en pare-feu troué. L'exception, c'est le coupe-circuit ; une fois qu'elle est large, il ne reste plus rien à couper. Gardez-la sur une seule adresse et laissez un commentaire nommant le profil et le fournisseur auxquels elle appartient, car dans six mois l'adresse paraîtra arbitraire.

La résolution de noms mérite sa propre ligne. La recherche a lieu avant que le tunnel existe, via l'interface physique, donc une politique stricte de refus de sortie peut laisser le client incapable de trouver son propre serveur. Autorisez le port 53 vers l'adresse de votre résolveur, ou résolvez une fois et fixez l'adresse dans le profil. Autoriser DNS sur toutes les interfaces est une décision, pas un défaut.

Construisez la politique avant que le tunnel soit nécessaire

ufw enable applique toute la politique d'un coup et recharge ses chaînes, et changer une politique par défaut sur un pare-feu en marche les recharge aussi. Le manuel d'ufw avertit que cela peut couper des connexions existantes comme SSH. Les commandes vont donc dans cet ordre, avec la règle SSH avant l'activation et une session console ouverte :

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset est volontairement laissé hors de ce bloc. Il supprime toutes les règles et désactive le pare-feu, et sur un hôte distant l'activation suivante est ce qui coupe votre session. Si vous réinitialisez quand même, ajoutez la règle SSH et confirmez un second chemin de retour par console avant d'aller plus loin.

L'enchaînement n'est pas cosmétique. Les règles ajoutées pendant qu'ufw tourne ne vident rien, mais au moment où vous basculez une politique par défaut les chaînes se rechargent, et une session que l'ancienne politique autorisait part avec elles. Faites les défauts, les autorisations et l'activation en une seule passe, tant que vous avez encore un chemin d'entrée qui ne dépend pas de la machine.

Testez l'état bloqué, et gardez l'annulation

Un coupe-circuit non testé est une supposition. Déconnectez le client exprès et essayez de charger une page : cela doit échouer. Reconnectez et il doit se rétablir sans toucher à une règle. sudo ufw status verbose confirme les défauts et l'état de journalisation, et ufw status numbered montre quelle règle de test supprimer quand elle survit à son objectif.

Gardez le script inverse à côté du script direct. Une machine avec refus de sortie et un tunnel mort ne peut pas télécharger sa propre réparation, donc l'annulation doit être sur le disque et lisible depuis une console :

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Exécutez-le quand le tunnel est déjà tombé et que les règles doivent partir, pas comme une étape de routine. Avant de fermer le terminal, quatre choses doivent tenir : la règle de pair nomme exactement une adresse, le DNS a une exception nommée, l'activation est venue après les autorisations, et tirer le tunnel tue le trafic ordinaire sans tuer le client pour de bon.