Pourquoi un OpenVPN /24 manque de clients plus tôt que prévu
En net30, chaque client prend un /30, donc un /24 plafonne vers 64. Comptez les attributions, trouvez le refus réel, puis redimensionnez le pool d’après le plan d’adresses.
Les pools bâtis sur un /24 qui cessent d’accepter des clients vers la soixantaine se comportent comme prévu et ne heurtent pas une limite de licence. En net30, chaque client reçoit une liaison virtuelle point à point qui consomme quatre adresses, si bien qu’un sous-réseau de 256 adresses n’en soutient qu’environ le quart de ce que le préfixe laisse penser. Le nombre qui compte, ce sont les attributions, pas les adresses. Lire le préfixe comme un nombre de clients est l’erreur qui déclenche la recherche d’un plafond d’utilisateurs caché.
Deux topologies, deux modèles arithmétiques, et un seul d’entre eux correspond au préfixe que l’on suppose.
net30 dépense quatre adresses par client
net30 alloue un bloc /30 par client, car chaque session est modélisée comme une liaison point à point avec une adresse à chaque extrémité. Quatre adresses entrent dans ce bloc et deux sont utilisables, ce qui fait du nombre effectif de clients le quart du sous-réseau. Sur un /24, cela laisse 64 blocs avant que le bloc du serveur lui-même et les éventuelles attributions fixes ne sortent. Un plafond rapporté près de 63 est de l’arithmétique qui transparaît, pas un maximum configuré.
Le serveur a aussi besoin de sa propre attribution, et les entrées statiques de clients consomment des blocs que ces clients se connectent ou non. Les deux réduisent la plage dynamique sans changer le préfixe avec lequel vous avez commencé.
Les limites du pool comptent plus que le préfixe
La directive du serveur peut définir un pool plus étroit que le sous-réseau qu’elle nomme, et un script auxiliaire peut s’étendre à des réglages supplémentaires invisibles dans le profil que vous avez ouvert. Les adresses fixes d’un répertoire client-config se situent dans cette plage et ne peuvent pas être distribuées deux fois. Le préfixe décrit l’espace maximal possible ; le pool effectif est ce que la configuration en cours offre réellement.
Comparez les deux avant de conclure quoi que ce soit sur la capacité, car une plage configurée plus petite explique le plafond aussi bien que la topologie.
Trouvez la limite qui a réellement refusé le client
Lisez d’abord la topologie et le pool effectif, puis tenez compte des attributions fixes et des adresses réservées. Vérifiez aussi max-clients et tout contrôle d’admission hors d’OpenVPN avant d’accuser l’espace d’adressage. Enfin, comparez le message du serveur lui-même au moment du refus avec ces candidats. Le message nomme la contrainte ; le décompte ne fait que resserrer le champ.
Un refus qui arrive avec une erreur de concurrence et un refus qui arrive avec une erreur d’attribution ont des correctifs différents, et hésiter entre les deux gaspille une fenêtre de maintenance.
Changer de topologie change le plan d’adresses
Passer à la topologie de sous-réseau donne à chaque client une adresse au lieu d’un bloc, ce qui est le bon geste quand le préfixe est réellement trop petit. Cela change aussi ce que signifient les paramètres d’adresse du client, donc chaque attribution épinglée et chaque fichier propre à un client doivent être redérivés plutôt que renumérotés à la main. Planifiez la nouvelle plage, migrez les entrées statiques et mettez à jour les routes qui les référencent.
Le basculement n’est pas un synonyme de l’ancienne configuration. Traitez-le comme un changement de plan d’adresses avec sa propre revue, et attendez-vous à ce qu’au moins un client conserve une adresse de l’ancien schéma.
Dimensionnez le pool d’après le plan, pas d’après le masque
Choisissez la taille d’après le nombre de clients simultanés plus une marge pour les reconnexions et les tests, puis prenez le plus petit préfixe qui la couvre dans la topologie retenue. Élargir à un /16 pour résoudre un plafond de soixante clients échange un problème de capacité contre un problème de routage et de chevauchement, car une plage privée plus grande risque davantage d’entrer en collision avec quelque chose que le client atteint déjà.
Documentez ensemble la topologie, le pool, les attributions fixes et le plafond de clients qui en résulte. La question de capacité suivante devient alors de l’arithmétique au lieu d’une enquête.