Règle d'écoute firewalld ou politique de transfert : ce que fait chacune

Un VPN qui se connecte mais n'atteint rien est généralement décrit comme un problème de pare-feu, et la solution vers laquelle on se tourne consiste à placer l'interface du tunnel dans une zone de confiance. Cela fonctionne au sens où le trafic commence à circuler, mais cela admet aussi bien plus que le service prévu. Les deux politiques en jeu sont différentes : l'une admet le transport externe vers une socket en écoute, et l'autre autorise le trafic déchiffré à atteindre une ressource précise. C'est les traiter comme un seul réglage qui transforme une autorisation étroite en autorisation large. Les deux se décident à des endroits différents, et c'est pourquoi l'erreur est si facile à commettre.

Deux politiques, un tunnel

La politique externe répond à une question simple : un paquet de cette source peut-il atteindre l'UDP 1194 sur cet hôte ? La politique interne répond à une autre : le client authentifié derrière ce tunnel peut-il atteindre cette destination, avec ce protocole, sur ce port ? La première concerne une socket, la seconde un chemin, et firewalld les modélise avec des objets différents parce qu'elles se décident à des points différents. L'une est une propriété d'une socket sur cet hôte, l'autre d'un chemin qui le traverse.

La conséquence pratique est qu'un tunnel qui fonctionne ne dit rien de la seconde politique, et qu'une seconde politique correcte ne rend pas la première inutile.

Admettez l'écoute externe réelle

Commencez par examiner ce qui est déjà attribué plutôt que de le supposer. Lisez les zones actives, listez la zone qui porte réellement l'entrée, et vérifiez la définition de service installée, car un nom de service décrit un ensemble de ports et ne dit rien sur le fait que l'écoute de ce serveur y corresponde.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Si l'écoute est réellement l'UDP 1194 sur cette zone, ouvrez précisément ce port et ce transport, puis rendez la même règle précise persistante après l'avoir testée. Vérifiez aussi les affectations par source, car une zone liée à une plage de sources peut capter le trafic avant même que la zone de l'interface ne le voie.

Autorisez la destination déchiffrée séparément

Une connexion à un service exécuté sur le serveur VPN lui-même relève d'une politique d'entrée locale. Une connexion transférée vers un autre hôte du LAN nécessite une politique de transfert, le transfert activé dans le noyau et une route de retour — trois exigences distinctes que les gens regroupent souvent en une seule. Les objets de politique modernes de firewalld décrivent le trafic dirigé entre une zone d'entrée et une zone de sortie, et c'est le bon endroit pour exprimer quelles sources VPN peuvent atteindre quels services privés.

Définissez explicitement les sources autorisées et laissez tout le reste tomber dans un refus. Une autorisation pour le service externe n'est pas cette politique, quelle que soit l'apparence de la disposition des zones.

Pourquoi faire confiance à l'interface est le mauvais raccourci

Placer l'interface du tunnel dans une zone dont la cible accepte tout laisse passer tout le trafic déchiffré vers chaque service exposé par l'hôte, y compris ceux que vous n'avez pas examinés. Recibler la zone de confiance pour la rendre restrictive sur une machine en production est pire, car d'autres interfaces et plages de sources peuvent déjà dépendre de sa signification et changeront de comportement quand vous la modifierez. Si vous avez besoin d'une politique étroite, créez-en une ; ne réaffectez pas une zone partagée.

Maintenez aussi stable l'affectation de zone du tunnel à travers le composant qui détient cette configuration. Perdre l'affectation au redémarrage produit une panne qui ressemble à un problème de règle de pare-feu et qui est en réalité un problème de persistance.

Vérifiez trois choses, dont un refus

Testez la connexion externe depuis l'extérieur, testez un service interne autorisé depuis un client connecté, et testez un service qui devrait rester injoignable. Le troisième test est celui qui distingue une politique d'un effet de bord, et c'est celui que les gens sautent parce que tout semble fonctionner. Si le service refusé répond, vous avez admis une zone plutôt qu'un service.

Notez la zone, le port, le transport et l'objet de politique dans les notes du serveur. Sinon, le prochain changement sur cet hôte repartira de la même supposition.