Un pool VPN máis grande non é un límite de sesións máis grande

Unha /22 contén 1,024 enderezos IPv4, e ese número confúndese facilmente coa capacidade. Describe cantas asignacións podería admitir o rango, non cantas sesións aceptará a pasarela nin canto tráfico pode reenviar. Detrás de calquera resposta hai tres recontos separados, e fallan de xeitos distintos. Comparalos é a forma de atribuír unha negativa ao correcto.

O pool, o dereito e a carga de traballo cóntanse en unidades distintas e por propietarios distintos.

Que ofrece realmente o pool

Comeza polos límites efectivos en lugar da máscara. A topoloxía da subrede decide cantos enderezos pode repartir o servidor, as asignacións fixas e as reservas consomen algúns, e os enderezos de rede e de difusión non están dispoñibles. Unha /22 ofrece 1,024 en principio e menos na práctica, o que xa abonda para romper a aritmética que a xente espera. A superposición con redes ás que os clientes deben chegar pode descartar un rango que parecía xeneroso. Verifica que o mecanismo de asignación admite o rango proposto antes de anuncialo.

Un pool máis grande elimina exactamente unha restrición. Non toca os límites de admisión, a licenza nin o rendemento de reenvío, e ampliar unha subrede deixando as rutas e a política de acceso sen cambios produce un rango ao que ninguén pode chegar.

Que permite realmente a licenza

A concorrencia admitida pola plataforma e o dereito do produto son dous números máis, e frecuentemente non coinciden. Os dereitos poden contar usuarios, dispositivos ou sesións simultáneas, e esas medidas non son intercambiables. As guías de pedido dos provedores mostran o distintos que poden ser os modelos, e por iso o número de pares dunha folla de datos antiga non debe trasladarse a unha implantación nova. Le o acordo que se aplica ao servizo que realmente operas.

Unha licenza que conta usuarios con nome non admitirá máis dispositivos só porque o pool teña sitio.

Que pode soportar realmente a pasarela

O terceiro reconto é a carga de traballo. Estima o tráfico que esas sesións xeran xuntas: ritmos de paquetes, ráfagas de autenticación, custo de cifrado e as funcións de política que estean activadas. As sesións interactivas e as transferencias masivas caen de xeito moi distinto na mesma máquina. Unha pasarela pode ter enderezos libres e admisión licenciada dispoñible mentres a carga prevista supera o que pode reenviar. A planificación de capacidade que ignora o conxunto de funcións produce un número que só vale nun laboratorio con todo apagado.

Unha negativa é o momento de mirar que rexistrou a pasarela para ese intento: un evento de asignación, unha decisión de admisión ou unha chamada de autenticación atascada. Eses tres producen correccións distintas, e adiviñar desde o lado do cliente raramente escolle a correcta.

Atribúe a negativa antes de cambiar nada

A comparación útil é entre os tres recontos e o fallo observado. Se o pool está cheo, amplíao e actualiza as rutas e a política que o describen. Se se rexeita a admisión mentres quedan enderezos, a restrición está noutro sitio. Se se admiten sesións e o rendemento derrúbase, o problema é a capacidade e non ningún dos dous límites.

Anota que reconto se esgotou, cando ocorreu e que cambiou despois. Ese rexistro evita que a seguinte investigación volva comezar pola máscara de subrede.

Ampliar un pool é un cambio dunha liña cun seguimento de tres partes: rutas, política e unha nova proba.