Dimensionnez les sessions VPN par rôle, puis vérifiez la marge de panne

Vous ajoutez une seconde passerelle, la console affiche deux membres sains, et le plafond de sessions bouge à peine, parce que rien n'a dit aux clients comment joindre la nouvelle machine. Dimensionner un service VPN, c'est deux décisions successives : quel mécanisme répartit les clients pour ce type de connexion, et quelle capacité reste après la pire perte isolée. Les prendre dans l'ordre inverse produit une conception qui semble redondante et échoue précisément quand on en a besoin. Commencez par la console, puis faites l'arithmétique.

Assortissez le mécanisme au type de session

Les utilisateurs distants, les pairs intersites et les tunnels d'appareils toujours actifs ne sont pas des sessions interchangeables. Une fonction de répartition conçue pour l'un d'eux redirige normalement un client pendant la négociation, ce qui ne signifie rien pour un pair qui détient déjà une adresse fixe et une configuration statique.

Le guide de haute disponibilité ASA de Cisco distingue trois capacités : l'équilibrage de charge VPN pour l'accès distant, le basculement avec état et le clustering intersites. Seule la première déplace un client éligible d'une entrée de groupe vers un membre, et les connexions LAN à LAN restent hors de cette répartition. Un répartiteur TCP générique ne peut pas remplacer l'étape de redirection propre au protocole, car le handshake du tunnel n'est pas du HTTP simple qu'un proxy peut réécrire. Le résultat pratique est un répartiteur qui accepte la connexion et laisse néanmoins le client incapable d'établir le tunnel.

Lisez la liste des fonctions au regard de votre type de session avant de commander un second équipement. La ligne de licence et la ligne de mécanisme sont des entrées distinctes, et l'une n'implique pas l'autre.

Calculez l'exemple au lieu de deviner

Supposons que trois passerelles soient chacune validées à 800 tunnels simultanés sous la charge que vous avez approuvée, soit 2,400 au total. Un objectif de 1,650 en heure de pointe semble confortable jusqu'à la perte d'une unité, et le couple survivant doit alors tenir 1,650 face à 1,600 fermes. La conception a déjà échoué, et aucun réglage de basculement ne répare l'arithmétique.

Fixez l'objectif pour que l'ensemble survivant le respecte encore, ce qui, pour un groupe de trois membres, signifie rester sous les deux tiers du total. Ce rapport est une propriété de l'arithmétique et non d'un produit, alors recalculez-le dès que le chiffre validé d'un membre change. Gardez le nombre licencié, le maximum documenté et votre propre chiffre mesuré dans trois colonnes, car ils concordent rarement et le plus petit fait foi. Une quatrième colonne pour le pic observé en heure de pointe garde le plan honnête après le premier mois.

Budgétez la rafale de reconnexion, pas seulement le régime stable

Les sessions d'un membre défaillant ne réapparaissent pas discrètement ailleurs. Selon le mécanisme, elles basculent avec état, renégocient depuis zéro ou attendent que l'application réessaie selon son propre calendrier.

Quelques milliers de clients qui réessaient en une minute forment un événement différent d'un 1,650 stable, et les serveurs d'authentification le ressentent en premier. Vérifiez aussi l'espace du pool, car la redirection ne le consulte pas : un membre qui ne peut pas allouer d'adresse accepte quand même le client puis abandonne son trafic.

Vérifiez la capacité avec le pool et la route sous la main

La vérification est un exercice en lecture seule qui attrape la plupart des erreurs de conception avant l'ouverture d'une fenêtre de maintenance. Relevez le pool par membre, le nombre de sessions actives et la route de retour vers le sous-réseau client, puis comparez chacun au plan. L'épuisement du pool et une route de retour manquante se manifestent tous deux par un client qui s'authentifie puis perd son trafic.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Exécutez ces lectures sur chaque membre pendant une heure de pointe normale plutôt qu'une heure calme. Un membre qui signale des sessions mais n'a plus d'adresses libres est déjà à sa limite pratique, quoi qu'en dise la licence. Notez la version du firmware à côté de chaque sortie, car les noms de commandes changent d'une version à l'autre.

Répétez la perte une fois volontairement, en dehors des heures ouvrées, et notez ce que les membres survivants signalent pendant l'opération. Un membre qui accepte la redirection mais n'a pas d'espace dans le pool apparaît comme une allocation échouée, ce que la bande passante supplémentaire ne corrige jamais. Conservez les chiffres validés avec la date à côté du plan, afin que la prochaine revue de capacité parte de preuves et non d'un tableur de licences. Ajoutez le résultat de cet essai sur la même page, même lorsque les chiffres correspondent au plan.