Een grotere VPN-pool is geen grotere sessielimiet
Een /22 bevat 1,024 adressen, niet 1,024 sessies. Tel de pool, de licentie en de doorvoercapaciteit apart en koppel een weigering daarna aan een van die drie.
Een /22 bevat 1,024 IPv4-adressen, en dat aantal wordt gemakkelijk met capaciteit verward. Het beschrijft hoeveel toewijzingen de reeks kan ondersteunen, niet hoeveel sessies de gateway accepteert of hoeveel verkeer hij kan doorsturen. Achter elk antwoord staan drie afzonderlijke tellingen, en ze falen op verschillende manieren. Juist het vergelijken ervan koppelt een weigering aan de juiste.
De pool, het recht en de werklast worden in verschillende eenheden en door verschillende eigenaren geteld.
Wat de pool werkelijk biedt
Begin bij de werkelijke grenzen in plaats van het masker. De subnettopologie bepaalt hoeveel adressen de server kan uitdelen, vaste toewijzingen en reserveringen gebruiken er enkele, en het netwerk- en broadcastadres zijn niet beschikbaar. Een /22 biedt 1,024 in theorie en minder in de praktijk, wat al genoeg is om de verwachte rekensom te breken. Overlap met netwerken die clients moeten bereiken kan een reeks uitsluiten die royaal leek. Controleer of het toewijzingsmechanisme de voorgestelde reeks ondersteunt voordat je die aankondigt.
Een grotere pool verwijdert precies één beperking. Hij raakt geen toelatingslimieten, licenties of doorvoersnelheid aan, en een subnet vergroten zonder de routes en het toegangsbeleid te wijzigen levert een reeks op die niemand kan bereiken.
Wat de licentie werkelijk toestaat
De door het platform ondersteunde gelijktijdigheid en het productrecht zijn nog twee getallen, en ze zijn vaak niet gelijk. Rechten kunnen gebruikers, apparaten of gelijktijdige sessies tellen, en die maten zijn niet uitwisselbaar. Bestelgidsen van leveranciers laten zien hoe verschillend de modellen kunnen zijn, daarom moet het peeraantal van een oud datablad niet naar een nieuwe uitrol worden overgedragen. Lees de overeenkomst die geldt voor de dienst die je werkelijk beheert.
Een licentie die benoemde gebruikers telt, laat niet meer apparaten toe alleen omdat er ruimte in de pool is.
Wat de gateway werkelijk kan dragen
De derde telling is de werklast. Schat het verkeer dat deze sessies samen genereren: pakketfrequenties, authenticatiepieken, versleutelingskosten en welke beleidsfuncties dan ook aanstaan. Interactieve sessies en bulkoverdrachten landen heel anders op dezelfde machine. Een gateway kan vrije adressen en beschikbare toegelaten toelating hebben terwijl de bedoelde belasting meer is dan hij kan doorsturen. Capaciteitsplanning die de functieset negeert, levert een getal dat alleen geldt in een lab met alles uitgeschakeld.
Een weigering is het moment om te kijken wat de gateway voor die poging heeft gelogd: een toewijzingsgebeurtenis, een toelatingsbeslissing of een vastgelopen authenticatieoproep. Die drie vragen om verschillende correcties, en gokken vanaf de clientzijde kiest zelden de juiste.
Wijs de weigering toe voordat je iets verandert
De nuttige vergelijking is die tussen de drie tellingen en de waargenomen storing. Is de pool vol, breid hem uit en werk de routes en het beleid bij die hem beschrijven. Wordt toelating geweigerd terwijl er nog adressen zijn, dan ligt de beperking elders. Worden sessies toegelaten en stort de prestatie in, dan is het probleem capaciteit en geen van beide limieten.
Noteer welke telling uitgeput was, wanneer het gebeurde en wat daarna veranderde. Dat verslag voorkomt dat het volgende onderzoek weer bij het subnetmasker begint.
Een pool vergroten is een wijziging van één regel met een driedelige vervolgstap: routes, beleid en een nieuwe test.