Adresses de tunnel statiques dans pfSense : préférence ou réservation ?

Deux conceptions se ressemblent sur le papier et se comportent très différemment dès qu’une règle en dépend. L’une saisit une adresse dans une surcharge client et traite cette adresse comme une identité. L’autre ferme complètement l’admission dynamique, de sorte qu’un point de terminaison dispose soit d’une affectation unique, soit d’aucune connexion. Seule la seconde transforme une adresse en un élément de politique que vous pouvez défendre, et la différence mérite d’être comprise avant d’écrire la moindre règle de pare-feu.

Ce qu’une adresse de surcharge promet réellement

Une surcharge spécifique au client porte des options par client, dont une adresse de tunnel préférée. Netgate décrit cette adresse comme une préférence et non comme une réservation, ce qui signifie que le pool dynamique ne renonce pas à l’adresse pour quelqu’un d’autre.

C’est généralement acceptable. Une collision est rare, et le client reçoit normalement ce qu’il a demandé, ce qui suffit pour la commodité et ne suffit pas pour l’autorisation. Commodité et autorisation sont des exigences différentes, et une seule des deux survit à une collision.

Avec la topologie de sous-réseau, le champ prend l’adresse du client avec le masque du réseau du serveur, si bien qu’une adresse à l’intérieur d’un tunnel 10.90.0.0/24 s’écrit 10.90.0.10/24.

Rien de tout cela ne réserve le numéro. Un client dont la surcharge ne correspond pas, ou une session en double, peut se retrouver ailleurs dans le pool, et une règle fondée sur l’adresse décrit alors quelqu’un qui n’est pas là.

Fermer la voie dynamique avec un défaut bien délimité

L’alternative est un serveur uniquement statique : chaque point de terminaison admis a sa propre identité et sa propre adresse unique, et rien d’autre n’entre.

Le mettre en œuvre suppose une surcharge DEFAULT limitée à ce seul serveur, avec le blocage des connexions activé. Un client sans surcharge correspondante ne peut alors pas retomber sur l’admission dynamique ordinaire. Cette seule ligne est ce qui transforme une préférence en ensemble fermé.

La portée compte. Une surcharge par défaut appliquée à chaque instance VPN de la machine bloquera des tunnels sans rapport, et cette panne ressemble à un service cassé plutôt qu’à une décision de politique. Liez-la au seul serveur dont vous changez le modèle d’admission. Notez ensuite la portée dans le journal des changements, car la personne suivante ne se souviendra pas du tunnel auquel elle appartient.

Auditez ensuite l’ensemble autorisé complet. Le blocage par défaut ne corrige pas une surcharge nommée laissée sans adresse, et ce point de terminaison échouera simplement à se connecter sans indice évident sur la raison.

Faire correspondre l’identité que le serveur utilise vraiment

Une surcharge correspond à quelque chose. Sur un serveur qui compare les noms communs des certificats, le nom de la surcharge doit être ce nom commun, et non le nom d’affichage de la personne. Copiez-le depuis le certificat plutôt que depuis la liste des comptes.

Un serveur configuré pour utiliser le nom d’utilisateur comme nom commun compare sur une clé entièrement différente, et une surcharge nommée d’après le certificat ne se déclenchera jamais. Lisez le paramètre plutôt que de le déduire de ce que montre la liste des comptes.

Conservez les facteurs d’authentification supplémentaires exigés par le déploiement. Un modèle d’adressage fermé change qui peut se connecter et quelle adresse il reçoit ; il ne remplace ni la vérification du certificat ni le second facteur.

Écrire les règles d’accès une fois la carte saine

Une fois la correspondance entre identité et adresse fermée, les règles peuvent référencer des adresses sans prétendre qu’il s’agit de personnes. Un alias regroupant les points de terminaison d’une personne peut atteindre un service précis tandis qu’un autre alias atteint autre chose. L’alias devient l’objet vérifiable, et l’adresse devient un détail d’implémentation à l’intérieur.

Gardez les destinations et les ports explicites. Autoriser tout le réseau local depuis l’ensemble du pool de tunnels est précisément la conception que cet exercice devait remplacer.

Lisez les règles flottantes, de groupe et d’interface dans leur ordre d’évaluation réel, car un passage large antérieur annule un passage étroit postérieur. Désactiver le transfert interne de client à client maintient le trafic entre pairs à la frontière où ces règles sont examinées. Une règle qui n’existe que sur le papier n’est pas une application.

Tester les cas négatifs

Exercez quatre connexions neuves : un point de terminaison nommé, un sans aucune surcharge, un service qui devrait être joignable et un qui ne devrait pas l’être. Le point de terminaison non listé est le cas important, car c’est celui que la conception existe pour arrêter. S’il se connecte, le blocage par défaut ne fait pas son travail.

Vérifiez IPv6 séparément, car une politique d’adresses IPv4 ne dit rien d’une seconde pile. Confirmez ensuite que l’application autorise toujours l’utilisateur, car une adresse de tunnel est un fait de réseau et non une preuve de qui est au clavier. Les deux vérifications ont leur place dans la note de recette.

Enfin, planifiez la migration. Les nouvelles surcharges et les règles étroites ne modifient pas rétroactivement les sessions déjà établies, donc les états existants doivent expirer ou être effacés délibérément.