Un plus grand pool VPN n’est pas une plus grande limite de sessions

Un /22 contient 1,024 adresses IPv4, et ce nombre se confond facilement avec de la capacité. Il décrit combien d’attributions la plage pourrait prendre en charge, pas combien de sessions la passerelle admettra ni quel trafic elle peut transmettre. Trois comptages distincts se cachent derrière toute réponse, et ils échouent de manières différentes. C’est en les comparant qu’un refus est attribué au bon.

Le pool, le droit et la charge de travail se comptent en unités différentes et par des propriétaires différents.

Ce que le pool offre réellement

Partez des limites effectives plutôt que du masque. La topologie du sous-réseau décide combien d’adresses le serveur peut distribuer, les attributions fixes et les réservations en consomment certaines, et les adresses de réseau et de diffusion ne sont pas disponibles. Un /22 offre 1,024 en principe et moins en pratique, ce qui suffit déjà à casser l’arithmétique attendue. Un chevauchement avec des réseaux que les clients doivent joindre peut écarter une plage qui semblait généreuse. Vérifiez que le mécanisme d’attribution prend en charge la plage proposée avant de l’annoncer.

Un pool plus grand supprime exactement une contrainte. Il ne touche ni aux limites d’admission, ni aux licences, ni au débit de transfert, et agrandir un sous-réseau en laissant les routes et la politique d’accès inchangées produit une plage que personne ne peut joindre.

Ce que la licence permet réellement

La concurrence prise en charge par la plateforme et le droit produit sont deux nombres de plus, et ils ne coïncident souvent pas. Les droits peuvent compter des utilisateurs, des appareils ou des sessions simultanées, et ces mesures ne sont pas interchangeables. Les guides de commande des fournisseurs montrent à quel point les modèles peuvent différer, c’est pourquoi le nombre de pairs d’une ancienne fiche technique ne doit pas être reporté dans un nouveau déploiement. Lisez l’accord qui s’applique au service que vous exploitez réellement.

Une licence qui compte des utilisateurs nommés n’admettra pas plus d’appareils simplement parce que le pool a de la place.

Ce que la passerelle peut réellement porter

Le troisième comptage est la charge de travail. Estimez le trafic que ces sessions génèrent ensemble : débits de paquets, pics d’authentification, coût du chiffrement et les fonctions de stratégie activées. Les sessions interactives et les transferts massifs tombent très différemment sur la même machine. Une passerelle peut avoir des adresses libres et une admission sous licence disponible alors que la charge prévue dépasse ce qu’elle peut transmettre. Une planification de capacité qui ignore le jeu de fonctions produit un nombre qui ne tient que dans un laboratoire où tout est désactivé.

Un refus est le moment de regarder ce que la passerelle a journalisé pour cette tentative : un événement d’attribution, une décision d’admission ou un appel d’authentification bloqué. Ces trois appellent des corrections différentes, et deviner côté client choisit rarement la bonne.

Attribuez le refus avant de changer quoi que ce soit

La comparaison utile est entre les trois comptages et la défaillance observée. Si le pool est plein, élargissez-le et mettez à jour les routes et la politique qui le décrivent. Si l’admission est refusée alors que des adresses restent, la contrainte est ailleurs. Si les sessions sont admises et que les performances s’effondrent, le problème est la capacité et non l’une des deux limites.

Notez quel comptage s’est épuisé, quand cela s’est produit et ce qui a changé ensuite. Cette trace évite que l’enquête suivante reparte du masque de sous-réseau.

Agrandir un pool est un changement d’une ligne avec un suivi en trois parties : routes, politique et nouveau test.