Kial OpenVPN /24 elĉerpiĝas je klientoj pli frue ol vi atendas

Pool-oj konstruitaj sur /24, kiuj ĉesas akcepti klientojn ĉe proksimume sesdek, kondutas laŭ la dezajno, ne trafas licencan limon. Ĉe net30 ĉiu kliento ricevas virtualan punkt-al-punktan ligilon, kiu konsumas kvar adresojn, do subreto de 256 adresoj subtenas proksimume kvaronon de tio, kion sugestas la prefikso. La nombro, kiu gravas, estas atribuoj, ne adresoj. Legi la prefikson kiel klientan nombron estas la eraro, kiu kaŭzas serĉadon de kaŝita uzantlimo.

Du topologioj, du aritmetikaj modeloj, kaj nur unu el ili kongruas kun la prefikso, kiun homoj supozas.

net30 elspezas kvar adresojn por kliento

net30 atribuas blokon /30 por kliento, ĉar ĉiu sesio estas modeligata kiel punkt-al-punkta ligilo kun adreso ĉe ĉiu fino. Kvar adresoj eniras tiun blokon kaj du estas uzeblaj, tial la efektiva klienta nombro estas kvarono de la subreto. Sur /24 tio lasas 64 blokojn antaŭ ol la propra bloko de la servilo kaj eventualaj fiksaj atribuoj eliras. Raportita plafono proksime al 63 estas aritmetiko, kiu trabrilas, ne agordita maksimumo.

La servilo ankaŭ bezonas sian propran atribuon, kaj statikaj klientaj enskriboj konsumas blokojn sendepende de tio, ĉu tiuj klientoj konektiĝas. Ambaŭ malpliigas la dinamikan intervalon sen ŝanĝi la prefikson, kun kiu vi komencis.

La limoj de la pool gravas pli ol la prefikso

La servila direktivo povas difini pool pli mallarĝan ol la subreto, kiun ĝi nomas, kaj helposkripto povas etendiĝi al pliaj agordoj, kiuj ne videblas en la profilo, kiun vi malfermis. Fiksaj adresoj el dosierujo client-config sidas ene de tiu intervalo kaj ne povas esti donitaj dufoje. La prefikso priskribas la maksimuman eblan spacon; la efektiva pool estas tio, kion la kuranta agordo efektive proponas.

Komparu la du antaŭ ol konkludi ion pri kapacito, ĉar pli malgranda agordita intervalo klarigas la plafonon same bone kiel la topologio.

Trovu la limon, kiu efektive rifuzis la klienton

Unue legu la topologion kaj la efektivan pool, poste enkalkulu fiksajn atribuojn kaj rezervitajn adresojn. Kontrolu ankaŭ max-clients kaj ajnan akceptokontrolon ekster OpenVPN antaŭ ol kulpigi la adresan spacon. Fine, kongruigu la propran mesaĝon de la servilo en la momento de la rifuzo kun tiuj kandidatoj. La mesaĝo nomas la limigon; la nombro nur mallarĝigas la kampon.

Rifuzo, kiu alvenas kun samtempeca eraro, kaj rifuzo, kiu alvenas kun atribua eraro, havas malsamajn riparojn, kaj diveni inter ili malŝparas prizorgan fenestron.

Ŝanĝi la topologion ŝanĝas la adresan planon

Ŝalti al subreta topologio donas al ĉiu kliento unu adreson anstataŭ blokon, kio estas la ĝusta movo, kiam la prefikso vere estas tro malgranda. Ĝi ankaŭ ŝanĝas, kion signifas la klientaj adresaj parametroj, do ĉiu fiksita atribuo kaj ĉiu klient-specifa dosiero devas esti denove derivitaj anstataŭ mane renumeritaj. Planu la novan intervalon, migru la statikajn enskribojn kaj ĝisdatigu la itinerojn, kiuj referencas ilin.

La ŝalto ne estas sinonimo de la malnova agordo. Traktu ĝin kiel ŝanĝon de la adresa plano kun propra revizio, kaj atendu, ke almenaŭ unu kliento tenos adreson el la antaŭa skemo.

Grandigu la pool laŭ la plano, ne laŭ la masko

Elektu la grandecon laŭ la nombro de samtempaj klientoj plus rezervo por rekonektoj kaj testado, poste prenu la plej malgrandan prefikson, kiu kovras tion sub la elektita topologio. Etendi al /16 por solvi plafonon de sesdek klientoj interŝanĝas kapacitan problemon kontraŭ itineran kaj interkovran problemon, ĉar pli granda privata intervalo pli verŝajne kolizias kun io, kion la kliento jam atingas.

Dokumentu kune la topologion, la pool, la fiksajn atribuojn kaj la rezultantan klientan plafonon. La sekva kapacita demando tiam estas aritmetiko anstataŭ enketo.