Les adresses stables d’OpenVPN doivent suivre l’identité, pas l’IP source
Une adresse statique est une affirmation sur une identité, pas sur une IP source. Choisissez la clé, gardez les réservations hors du pool, puis choisissez le propriétaire de l’attribution.
Les plans d’adressage qui disent « ce portable obtient 10.90.0.10 » sont en réalité des affirmations sur l’identité : quel appareil authentifié peut détenir cette adresse. L’IP publique actuelle de cet appareil n’a presque rien à voir avec cela, car le NAT et l’itinérance la changent sans changer qui est l’utilisateur. Construire le plan sur l’adresse source produit des règles qui se cassent sur le premier réseau d’hôtel. Le construire sur l’identité authentifiée produit un plan qui survit aux déplacements.
Partez de ce que le serveur peut vérifier, puis décidez à quoi sert l’adresse.
Choisissez la clé d’identité avant l’adresse
Un certificat client distinct par appareil donne au serveur une clé stable et vérifiable pour chaque membre, ce qui constitue la base la plus propre pour une attribution statique. Un déploiement utilisant une authentification par utilisateur peut plutôt s’appuyer sur le nom d’utilisateur, tant que la sélection de configuration suit le même champ. Mélanger les deux modèles produit des attributions qui correspondent à un certificat pour un client et à un nom d’utilisateur pour un autre, et personne ne peut prédire laquelle l’emporte. Décidez quelle clé le plan utilise avant d’écrire une seule réservation.
Avec duplicate-cn, plusieurs sessions simultanées peuvent présenter le même nom commun, donc une adresse épinglée ne peut pas les identifier individuellement. C’est une propriété du modèle d’identité, pas quelque chose qu’un meilleur plan d’adressage peut corriger.
Réservez des adresses hors de la plage dynamique
Dans un réseau à topologie de sous-réseau comme 10.90.0.0/24, gardez les adresses basses pour les membres nommés et placez le pool dynamique dans une plage disjointe. Une attribution pour un membre épinglé ressemble à ceci ifconfig-push 10.90.0.10 255.255.255.0 dans le fichier que le serveur sélectionne pour cette identité. Le second argument signifie autre chose sous net30, donc l’exemple n’est pas neutre vis-à-vis de la topologie. Lisez la topologie avant de le copier.
La persistance du pool enregistre les baux récents et tend à rendre la même adresse, ce qui est une commodité et non une réservation. Ne laissez pas le fichier de persistance devenir le registre de propriété, car il change avec l’historique des connexions et non avec la politique.
La priorité d’attribution décide qui gagne
Le manuel documente un ordre : une attribution explicite générée pendant client-connect peut prendre effet avant une entrée client-config-dir, qui elle-même précède l’attribution ordinaire du pool. Cet ordre explique la plupart des rapports « l’adresse épinglée ne s’est pas appliquée ». Il signifie aussi qu’un allocateur dynamique qui écrit une configuration par session peut silencieusement écraser un fichier statique que vous croyiez faisant autorité.
Choisissez une seule couche pour posséder les attributions et rendez les autres en lecture seule. Deux couches qui revendiquent toutes deux la décision produisent des attributions qui dépendent du moment.
Un allocateur dynamique a besoin du même modèle
Une intégration client-connect qui distribue des adresses par session est un petit allocateur avec les problèmes habituels des allocateurs. Il doit valider l’identité demandeuse, réserver une adresse de façon atomique, n’émettre que la sortie par connexion prise en charge et libérer la réservation à la déconnexion ou en cas d’échec. Les requêtes concurrentes ont besoin d’un verrou ou d’une contrainte de base de données, pas d’une séquence lire-puis-écrire. Sans nettoyage, le pool perd des adresses jusqu’au redémarrage.
Gardez l’état de l’allocateur là où l’opérateur suivant peut le lire, et journalisez la décision identité-vers-adresse plutôt que seulement l’adresse.
Décidez si l’adresse relève de la politique ou du confort
Si une règle de pare-feu ou une route autorise le trafic depuis une adresse de tunnel, alors l’adresse participe à la politique d’accès et une réattribution hérite de cette permission. Coordonnez le cycle de vie de l’identité, de l’adresse et du pare-feu, ou liez la règle à quelque chose qui ne peut pas être réattribué. Un adressage stable rend la configuration lisible ; il ne remplace pas l’authentification.
Écrivez le plan comme un inventaire avec un propriétaire par entrée, puis révisez-le lorsqu’un appareil est retiré. La réservation inutilisée est celle qui est réutilisée par accident.