Porque um /24 de OpenVPN fica sem clientes mais cedo do que espera

Pools construídas sobre um /24 que deixam de aceitar clientes por volta dos sessenta comportam-se como projetado, não estão a atingir um limite de licença. No net30 cada cliente recebe uma ligação virtual ponto-a-ponto que consome quatro endereços, por isso uma sub-rede de 256 endereços suporta cerca de um quarto do que o prefixo sugere. O número que importa são as alocações, não os endereços. Ler o prefixo como número de clientes é o erro que produz a procura de um limite de utilizadores escondido.

Duas topologias, dois modelos aritméticos, e apenas um deles corresponde ao prefixo que as pessoas assumem.

o net30 gasta quatro endereços por cliente

O net30 atribui um bloco /30 por cliente, porque cada sessão é modelada como uma ligação ponto-a-ponto com um endereço em cada extremidade. Nesse bloco entram quatro endereços e dois são utilizáveis, razão pela qual o número efetivo de clientes é um quarto da sub-rede. Num /24 isso deixa 64 blocos antes de saírem o próprio bloco do servidor e quaisquer atribuições fixas. Um teto reportado perto de 63 é aritmética a aparecer, não um máximo configurado.

O servidor também precisa da sua própria alocação, e as entradas estáticas de clientes consomem blocos quer esses clientes se liguem quer não. Ambos reduzem o intervalo dinâmico sem alterar o prefixo com que começou.

Os limites da pool importam mais do que o prefixo

A diretiva do servidor pode definir uma pool mais estreita do que a sub-rede que nomeia, e um script auxiliar pode expandir-se em definições adicionais que não são visíveis no perfil que abriu. Endereços fixos de um diretório client-config ficam dentro desse intervalo e não podem ser entregues duas vezes. O prefixo descreve o espaço máximo possível; a pool efetiva é o que a configuração em execução realmente oferece.

Compare os dois antes de concluir algo sobre capacidade, porque um intervalo configurado mais pequeno explica o teto tão bem como a topologia.

Encontre o limite que realmente recusou o cliente

Leia primeiro a topologia e a pool efetiva, depois contabilize as atribuições fixas e os endereços reservados. Antes de culpar o espaço de endereços, verifique max-clients e qualquer controlo de admissão fora do OpenVPN. Por fim, confronte a mensagem do próprio servidor no momento da recusa com esses candidatos. A mensagem nomeia a restrição; a contagem apenas estreita o campo.

Uma recusa que chega com um erro de concorrência e uma recusa que chega com um erro de alocação têm correções diferentes, e adivinhar entre elas desperdiça uma janela de manutenção.

Mudar de topologia muda o plano de endereços

Mudar para a topologia de sub-rede dá a cada cliente um endereço em vez de um bloco, que é o passo certo quando o prefixo é genuinamente pequeno demais. Também muda o que os parâmetros de endereço do cliente significam, por isso cada atribuição fixada e cada ficheiro específico do cliente tem de ser rederivado em vez de renumerado à mão. Planeie o novo intervalo, migre as entradas estáticas e atualize as rotas que se referem a elas.

A mudança não é sinónimo da configuração antiga. Trate-a como uma alteração ao plano de endereços com a sua própria revisão, e espere que pelo menos um cliente mantenha um endereço do esquema anterior.

Dimensione a pool a partir do plano, não da máscara

Escolha o tamanho a partir do número de clientes simultâneos mais margem para reconexões e testes, e depois escolha o prefixo mais pequeno que o cobre na topologia escolhida. Alargar para um /16 para resolver um teto de sessenta clientes troca um problema de capacidade por um problema de encaminhamento e sobreposição, porque um intervalo privado maior tem mais probabilidade de colidir com algo que o cliente já alcança.

Documente em conjunto a topologia, a pool, as atribuições fixas e o teto de clientes resultante. A questão de capacidade seguinte passa então a ser aritmética em vez de investigação.