iptables : laisser les clients VPN atteindre un seul hôte

Deux tickets de support qui semblent sans rapport finissent par partager une même cause. Dans le premier, un administrateur veut que le serveur n’accepte que les connexions venant du tunnel ; dans le second, les utilisateurs VPN doivent atteindre un seul hôte interne et rien de plus. Les deux politiques relèvent de FORWARD, et les deux sont généralement tentées dans INPUT. Le résultat ressemble à un pare-feu et se comporte comme un espace réservé.

Quelle chaîne répond à votre question

Les paquets qu’un client VPN envoie vers un hôte du LAN, ou plus loin vers Internet, sont réacheminés par le noyau et évalués dans FORWARD. INPUT et OUTPUT ne voient que le trafic qui se termine sur le serveur lui-même ou qui en provient. Un rejet pour tout ce qui n’arrive pas par tun0 protège donc les propres écouteurs du serveur, et il mettra aussi fin à votre session SSH si les flux établis ne sont pas admis d’abord. Cela ne change rien à l’endroit où les clients sont autorisés à aller.

Nommez d’abord la question : qui peut atteindre le serveur, ou où les clients peuvent-ils aller. La plupart des réseaux ont besoin des deux réponses, dans des chaînes différentes.

D’abord l’état, puis l’autorisation, puis le refus

Une liste d’autorisation ne fonctionne que si l’autorisation précise se trouve au-dessus du refus général et si le trafic de retour est admis au-dessus des deux. Insérez les règles à des positions explicites, puis affichez la chaîne avec iptables -S FORWARD pour que l’ordre soit visible plutôt que supposé.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Deux détails décident si cela survit au contact du trafic réel. Sans la règle d’état, les réponses aux connexions que vous venez d’autoriser sont elles-mêmes évaluées contre le refus et supprimées. Une règle LOG sans limite peut saturer une petite partition dès la première analyse qui la touche, alors ajoutez -m limit --limit 10/min avant de continuer à journaliser. REJECT renvoie une erreur immédiatement, ce qui est plus agréable pendant le réglage de la liste ; DROP écarte en silence, si bien que chaque erreur se présente comme un délai dépassé. Choisissez-en un délibérément et consignez ce choix dans le journal des changements.

Le réacheminement et le NAT doivent déjà fonctionner

Le filtrage ne peut pas prouver qu’un chemin existe. Confirmez d’abord que le noyau réachemine tout court, et rendez ce réglage permanent plutôt qu’une commande ponctuelle du shell. Le filtre est la dernière couche, pas la première.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

L’emplacement du masquerading dépend de l’endroit où les clients sortent. S’ils partent vers un réseau distant par le tunnel, la règle NAT va sur cette interface plutôt que sur l’interface WAN. Regardez ensuite les compteurs : si le compteur de POSTROUTING ne bouge jamais alors que le nombre d’acceptations dans FORWARD augmente, le chemin de retour est cassé et le filtre est correct. Cette lecture épargne un après-midi à réécrire des règles qui n’ont jamais été le problème.

Le blocage du courrier appartient à la chaîne d’à côté

Bloquer le port 25 dans INPUT n’arrête que le courrier adressé au serveur VPN. Un client compromis qui envoie du courrier par le tunnel est réacheminé, donc le blocage doit se trouver dans FORWARD à côté de 465 et 587. Si une application relaie légitimement du courrier, placez sa destination et son port au-dessus de cette règle.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Laissez tourner le compteur de rejets une semaine avant de resserrer quoi que ce soit d’autre. Le nombre qui cesse de grimper est le flux légitime que vous venez de casser.

Relisez-le, puis prouvez-le depuis un client

Lisez le jeu de règles tel que le noyau le rapporte, pas tel que votre script l’a écrit. Commencez par iptables -S FORWARD, puis la table NAT avec iptables -t nat -L POSTROUTING -n -v, puis l’entrée conntrack du flux que vous testez. Gardez une commande de retour arrière ou un vidage planifié tant que le travail dure. Chaque appel a besoin de -w, sinon deux administrateurs se heurteront au verrou xtables. Rien de tout cela n’est facultatif pendant une fenêtre de changement.

Terminez en testant depuis un client à l’intérieur du pool et depuis un autre à l’extérieur. Une règle qui ne fonctionne que depuis la machine où vous l’avez tapée n’est pas une politique.