Un pool VPN più grande non è un limite di sessioni più grande

Una /22 contiene 1,024 indirizzi IPv4, e quel numero si confonde facilmente con la capacità. Descrive quante assegnazioni l’intervallo potrebbe supportare, non quante sessioni il gateway accetterà o quanto traffico può inoltrare. Dietro ogni risposta ci sono tre conteggi separati, e falliscono in modi diversi. Confrontarli è il modo per attribuire un rifiuto a quello giusto.

Il pool, il diritto e il carico di lavoro si contano in unità diverse e da proprietari diversi.

Che cosa offre davvero il pool

Partite dai limiti effettivi invece che dalla maschera. La topologia della sottorete decide quanti indirizzi il server può distribuire, le assegnazioni fisse e le prenotazioni ne consumano alcuni, e gli indirizzi di rete e di broadcast non sono disponibili. Una /22 offre 1,024 in linea di principio e meno in pratica, il che basta già a rompere l’aritmetica che le persone si aspettano. Una sovrapposizione con reti che i client devono raggiungere può escludere un intervallo che sembrava generoso. Verificate che il meccanismo di assegnazione supporti l’intervallo proposto prima di annunciarlo.

Un pool più grande elimina esattamente un vincolo. Non tocca i limiti di ammissione, le licenze o la capacità di inoltro, e ampliare una sottorete lasciando invariate le route e la politica di accesso produce un intervallo che nessuno può raggiungere.

Che cosa consente davvero la licenza

La concorrenza supportata dalla piattaforma e il diritto del prodotto sono altri due numeri, e spesso non coincidono. I diritti possono contare utenti, dispositivi o sessioni simultanee, e queste misure non sono intercambiabili. Le guide all’ordine dei fornitori mostrano quanto possono differire i modelli, per questo il numero di peer di una vecchia scheda tecnica non va trasferito in una nuova installazione. Leggete l’accordo che si applica al servizio che gestite davvero.

Una licenza che conta utenti nominali non ammetterà più dispositivi solo perché il pool ha spazio.

Che cosa può davvero portare il gateway

Il terzo conteggio è il carico di lavoro. Stimate il traffico che queste sessioni generano insieme: frequenze dei pacchetti, picchi di autenticazione, costo della cifratura e le funzioni di politica attive. Le sessioni interattive e i trasferimenti massivi atterrano in modo molto diverso sulla stessa macchina. Un gateway può avere indirizzi liberi e ammissione su licenza disponibile mentre il carico previsto supera ciò che può inoltrare. Una pianificazione della capacità che ignora l’insieme di funzioni produce un numero valido solo in un laboratorio con tutto spento.

Un rifiuto è il momento di guardare cosa ha registrato il gateway per quel tentativo: un evento di assegnazione, una decisione di ammissione o una chiamata di autenticazione bloccata. Questi tre richiedono correzioni diverse, e indovinare dal lato client raramente sceglie quella giusta.

Attribuite il rifiuto prima di cambiare qualcosa

Il confronto utile è tra i tre conteggi e il guasto osservato. Se il pool è pieno, ampliatelo e aggiornate le route e la politica che lo descrivono. Se l’ammissione viene rifiutata mentre restano indirizzi, il vincolo è altrove. Se le sessioni vengono ammesse e le prestazioni crollano, il problema è la capacità e non uno dei due limiti.

Annotate quale conteggio si è esaurito, quando è successo e cosa è cambiato dopo. Quella registrazione evita che l’indagine successiva riparta dalla maschera di sottorete.

Ampliare un pool è una modifica di una riga con un seguito in tre parti: route, politica e un nuovo test.