Pourquoi une règle de blocage de client OpenVPN n'atteint jamais FORWARD

Deux clients sur le même serveur OpenVPN peuvent s'atteindre alors même que vous avez ajouté une règle DROP pour leur pool. La règle se trouve dans la chaîne FORWARD, le trafic circule manifestement, et le compteur de cette règle reste à zéro. La conclusion naturelle est que le pare-feu est cassé. Le plus souvent, le paquet n'est jamais entré dans la chaîne du tout.

Il existe deux chemins qu'un paquet de pair peut emprunter à travers un serveur OpenVPN, et ils sont décidés par la configuration, non par le pare-feu. Savoir quel chemin est utilisé vous dit si une règle de l'hôte est seulement au bon endroit.

Deux chemins qu'un paquet de pair peut emprunter

Lorsque l'option de transfert interne est désactivée, un paquet du client A arrive sur l'interface du tunnel avec une destination à l'intérieur de l'adresse attribuée au client B. La table de routage du serveur le renvoie par la même interface de tunnel, parce que le serveur possède la route vers l'adresse de B. C'est un flux d'entrée et de sortie à travers l'hôte, et le chemin de transfert IPv4 l'évalue.

Lorsque l'option de transfert interne est activée, le processus du serveur associe le paquet à un client connecté et le réécrit vers ce client lui-même. Le paquet est traité à l'intérieur du démon et ne rentre jamais dans le périphérique de tunnel, donc le chemin de transfert de l'hôte est entièrement contourné. Le manuel d'OpenVPN 2.6 décrit cette option comme un transfert interne de client à client, et c'est exactement pourquoi une règle de pare-feu de l'hôte ne peut pas la voir.

Une troisième variante existe dans les déploiements qui déchargent le canal de données vers un module du noyau. La décision de transfert et le chiffrement quittent l'espace utilisateur, et le fait que netfilter observe le flux dépend de la façon dont le chemin de déchargement est construit. Ne supposez jamais qu'un ancien jeu de règles se comporte sur un serveur déchargé comme sur un serveur en espace utilisateur. Confirmez le mode à partir de la configuration en cours, pas de la version du paquet.

Quand le compteur ne bouge jamais

Un compteur à zéro signifie que le paquet n'a pas correspondu à cette règle à cet endroit, et les raisons sont multiples. La première est le contournement ci-dessus : le trafic n'a jamais atteint la chaîne. La seconde est une inadéquation d'interface, de direction, de source ou de destination, ce qui est courant lorsque le pool a été renuméroté et que la règle nomme encore l'ancien préfixe.

La troisième est la position. Une règle plus haut dans la chaîne peut accepter le flux avant que votre DROP soit évalué, et une règle plus bas peut être celle qui décide réellement du résultat. Lisez la chaîne dans l'ordre avec les compteurs visibles, puis vérifiez quel compteur augmente lorsque vous répétez le test.

Effectuez un échange contrôlé entre deux clients dont vous avez confirmé les adresses réelles à partir de l'état du serveur lui-même, et non d'un bail dont vous vous souvenez. Si le compteur concerné ne bouge toujours pas, soupçonnez le chemin avant de réécrire la correspondance. S'il bouge mais que la connexion réussit encore, la chute est écrasée plus loin et c'est l'ordre qui pose problème. Cette réponse décide si la réparation est un changement de règle ou un changement de topologie, alors obtenez-la avant de modifier quoi que ce soit.

Choisir une frontière qui peut filtrer

Si la politique doit vivre dans le pare-feu de l'hôte, placez le trafic là où le pare-feu peut le voir. Désactiver le transfert interne est la façon prise en charge de faire traverser le trafic de pair par l'interface du tunnel et par le chemin de transfert, au prix de faire passer chaque paquet de pair par la pile de l'hôte.

Faites ensuite correspondre le flux avec précision. Le trafic arrive sur l'interface du tunnel et en repart, dans les deux sens, donc les règles qui ne considèrent que l'interface physique ne correspondront pas. Les règles basées sur les adresses ont besoin du pool actuel, et elles doivent tenir compte du sens retour autant que du sens aller.

De nombreux déploiements sont mieux servis par un filtrage au niveau du client ou du groupe, où l'identité est connue et où la politique suit l'utilisateur plutôt qu'une adresse qui change à la reconnexion. C'est un mécanisme différent d'une chaîne de l'hôte, et les deux ne devraient pas être mélangés sans raison claire.

Ne transportez pas tel quel le jeu de règles d'une ancienne topologie lors d'une migration. Les pools d'adresses, les noms d'interface et les modes de transfert influent tous sur la correspondance d'une règle, et une règle copiée qui fonctionnait auparavant est le type de preuve le plus trompeur. Partez du flux que vous voulez autoriser et écrivez la règle qui y correspond.

Tester l'isolation au lieu de faire confiance à une règle

Testez le cas interdit et le cas autorisé dans la même exécution. Lancez une nouvelle connexion d'un client vers l'autre et confirmez qu'elle échoue, puis confirmez qu'une connexion qui devrait être autorisée fonctionne toujours. Si seul le premier est testé, un pare-feu qui bloque tout ressemble à un succès.

Répétez après avoir rechargé la configuration du serveur et après la reconnexion d'un client, car le transfert interne et les attributions de pool sont un état d'exécution. Vérifiez les compteurs dans les deux sens, car une règle qui correspond dans un sens et pas à la réponse produit une isolation partielle difficile à remarquer dans un test rapide.

L'isolation est le résultat observé à la frontière qui transporte réellement le flux. Une règle DROP quelque part dans l'hôte n'est pas une preuve ; une connexion échouée plus un compteur déplacé sur la règle qui l'a causée en est une.