Bloquer un client OpenVPN du LAN sans arrêter le tunnel

Un client de votre serveur OpenVPN doit perdre l'accès au LAN pendant que tous les autres tunnels restent actifs. Si vous cherchez cela, la meilleure réponse dit souvent que le démon ne peut pas le faire, ce qui n'est qu'à moitié vrai : OpenVPN n'a pas de pare-feu par client, mais l'hôte qui termine le tunnel filtre déjà les paquets. Les deux décisions qui comptent sont l'identité que vous bloquez et la position de la règle. Réussissez ces deux points et le changement devient une ligne que vous pouvez tester et retirer.

Épinglez le client avant d'écrire la règle

OpenVPN loue des adresses de tunnel dans un pool, donc 10.8.0.6 est un siège, pas une personne. Quand la session se termine, le bail revient et peut être donné à la connexion suivante, ce qui signifie qu'une règle écrite contre cette adresse suit le siège, pas l'utilisateur. Décidez donc d'abord ce que vous bloquez vraiment : une adresse pour une expérience courte, ou un certificat pour quelqu'un que vous voulez tenir dehors.

Pour lier l'adresse au certificat, créez un fichier dans le répertoire indiqué par client-config-dir et donnez au fichier exactement le common name du certificat. Mettez-y une directive, ifconfig-push 10.8.0.6 255.255.255.0, et ce client garde la même adresse de tunnel d'une reconnexion à l'autre. Deux réglages doivent exister pour que cela prenne effet : client-config-dir doit être déclaré dans la configuration du serveur, et l'adresse poussée doit se trouver dans un sous-réseau que le serveur peut router. Si l'un manque, le fichier est ignoré sans erreur, ce qui rend le prochain test de pare-feu trompeur.

Un blocage temporaire peut utiliser une adresse du pool, tant que le ticket note quelle session la détenait à ce moment-là.

L'ordre décide si le rejet s'exécute

Sur une passerelle Linux qui transfère entre le tunnel et le LAN, les paquets traversent la chaîne FORWARD. Lisez la commande ci-dessous comme une phrase : insérer en tête de FORWARD, faire correspondre le trafic entrant depuis tun0, de cet hôte unique, adressé au sous-réseau du LAN, et le rejeter.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

Le -I est ce qui fait tourner la règle. Ajoutée avec -A, elle atterrit sous toute acceptation large pour le sous-réseau du tunnel et ne voit jamais un paquet. Vérifiez la position avec iptables -vnL FORWARD --line-numbers, et lisez aussi les compteurs : un rejet en haut qui ne compte rien signifie que le trafic arrive par un autre chemin.

L'adresse LAN de la passerelle elle-même est un autre chemin. Les paquets envoyés à la machine vont vers INPUT, pas FORWARD, donc un client peut perdre un hôte du LAN et ouvrir quand même la page d'administration du routeur. Ajoutez la règle INPUT correspondante quand cela compte.

Ce que le filtre ne peut pas voir

Le filtrage a lieu lors de l'évaluation d'un paquet, donc une session TCP établie peut continuer jusqu'à sa fermeture ou sa réinitialisation. Si le blocage doit mordre immédiatement, videz les flux suivis de cette source avec conntrack -D -s 10.8.0.6 après avoir posé la règle. Si quelques secondes de chevauchement sont acceptables, consignez ce choix au lieu de le laisser implicite. Dans tous les cas, la personne suivante doit savoir si la règle arrête le trafic en cours ou seulement les nouvelles connexions.

Le trafic entre pairs ne touche jamais le pare-feu de l'hôte. Avec client-to-client activé, OpenVPN transmet ces paquets à l'intérieur du démon, donc ni FORWARD ni INPUT ne les voient. Les seules solutions sont de désactiver client-to-client ou d'accepter que les pairs puissent s'atteindre ; une règle iptables ne verra pas ce trafic.

IPv6, micrologiciel et survie au redémarrage

Une règle IPv4 ne dit rien d'IPv6. Si le tunnel et le LAN portent les deux familles, la règle équivalente doit exister dans ip6tables, ou dans le jeu de règles nftables qui possède la politique sur cet hôte. Le micrologiciel du routeur cache souvent netfilter derrière sa propre abstraction, donc la syntaxe et les noms de tables copiés d'un forum peuvent ne pas s'appliquer.

Sur OpenWrt, le chemin documenté est une entrée de configuration du pare-feu et non une ligne iptables écrite à la main, et une ligne écrite à la main peut disparaître quand le pare-feu se recharge. D'autres distributions restaurent les règles via netfilter-persistent, une unité de démarrage ou un magasin du fournisseur, et ces mécanismes ne sont pas interchangeables. Prouvez celui que vous avez choisi par un redémarrage, car un rechargement exerce un autre chemin.

Vérifiez par chemin, puis revenez proprement en arrière

Testez chaque chemin séparément, car une vérification réussie masque les autres. Un client bloqué doit encore joindre internet par le tunnel tout en échouant contre un hôte du LAN, un second client doit joindre ce même hôte, et l'adresse de la passerelle et le chemin entre pairs demandent chacun leur propre observation. Écrivez les résultats à côté de la règle pour que le changement suivant ait une base. Le tableau ci-dessous est l'ensemble qui vaut la peine de rester dans le ticket.

Le retour en arrière est une suppression par spécification, pas un flush : iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP retire exactement cette entrée et laisse le reste de la chaîne intact. Retirez la même ligne du fichier qui restaure les règles au démarrage, rechargez-le et confirmez que le client joint de nouveau l'hôte du LAN. Un flush de FORWARD annulerait aussi des règles que vous n'avez pas écrites, ce qui transforme un retour en arrière en second incident.

Avant de fermer le ticket, confirmez trois choses : l'adresse épinglée correspond au certificat, la règle se trouve au-dessus des acceptations avec un compteur non nul, et le fichier de persistance contient la même règle que celle testée. S'il en manque une, le blocage est une illusion de session shell.