Um pool VPN maior não é um limite de sessões maior
Um /22 contém 1,024 endereços, não 1,024 sessões. Conte o pool, a licença e a capacidade de reencaminhamento em separado e depois associe uma recusa a um deles.
Um /22 contém 1,024 endereços IPv4, e esse número confunde-se facilmente com capacidade. Descreve quantas atribuições o intervalo pode suportar, não quantas sessões o gateway vai admitir ou quanto tráfego consegue reencaminhar. Por trás de qualquer resposta estão três contagens separadas, e falham de formas diferentes. É a comparação entre elas que permite atribuir uma recusa à contagem certa.
O pool, o direito e a carga de trabalho contam-se em unidades diferentes e por donos diferentes.
O que o pool oferece realmente
Comece pelos limites efetivos em vez da máscara. A topologia da sub-rede decide quantos endereços o servidor pode distribuir, as atribuições fixas e as reservas consomem alguns, e os endereços de rede e de difusão não estão disponíveis. Um /22 oferece 1,024 em princípio e menos na prática, o que já basta para quebrar a aritmética que as pessoas esperam. A sobreposição com redes que os clientes têm de alcançar pode excluir um intervalo que parecia generoso. Verifique se o mecanismo de atribuição suporta o intervalo proposto antes de o anunciar.
Um pool maior elimina exatamente uma restrição. Não toca nos limites de admissão, nas licenças nem na capacidade de reencaminhamento, e ampliar uma sub-rede deixando as rotas e a política de acesso inalteradas produz um intervalo a que ninguém chega.
O que a licença permite realmente
A concorrência suportada pela plataforma e o direito do produto são mais dois números, e muitas vezes não coincidem. Os direitos podem contar utilizadores, dispositivos ou sessões simultâneas, e essas medidas não são intermutáveis. Os guias de encomenda dos fornecedores mostram o quão diferentes podem ser os modelos, e é por isso que o número de pares de uma ficha técnica antiga não deve ser transportado para uma nova instalação. Leia o acordo que se aplica ao serviço que realmente opera.
Uma licença que conta utilizadores nomeados não admite mais dispositivos só porque o pool tem espaço.
O que o gateway consegue realmente suportar
A terceira contagem é a carga de trabalho. Estime o tráfego que essas sessões geram em conjunto: ritmos de pacotes, picos de autenticação, custo de cifragem e as funcionalidades de política que estejam ativas. As sessões interativas e as transferências massivas aterram de forma muito diferente na mesma máquina. Um gateway pode ter endereços livres e admissão licenciada disponível enquanto a carga prevista excede o que consegue reencaminhar. O planeamento de capacidade que ignora o conjunto de funcionalidades produz um número que só é válido num laboratório com tudo desligado.
Uma recusa é o momento de olhar para o que o gateway registou para essa tentativa: um evento de atribuição, uma decisão de admissão ou uma chamada de autenticação bloqueada. Estes três exigem correções diferentes, e adivinhar do lado do cliente raramente escolhe a certa.
Atribua a recusa antes de mudar alguma coisa
A comparação útil é entre as três contagens e a falha observada. Se o pool está cheio, amplie-o e atualize as rotas e a política que o descrevem. Se a admissão é recusada enquanto restam endereços, a restrição está noutro lugar. Se as sessões são admitidas e o desempenho colapsa, o problema é a capacidade e não qualquer um dos dois limites.
Registe qual contagem se esgotou, quando aconteceu e o que mudou depois. Esse registo evita que a investigação seguinte volte a começar pela máscara de sub-rede.
Ampliar um pool é uma alteração de uma linha com um seguimento em três partes: rotas, política e um novo teste.