Per què un OpenVPN /24 s’esgota de clients abans del que espereu

Els pools construïts sobre un /24 que deixen d’acceptar clients cap a la seixantena es comporten tal com estan dissenyats, no toquen cap límit de llicència. Amb net30, cada client rep un enllaç virtual punt a punt que consumeix quatre adreces, així que una subxarxa de 256 adreces suporta aproximadament una quarta part del que suggereix el prefix. El nombre que importa són les assignacions, no les adreces. Llegir el prefix com un recompte de clients és l’error que provoca la recerca d’un topall d’usuaris ocult.

Dues topologies, dos models aritmètics, i només un d’ells coincideix amb el prefix que la gent suposa.

net30 gasta quatre adreces per client

net30 assigna un bloc /30 per client, perquè cada sessió es modela com un enllaç punt a punt amb una adreça a cada extrem. En aquest bloc hi entren quatre adreces i dues són utilitzables, i per això el recompte efectiu de clients és una quarta part de la subxarxa. En un /24 això deixa 64 blocs abans que surtin el bloc propi del servidor i qualsevol assignació fixa. Un sostre reportat vora 63 és aritmètica que es transparenta, no un màxim configurat.

El servidor també necessita la seva pròpia assignació, i les entrades estàtiques de clients consumeixen blocs tant si aquests clients es connecten com si no. Totes dues coses redueixen el rang dinàmic sense canviar el prefix amb què vau començar.

Les fronteres del pool importen més que el prefix

La directiva del servidor pot definir un pool més estret que la subxarxa que anomena, i un script auxiliar es pot expandir en paràmetres addicionals que no es veuen al perfil que heu obert. Les adreces fixes d’un directori client-config seuen dins d’aquest rang i no es poden lliurar dues vegades. El prefix descriu l’espai màxim possible; el pool efectiu és el que la configuració en execució ofereix realment.

Compareu els dos abans de concloure res sobre la capacitat, perquè un rang configurat més petit explica el sostre igual de bé que la topologia.

Trobeu el límit que va rebutjar realment el client

Llegiu primer la topologia i el pool efectiu, i després tingueu en compte les assignacions fixes i les adreces reservades. Comproveu també max-clients i qualsevol control d’admissió fora d’OpenVPN abans de culpar l’espai d’adreces. Finalment, compareu el missatge propi del servidor en el moment del rebuig amb aquests candidats. El missatge anomena la restricció; el recompte només estreta el camp.

Un rebuig que arriba amb un error de concurrència i un rebuig que arriba amb un error d’assignació tenen solucions diferents, i endevinar entre ells malbarata una finestra de manteniment.

Canviar la topologia canvia el pla d’adreces

Passar a la topologia de subxarxa dona a cada client una adreça en lloc d’un bloc, que és el moviment correcte quan el prefix és realment massa petit. També canvia el que signifiquen els paràmetres d’adreça del client, així que cada assignació fixada i cada fitxer específic del client s’han de tornar a derivar en lloc de renumerar a mà. Planifiqueu el nou rang, migreu les entrades estàtiques i actualitzeu les rutes que hi fan referència.

El canvi no és un sinònim de la configuració antiga. Tracteu-lo com un canvi de pla d’adreces amb la seva pròpia revisió, i espereu que almenys un client mantingui una adreça de l’esquema anterior.

Dimensioneu el pool a partir del pla, no de la màscara

Trieu la mida a partir del nombre de clients concurrents més un marge per a reconnexions i proves, i després trieu el prefix més petit que ho cobreixi amb la topologia triada. Ampliar a un /16 per resoldre un sostre de seixanta clients canvia un problema de capacitat per un problema d’encaminament i solapament, perquè un rang privat més gran té més probabilitats de xocar amb alguna cosa que el client ja assoleix.

Documenteu alhora la topologia, el pool, les assignacions fixes i el sostre de clients resultant. La següent pregunta sobre capacitat serà llavors aritmètica en lloc d’una investigació.