Limiter une passerelle OpenVPN à un seul réseau local avec les règles UFW

Décidez l'autorisation avant d'ouvrir un fichier de pare-feu : les clients authentifiés peuvent ouvrir des connexions vers un sous-réseau précis, et la passerelle doit refuser tout autre chemin de transit même lorsqu'un client installe des routes supplémentaires. Cette phrase est le dessein, et chaque règle ci-dessous existe pour la faire respecter. Quelque chose de plus large, comme tout l'espace d'adressage privé, la sortie vers internet par le tunnel ou le trafic pair à pair, est un dessein différent qui demande sa propre décision. Les règles sont aussi volontairement ennuyeuses, car un pare-feu astucieux est celui que personne ne pourra auditer plus tard.

Écrivez d'abord la topologie et l'autorisation

L'exemple utilise un serveur Community OpenVPN avec un périphérique TUN en espace utilisateur nommé tun0, un pool de clients 10.77.0.0/24, et un sous-réseau attaché 192.168.60.0/24 sur lan0. Le transfert IPv4 fonctionne déjà et le réseau local a déjà une route de retour vers le pool, donc rien ici ne dépend de la traduction entre eux.

UFW est propriétaire du pare-feu sur cet hôte, et aucun jeu de règles de conteneur ni table nftables séparée ne peut installer un chemin d'acceptation antérieur. Un raccourci de délestage de flux qui contourne le filtre rendrait les chaînes de garde décoratives, alors confirmez qu'aucun n'est actif. Laissez le transfert client-to-client propre à OpenVPN désactivé, car le trafic pair à pair qui ne traverse jamais le filtre du système d'exploitation ne peut pas être borné par lui. L'écouteur externe et les règles d'administration restent tels quels, puisque ce changement gouverne le trafic déchiffré du tunnel plutôt que de remplacer le pare-feu.

Placez les gardes avant les acceptations précoces d'UFW

Une autorisation de route suivie d'un refus ne suffit pas pour une frontière stricte. Les règles before d'origine acceptent le trafic établi et certains ICMP avant que la moindre règle utilisateur soit consultée, donc un flux autorisé la semaine dernière peut rester hors de la nouvelle restriction de destination simplement parce qu'il a encore de l'état. Sauvegardez les fichiers d'UFW et gardez une console hors bande ouverte avant d'éditer.

Dans la section *filter du fichier /etc/ufw/before.rules, déclarez deux chaînes à côté des déclarations existantes et avant toute ligne de règle.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Juste après les déclarations, et avant les autorisations d'entrée et de transfert, sautez dans ces chaînes et définissez ce qu'elles admettent.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Conservez le reste de la section et sa ligne COMMIT. Coller une deuxième table de filtre ou supprimer des règles sans rapport est la façon dont un changement de pare-feu devient une panne, et le fichier est à un redémarrage d'être la seule copie qui compte.

Lisez ce que chaque garde admet et refuse

La première chaîne ne poursuit le traitement que lorsque la source est dans le pool, que la destination est l'unique sous-réseau, que l'interface de sortie est le réseau local et que le paquet voyage dans la direction d'origine de son flux. Tout le reste qui arrive du tunnel est supprimé, y compris une source hors du pool et toute destination au-delà du sous-réseau autorisé.

Un paquet pair à pair entre et sort par tun0, donc il échoue au test d'interface du réseau local avant même d'atteindre une vérification de destination. Les nouvelles connexions du réseau local vers les clients échouent aussi au test de direction de réponse, ce qui ferme par défaut le chemin de rappel inverse.

La cible RETURN maintient la politique UFW ordinaire en jeu. Ces chaînes filtrent, et l'autorisation de route que vous ajoutez ensuite décide encore si un paquet survivant est accepté. C'est cette séparation qui vous permet de changer plus tard le sous-réseau autorisé à un seul endroit. Si les gardes acceptaient les paquets d'emblée, chaque règle future devrait être ajoutée deux fois.

Autorisez le sous-réseau et fermez les portes de côté

Prévisualisez d'abord l'autorisation de route, puis retirez l'indicateur de prévisualisation pour l'appliquer : sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Ensuite, vérifiez l'ordre des règles utilisateur, car un refus antérieur l'emporte encore sur une autorisation ultérieure. Une autorisation pour tout le sous-réseau est aussi la mauvaise forme lorsque seul le port HTTPS d'un hôte doit être joignable.

Notez ce que fait la suppression d'entrée : les clients du tunnel ne peuvent atteindre aucun service sur la passerelle elle-même, y compris un écouteur DNS lié à son adresse de réseau local. Héberger du DNS là-bas exige une exception délibérée avant la suppression et un contrat d'autorisation révisé. Si UFW gère IPv6, ajoutez des suppressions correspondantes pour tun0 dans before6.rules également, car une liste de destinations IPv4 ne dit rien des paquets IPv6.

Vérifiez la politique chargée, pas la prévisualisation

Prévisualisez le rechargement, appliquez-le dans une fenêtre de maintenance et lisez le jeu de règles actif.

sudo ufw --dry-run reload
sudo ufw show raw

Confirmez que les gardes du tunnel apparaissent avant les autorisations par défaut d'état et ICMP. Un ufw status simple n'affiche pas les règles before modifiées à la main, et c'est pourquoi les opérateurs concluent qu'une règle manque alors qu'elle est en fait chargée. Lisez la liste brute de haut en bas au lieu de chercher un fragment. Si les gardes apparaissent après une autorisation d'état, la frontière ne fait pas ce que le fichier suggère.

Testez ensuite le comportement plutôt que le texte. Ouvrez une connexion neuve vers un hôte autorisé et observez la réponse, acheminez une requête inoffensive vers une destination hors du sous-réseau et confirmez qu'elle meurt, essayez une connexion pair à pair, essayez un service local à la passerelle et essayez une connexion non sollicitée du réseau local vers un client. Incluez un flux hors périmètre qui existait avant le changement, et effacez seulement ce flux au lieu de vider toute la table de suivi de la machine.

Consignez les limites à côté des règles : ceci borne le transit et rien d'autre. Cela n'empêche pas un client d'utiliser sa propre connexion internet, n'empêche pas un hôte autorisé du réseau local de relayer du trafic plus loin, et ne remplace pas l'authentification à l'intérieur des services autorisés.