Por que un OpenVPN /24 queda sen clientes antes do que esperas

Os pools construídos sobre un /24 que deixan de aceptar clientes arredor dos sesenta compórtanse como foron deseñados, non chocan cun límite de licenza. Con net30, cada cliente recibe unha ligazón virtual punto a punto que consume catro enderezos, así que unha subrede de 256 enderezos soporta aproximadamente unha cuarta parte do que suxire o prefixo. O número que importa son as asignacións, non os enderezos. Ler o prefixo como un reconto de clientes é o erro que provoca a busca dun tope de usuarios agochado.

Dúas topoloxías, dous modelos aritméticos, e só unha delas coincide co prefixo que a xente supón.

net30 gasta catro enderezos por cliente

net30 asigna un bloque /30 por cliente, porque cada sesión se modela como unha ligazón punto a punto cun enderezo en cada extremo. Nese bloque entran catro enderezos e dous son utilizables, polo que o reconto efectivo de clientes é unha cuarta parte da subrede. Nun /24 iso deixa 64 bloques antes de que saian o bloque propio do servidor e calquera asignación fixa. Un teito reportado preto de 63 é aritmética que se transparenta, non un máximo configurado.

O servidor tamén necesita a súa propia asignación, e as entradas estáticas de clientes consomen bloques tanto se eses clientes se conectan como se non. Ambas as dúas cousas reducen o rango dinámico sen cambiar o prefixo co que comezaches.

Os límites do pool importan máis que o prefixo

A directiva do servidor pode definir un pool máis estreito que a subrede que nomea, e un script auxiliar pode expandirse en parámetros adicionais que non se ven no perfil que abriches. Os enderezos fixos dun directorio client-config sentan dentro dese rango e non se poden entregar dúas veces. O prefixo describe o espazo máximo posible; o pool efectivo é o que a configuración en execución ofrece realmente.

Compara os dous antes de concluír nada sobre a capacidade, porque un rango configurado máis pequeno explica o teito igual de ben que a topoloxía.

Atopa o límite que realmente rexeitou o cliente

Le primeiro a topoloxía e o pool efectivo, e despois ten en conta as asignacións fixas e os enderezos reservados. Revisa tamén max-clients e calquera control de admisión fóra de OpenVPN antes de culpar o espazo de enderezos. Por último, compara a mensaxe propia do servidor no momento do rexeitamento con eses candidatos. A mensaxe nomea a restrición; o reconto só estreita o campo.

Un rexeitamento que chega cun erro de concorrencia e un rexeitamento que chega cun erro de asignación teñen solucións distintas, e adiviñar entre eles desperdicia unha xanela de mantemento.

Cambiar a topoloxía cambia o plan de enderezos

Pasar á topoloxía de subrede dá a cada cliente un enderezo en lugar dun bloque, que é o movemento correcto cando o prefixo é realmente demasiado pequeno. Tamén cambia o que significan os parámetros de enderezo do cliente, así que cada asignación fixada e cada ficheiro específico do cliente deben derivarse de novo en lugar de renumerarse a man. Planifica o novo rango, migra as entradas estáticas e actualiza as rutas que fan referencia a elas.

O cambio non é sinónimo da configuración anterior. Trátao como un cambio de plan de enderezos coa súa propia revisión, e espera que polo menos un cliente manteña un enderezo do esquema anterior.

Dimensiona o pool a partir do plan, non da máscara

Escolle o tamaño a partir do número de clientes concorrentes máis unha marxe para reconexións e probas, e despois escolle o prefixo máis pequeno que o cubra coa topoloxía elixida. Ampliar a un /16 para resolver un teito de sesenta clientes cambia un problema de capacidade por un problema de encamiñamento e solapamento, porque un rango privado máis grande ten máis probabilidades de chocar con algo que o cliente xa alcanza.

Documenta á vez a topoloxía, o pool, as asignacións fixas e o teito de clientes resultante. A seguinte pregunta sobre capacidade será entón aritmética en lugar dunha investigación.