Un pare-feu de distribution Linux peut bloquer votre trafic VPN

Le tunnel monte, le journal indique connecté, et une application n’atteint toujours rien. Sur un client Linux, cela signifie généralement qu’un pare-feu de la distribution filtre un chemin que le client VPN n’a jamais géré. Deux gestionnaires peuvent être actifs en même temps, chacun avec sa propre idée de l’interface, de la zone et du sens du trafic. Identifier le propriétaire avant toute modification est plus rapide que d’essayer des règles jusqu’à ce que quelque chose fonctionne.

Trouvez le gestionnaire et le backend

Commencez par ce qui est réellement chargé, et non par ce qui est installé. Une distribution peut fournir firewalld, ufw et un service nftables simple, et un seul d’entre eux possède le jeu de règles en cours. Les paquets coexistent paisiblement, et une règle saisie via le mauvais frontend n’atteint jamais le noyau. Lisez le service actif, puis lisez le jeu de règles qu’il a produit.

Le backend compte autant que le frontend. Une installation de firewalld peut piloter nftables ou l’ancien backend iptables selon la version et la configuration, et les deux produisent une sortie d’inspection différente. Inscrivez la distribution, la version et le backend dans le ticket avant de comparer votre système à n’importe quel guide.

Alignez la direction et l’interface

Une requête sortante du client, un écouteur entrant et un paquet transféré traversent des crochets différents, et une règle pour l’un ne couvre pas les autres. Une zone qui autorise le LAN local n’inclut souvent pas l’interface du tunnel ni le pool d’adresses VPN. Une interface de tunnel atterrit généralement dans la zone par défaut, qui est souvent plus stricte que la zone de l’adaptateur physique. Ce décalage explique pourquoi la navigation fonctionne sur le LAN et s’arrête à l’instant où le tunnel monte.

Demandez quelle direction a échoué avant de choisir une règle. Une application qui ne peut pas se connecter vers l’extérieur a besoin du chemin de sortie, tandis qu’un service entrant a besoin du chemin d’entrée sur l’interface du tunnel. Ajouter une règle à la mauvaise chaîne produit un changement qui semble appliqué et ne fait absolument rien.

Gardez les propriétaires de règles d’accord

Le crochet d’un client VPN, un environnement d’exécution de conteneurs et le service de la distribution peuvent tous modifier le réseau, et ils ne se coordonnent pas entre eux. Les règles saisies à la main disparaissent au prochain rechargement, et celles insérées dans la chaîne d’un gestionnaire peuvent être évaluées dans un ordre que vous n’aviez pas prévu. Utilisez la configuration persistante du gestionnaire et inspectez le jeu de règles obtenu plutôt que le fichier que vous avez écrit. Désactiver tout le pare-feu parce qu’un service est injoignable échange un petit problème contre un gros.

Les compteurs étroits sont le moyen le moins coûteux de trouver le flux rejeté. Une règle de journalisation limitée à une destination et un port montre si le rejet se produit localement sans capturer le trafic des autres. Supprimez la règle de journalisation à la fin de l’enquête, car c’est un diagnostic et non une politique, et la documentation des zones de firewalld explique comment les interfaces et les services se combinent.

Vérifiez la correction sans perdre le verrouillage

Inspectez l’état appliqué avec le gestionnaire qui le possède, en utilisant des commandes correspondant au backend que vous avez noté. La liste ci-dessous suppose que firewalld est aux commandes ; remplacez-la par l’équivalent pour nftables ou ufw au lieu de toutes les exécuter. Mélanger les outils dans une seule session, c’est ainsi qu’une machine finit avec deux jeux de règles contradictoires.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

La première commande nomme les zones et les interfaces qui leur sont attribuées, ce qui montre où le tunnel a réellement atterri. La seconde affiche les règles et services d’une zone, de sorte que vous voyez si l’interface VPN est couverte. La liste nftables est la vérité de base du backend utilisé, et une règle qui n’existe que dans un fichier de configuration n’y apparaît pas. Comparez les trois sorties avec la règle ajoutée, et l’écart se nomme généralement lui-même.

Répétez ensuite la requête d’origine et le comportement d’échec que vous exigez. Un site qui fonctionne à nouveau ne suffit pas si la même modification a supprimé le verrouillage du client, testez donc aussi un chemin non protégé. Notez le gestionnaire, le backend, l’interface et l’objet de la règle, car une mise à jour de paquet qui ressuscite un second gestionnaire reconstruira sinon tout le désordre.