Pare-feu VPS : n’ouvrez que le port VPN, puis prouvez-le

Un pare-feu qui n’admet que le port VPN n’est pas une règle. Ce sont trois décisions distinctes qui portent par hasard sur le même numéro de port : la chaîne d’entrée décide de ce qui peut atteindre un processus local, la chaîne de transfert décide de ce qui peut traverser l’hôte au nom des clients du tunnel, et la table NAT réécrit l’adresse source à la sortie. Trompez-vous sur l’une d’elles et le résultat est rarement une panne nette. Vous obtenez un hôte qui accepte les clients mais ne charge rien, ou un hôte qui semble verrouillé jusqu’à ce que quelqu’un lise l’ordre des chaînes.

Le seul port qui ne peut pas être fermé

L’écouteur VPN doit accepter des connexions depuis des adresses que vous ne pouvez pas prévoir, c’est donc un service public par définition. C’est la seule exception autour de laquelle le design est bâti : un port UDP pour OpenVPN, un port UDP pour WireGuard, un port TCP pour un VPN SSL. Tout le reste appartient à l’arrière du tunnel, ce qui signifie que les services applicatifs doivent se lier à l’adresse du tunnel ou à la boucle locale, pas à toutes les interfaces.

Se lier n’est pourtant pas appliquer. Un processus lié à 0.0.0.0 n’est joignable que si une règle l’admet, et la politique par défaut est le recours pour le trafic qu’aucune règle n’a atteint, pas la règle qui gouverne le port. Une acceptation placée au-dessus de votre rejet reste une acceptation, et déplacer un service hors de l’adresse publique est une amélioration indépendante, non un substitut à la chaîne.

Entrée, transfert et NAT répondent à des questions différentes

Le trafic d’entrée est destiné à l’hôte lui-même, c’est donc là que vivent l’écouteur VPN et le chemin administratif. Le trafic de transfert traverse l’hôte, et les clients du tunnel en ont besoin en plus de net.ipv4.ip_forward=1. La configuration classique à moitié cassée autorise le flux sortant et oublie le sens du retour, si bien que le client termine sa poignée de main puis rien ne se charge ; une règle conntrack pour le trafic établi et associé couvre ce sens.

NAT est la troisième question. Sans réécriture en postrouting, les paquets transférés sortent avec la source privée du tunnel et sont rejetés en amont, car aucun réseau au-delà de l’hôte ne sait router le pool en retour. Le préfixe source de cette règle doit correspondre au pool VPN, pas à l’adresse propre de l’hôte, et il en va de même pour la règle de transfert qui nomme le sous-réseau des clients.

IPv6 est une seconde politique, pas une réflexion après coup. Un hôte avec une chaîne IPv4 stricte et une politique ouverte sur ip6tables n’a rien fermé ; les services restent joignables par l’autre famille. Soit vous dupliquez le jeu de règles avec ip6tables, soit vous désactivez IPv6 délibérément sur l’interface publique, et vous notez ce que vous avez choisi.

Une base lisible d’un seul passage

Partez du rejet, puis n’ajoutez que ce dont l’hôte a besoin. D’abord la boucle locale et les réponses, puis le chemin administratif, puis l’écouteur du tunnel, puis la politique de transfert pour les clients :

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Les noms d’interface, le port et le pool sont des espaces réservés ; lisez-les sur le serveur au lieu de les copier. Enregistrer le résultat compte autant que l’écrire, car un jeu de règles qui ne vit qu’en mémoire disparaît au prochain redémarrage et rouvre l’hôte en silence. Rendez-le persistant avec le mécanisme de la distribution et gardez une copie hors de la machine pour le jour où la machine ne démarrera pas.

Fermer le dernier port sans perdre l’hôte

Il y a un piège dans le design. Si SSH n’existe que par le tunnel, un service VPN défaillant emporte SSH avec lui, et le seul retour possible est peut-être une console que vous n’avez jamais ouverte. Avant de fermer le dernier port public, confirmez que cette console existe et que vous pouvez réellement l’utiliser, ou gardez un chemin administratif étroit qui ne dépend pas du tunnel : SSH depuis une adresse fixe, clés uniquement, authentification par mot de passe désactivée.

Appliquez le changement depuis une session déjà établie, pas à travers la connexion que vous êtes sur le point de filtrer. Programmez un retour arrière pour qu’une erreur expire au lieu de devenir permanente, par exemple une tâche systemd-run --on-active=10min qui restaure le jeu de règles précédent, et gardez une seconde session SSH ouverte pendant que vous testez la première. Vérifiez ensuite que la tâche de retour se déclenche vraiment, car une reprise non testée revient à pas de reprise.

Vérifiez le chemin, pas le script

Lisez les règles chargées, pas le fichier censé les charger. Depuis un hôte externe autorisé, confirmez que seuls les ports prévus répondent ; depuis l’intérieur du tunnel, confirmez que les services que vous vouliez publier sont joignables. Une politique de rejet par défaut qui bloque aussi le trafic du tunnel est identique à un verrouillage qui fonctionne jusqu’à ce que quelqu’un essaie de l’utiliser.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Notez le port autorisé, le pool de clients, l’interface du tunnel, la source administrative et la procédure de console à côté de la configuration. Le prochain changement du pool ou du nom d’interface doit être répercuté à la fois dans le filtre et dans la règle NAT, sinon l’hôte revient à un état à moitié ouvert sans que personne ne le remarque.

Une habitude vaut plus que le jeu de règles : après chaque changement, prouvez le chemin de transfert par une requête client et le chemin de reprise par une seconde session. Un verrouillage que vous n’avez pas utilisé est une hypothèse.