Pourquoi nftables ne voit pas le trafic entre clients d'OpenVPN

Deux clients sur un même serveur échangent des fichiers, le transfert réussit, et chaque règle de transfert que vous pointez vers le tunnel rapporte zéro paquet. Les règles ne sont pas cassées et la chaîne n'est pas mal placée. Quand le transfert entre pairs est activé, le paquet est livré à l'intérieur du processus du serveur et la pile de l'hôte ne devient jamais le routeur, donc le pare-feu du noyau n'a rien à compter. Comprendre cette séparation décide si vous gardez le raccourci ou reconstruisez le chemin par le noyau.

Suivez un paquet à travers le serveur

Dans un tunnel routé, le démon remet le paquet déchiffré de chaque client à l'interface de tunnel. De là, l'hôte le route, le crochet de transfert s'exécute, et une règle qui correspond à l'interface de tunnel peut compter ou rejeter le trafic. C'est le chemin que supposent la plupart des exemples de pare-feu.

Le raccourci retire l'hôte du milieu. Le paquet déchiffré d'une session est remis à une autre session à l'intérieur du démon, et le paquet interne n'est jamais émis sur l'interface de tunnel ni routé par l'hôte. Le trafic encapsulé traverse toujours l'interface physique, donc une capture externe paraît active alors que les règles internes restent muettes. Une capture prise sur l'interface de tunnel ne montre absolument rien, ce qui surprend quiconque s'attend à y voir le transfert. Cette asymétrie est le moyen le plus rapide de reconnaître le raccourci depuis l'extérieur du démon.

Le test du compteur qui tranche quel chemin a été emprunté

Attachez un compteur à la règle qui devrait s'appliquer, lancez un transfert entre deux clients que cette règle devrait bloquer, puis lisez le compteur.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Si le transfert réussit et que le compteur reste à zéro, le noyau n'a jamais traité ces paquets, et aucune modification de règle n'y changera rien. Répétez le même test contre un service sur le serveur lui-même, car ce flux traverse bien la pile de l'hôte et son compteur bouge. C'est la comparaison des deux résultats qui donne la réponse.

Deux détails évitent une lecture fausse. Un nom d'interface écrit dans une étiquette de chaîne ne filtre rien en soi, car la correspondance se fait sur les champs d'interface à l'intérieur des règles. Et une conception pontée de couche 2 se comporte encore autrement : là, les clients partagent un domaine de diffusion, donc la découverte de pairs est attendue plutôt qu'un défaut de routage.

Un commutateur n'est pas une liste d'accès

C'est la partie qui coûte un après-midi. Le transfert entre pairs est un seul réglage activé ou désactivé, et tant qu'il est activé le démon est le seul point de transfert. Le pare-feu de l'hôte ne peut pas exprimer qui peut joindre qui, et des fichiers par client ne transforment pas le commutateur en matrice de politiques.

Si vous avez besoin de règles par pair, le choix est entre renoncer au raccourci et renoncer au pare-feu de l'hôte comme moyen de contrôle. Le désactiver rétablit le transfert par le noyau, ce qui exige le transfert IP sur le serveur et des règles explicites pour les flux voulus. Le laisser activé signifie que la politique vit dans la configuration du démon, ce qui en pratique revient à tous les pairs ou aucun.

Des processus serveur séparés avec leurs propres plages d'adresses et ports sont le juste milieu praticable. Chaque processus porte exactement une décision d'accès, donc deux groupes peuvent avoir des règles différentes sans matrice de politiques. L'hôte peut router entre les plages quand c'est voulu, et le pare-feu voit alors ces flux parce qu'ils traversent l'hôte. Le coût est celui de ports supplémentaires, de certificats supplémentaires et d'un profil par groupe.

Choisir le point de transfert

Choisissez le transfert par le noyau quand le pare-feu est le moteur de politique, quand vous avez besoin de journalisation par flux ou quand la comptabilité compte. Le coût est le débit à travers la pile de l'hôte et davantage de règles à maintenir. L'avantage est que chaque outil existant, des compteurs aux exportateurs de flux, décrit de nouveau le trafic. Sur un petit serveur ce coût est invisible ; sur un relais chargé il ne l'est pas.

Choisissez le transfert dans le processus quand le trafic entre pairs est soit entièrement autorisé, soit entièrement refusé et que le serveur est dimensionné pour cela. Le coût est que les compteurs, les disciplines de file et le suivi des connexions ne décrivent plus les flux internes ; ce n'est acceptable que si personne ne s'y fie ensuite.

Quel que soit votre choix, écrivez-le à côté des règles du pare-feu. Un jeu de règles qui semble autoriser le trafic entre pairs alors que le démon décide de toute façon trompe la personne suivante qui débogue un transfert échoué. Quiconque ne lit que les règles supposera que le noyau est la porte.

Ce qu'il faut vérifier avant de changer les règles

Lisez la configuration que le serveur a réellement chargée, pas le fichier dont vous vous souvenez l'avoir modifié, et confirmez si l'option de pairs est présente. Si vous l'avez changée, assurez-vous que le service a rechargé et n'a pas seulement réécrit un fichier sur le disque.

Répétez ensuite le test avec un flux de client à serveur pour prouver que la règle correspond au moins, et vérifiez les routes poussées, car une route manquante ressemble exactement à un blocage du pare-feu vu du client. Ne changez l'ordre des règles qu'une fois que vous savez quel point de transfert détient la décision.