Un pool VPN más grande no es un límite de sesiones más grande

Una /22 contiene 1,024 direcciones IPv4, y ese número se confunde fácilmente con capacidad. Describe cuántas asignaciones podría admitir el rango, no cuántas sesiones aceptará la puerta de enlace ni cuánto tráfico puede reenviar. Detrás de cualquier respuesta hay tres recuentos separados, y fallan de maneras distintas. Compararlos es la forma de atribuir un rechazo al correcto.

El pool, el derecho y la carga de trabajo se cuentan en unidades distintas y por propietarios distintos.

Qué ofrece realmente el pool

Empiece por los límites efectivos en lugar de la máscara. La topología de la subred decide cuántas direcciones puede repartir el servidor, las asignaciones fijas y las reservas consumen algunas, y las direcciones de red y de difusión no están disponibles. Una /22 ofrece 1,024 en principio y menos en la práctica, lo que ya basta para romper la aritmética que la gente espera. La superposición con redes a las que los clientes deben llegar puede descartar un rango que parecía generoso. Verifique que el mecanismo de asignación admita el rango propuesto antes de anunciarlo.

Un pool más grande elimina exactamente una restricción. No toca los límites de admisión, las licencias ni el rendimiento de reenvío, y ampliar una subred dejando las rutas y la política de acceso sin cambios produce un rango al que nadie puede llegar.

Qué permite realmente la licencia

La concurrencia admitida por la plataforma y el derecho del producto son dos números más, y con frecuencia no coinciden. Los derechos pueden contar usuarios, dispositivos o sesiones simultáneas, y esas medidas no son intercambiables. Las guías de pedido de los proveedores muestran lo distintos que pueden ser los modelos, y por eso el número de pares de una hoja de datos antigua no debe trasladarse a una implementación nueva. Lea el acuerdo que se aplica al servicio que realmente opera.

Una licencia que cuenta usuarios con nombre no admitirá más dispositivos solo porque el pool tenga sitio.

Qué puede soportar realmente la puerta de enlace

El tercer recuento es la carga de trabajo. Estime el tráfico que esas sesiones generan juntas: ritmos de paquetes, ráfagas de autenticación, coste de cifrado y las funciones de política que estén activadas. Las sesiones interactivas y las transferencias masivas caen de forma muy distinta en la misma máquina. Una puerta de enlace puede tener direcciones libres y admisión licenciada disponible mientras la carga prevista supera lo que puede reenviar. La planificación de capacidad que ignora el conjunto de funciones produce un número que solo vale en un laboratorio con todo apagado.

Un rechazo es el momento de mirar qué registró la puerta de enlace para ese intento: un evento de asignación, una decisión de admisión o una llamada de autenticación atascada. Esos tres producen correcciones distintas, y adivinar desde el lado del cliente rara vez elige la correcta.

Atribuya el rechazo antes de cambiar nada

La comparación útil es entre los tres recuentos y el fallo observado. Si el pool está lleno, amplíelo y actualice las rutas y la política que lo describen. Si se rechaza la admisión mientras quedan direcciones, la restricción está en otro sitio. Si se admiten sesiones y el rendimiento se desploma, el problema es la capacidad y no ninguno de los dos límites.

Anote qué recuento se agotó, cuándo ocurrió y qué cambió después. Ese registro evita que la siguiente investigación vuelva a empezar por la máscara de subred.

Ampliar un pool es un cambio de una línea con un seguimiento de tres partes: rutas, política y una nueva prueba.