Un pool VPN més gran no és un límit de sessions més gran

Una /22 conté 1,024 adreces IPv4, i aquest nombre és fàcil de confondre amb capacitat. Descriu quantes assignacions pot suportar el rang, no quantes sessions admetrà la passarel·la ni quant trànsit pot reenviar. Darrere de qualsevol resposta hi ha tres recomptes separats, i fallen de maneres diferents. Comparar-los és com s'atribueix un rebuig al correcte.

El pool, el dret i la càrrega de treball es compten en unitats diferents i per propietaris diferents.

Què ofereix realment el pool

Comenceu pels límits efectius, no per la màscara. La topologia de la subxarxa decideix quantes adreces pot repartir el servidor, les assignacions fixes i les reserves en consumeixen algunes, i les adreces de xarxa i de difusió no estan disponibles. Una /22 n'ofereix 1,024 en principi i menys a la pràctica, cosa que ja n'hi ha prou per trencar l'aritmètica que la gent espera. La superposició amb xarxes a què els clients han d'arribar pot descartar un rang que semblava generós. Verifiqueu que el mecanisme d'assignació admeti el rang proposat abans d'anunciar-lo.

Un pool més gran elimina exactament una restricció. No toca els límits d'admissió, la llicència ni el rendiment de reenviament, i ampliar una subxarxa deixant les rutes i la política d'accés sense canvis produeix un rang al qual ningú no pot arribar.

Què permet realment la llicència

La concurrència admesa per la plataforma i el dret del producte són dos nombres més, i sovint no coincideixen. Els drets poden comptar usuaris, dispositius o sessions simultànies, i aquestes mesures no són intercanviables. Les guies de comanda dels proveïdors mostren com poden arribar a diferir els models, i per això el nombre de parells d'una fitxa tècnica antiga no s'ha de traslladar a una nova implantació. Llegiu l'acord que s'aplica al servei que realment gestioneu.

Una llicència que compta usuaris nominals no admetrà més dispositius només perquè el pool tingui lloc.

Què pot suportar realment la passarel·la

El tercer recompte és la càrrega de treball. Estimeu el trànsit que aquestes sessions generen juntes: ritmes de paquets, pics d'autenticació, cost de xifratge i les funcions de política que estiguin activades. Les sessions interactives i les transferències massives cauen molt diferentment a la mateixa caixa. Una passarel·la pot tenir adreces lliures i admissió llicenciada disponible mentre la càrrega prevista supera el que pot reenviar. La planificació de capacitat que ignora el conjunt de funcions produeix un nombre que només val en un laboratori amb tot desactivat.

Un rebuig és el moment de mirar què va registrar la passarel·la per a aquell intent: un esdeveniment d'assignació, una decisió d'admissió o una crida d'autenticació encallada. Aquests tres produeixen correccions diferents, i endevinar des del costat del client poques vegades encerta la correcta.

Atribuïu el rebuig abans de canviar res

La comparació útil és entre els tres recomptes i la fallada observada. Si el pool és ple, amplieu-lo i actualitzeu les rutes i la política que el descriuen. Si es refusa l'admissió mentre queden adreces, la restricció és en un altre lloc. Si s'admeten sessions i el rendiment s'enfonsa, el problema és la capacitat, no cap dels dos límits.

Anoteu quin recompte es va esgotar, quan va passar i què va canviar després. Aquest registre evita que la propera investigació torni a començar per la màscara de subxarxa.

Ampliar un pool és un canvi d'una línia amb un seguiment de tres parts: rutes, política i una nova prova.