Zergatik geratzen den OpenVPN /24 klienterik gabe uste baino lehenago

/24 baten gainean eraikitako poolak hirurogei inguruan klienterik onartzen ez dutenean, diseinatuta bezala ari dira, ez dute lizentzia-mugarik jotzen. net30 erabiliz, klient bakoitzak lau helbide gastatzen dituen puntu-puntuko esteka birtual bat jasotzen du, beraz 256 helbideko azpisare batek aurrizkiak iradokitzen duenaren laurden bat inguru onartzen du. Garrantzitsua den zenbakia esleipenak dira, ez helbideak. Aurrizkia kliente-kopuru gisa irakurtzea erabiltzaile-muga ezkutu baten bila hasten den akatsa da.

Bi topologia, bi kalkulu-eredu, eta horietako bakarra dator jendeak uste duen aurrizkiarekin.

net30ek lau helbide gastatzen ditu kliente bakoitzeko

net30ek /30 bloke bat esleitzen du kliente bakoitzeko, saio bakoitza mutur bakoitzean helbide bat duen puntu-puntuko esteka gisa modelatzen delako. Bloke horretan lau helbide sartzen dira eta bi erabilgarriak dira, horregatik kliente-kopuru eraginkorra azpisarearen laurdena da. /24 batean horrek 64 bloke uzten ditu zerbitzariaren beraren blokea eta esleipen finkoak atera aurretik. 63 inguruan jakinarazitako sabai bat agerian geratzen den aritmetika da, ez konfiguratutako maximoa.

Zerbitzariak bere esleipena ere behar du, eta kliente-erregistro estatikoek blokeak kontsumitzen dituzte kliente horiek konektatu ala ez. Biek eremu dinamikoa txikitzen dute, hasitako aurrizkia aldatu gabe.

Poolaren mugak aurrizkia baino garrantzitsuagoak dira

Zerbitzariaren direktibak izendatzen duen azpisarea baino pool estuagoa defini dezake, eta script laguntzaile batek irekitako profilean ikusten ez diren ezarpen gehigarrietan sar daiteke. client-config direktorioko helbide finkoak barruti horren barruan daude eta ezin dira bitan eman. Aurrizkiak ahalik eta espazio handiena deskribatzen du; pool eraginkorra martxan dagoen konfigurazioak benetan eskaintzen duena da.

Konparatu biak kapazitateari buruz ezer ondorioztatu aurretik, konfiguratutako barruti txikiago batek sabaiaren azalpena topologiak adina ematen duelako.

Bilatu klienteari benetan uko egin zion muga

Irakurri lehenik topologia eta pool eraginkorra, gero hartu kontuan esleipen finkoak eta gordetako helbideak. Gainera max-clients eta OpenVPN kanpoko onarpen-kontrol oro egiaztatu behar dituzu helbide-eremua erruduntzat jo aurretik. Azkenik, konparatu zerbitzariaren beraren mezua ukoaren unean hautagai horiekin. Mezuak muga izendatzen du; zenbakiak eremua estutu besterik ez du egiten.

Konkurrentzia-errore batekin datorren ukoak eta esleipen-errore batekin datorren ukoak konponketa desberdinak dituzte, eta bien artean asmatzeak mantentze-leiho bat alferrik galtzen du.

Topologia aldatzeak helbide-plana aldatzen du

Azpisare-topologiara aldatzea kliente bakoitzari bloke bat beharrean helbide bat ematen dio, eta hori da urrats egokia aurrizkia benetan txikiegia denean. Kliente-helbide parametroen esanahia ere aldatzen du, beraz finkatutako esleipen bakoitza eta kliente bakoitzeko fitxategi bakoitza berriro eratorri behar dira, eskuz berriz zenbatu beharrean. Planifikatu barruti berria, migratu erregistro estatikoak eta eguneratu haiei erreferentzia egiten dieten bideak.

Aldaketa ez da konfigurazio zaharraren sinonimoa. Helbide-planaren aldaketatzat hartu, berrikuspen propioarekin, eta espero ezazu kliente batek gutxienez aurreko eskemako helbide bat mantenduko duela.

Eman poolari tamaina planetik, ez maskaratik

Aukeratu tamaina aldi bereko kliente-kopurutik gehi berrezikonexioetarako eta probetarako tartea, eta gero hartu hautatutako topologiaren pean hori estaltzen duen aurrizkirik txikiena. Hirurogei klienteetako sabai bat konpontzeko /16ra zabaltzeak kapazitate-arazoa bideratze- eta gainjartze-arazoagatik aldatzen du, barruti pribatu handiago batek klienteak dagoeneko iristen duen zerbait kolpatzeko probabilitate handiagoa duelako.

Dokumentatu elkarrekin topologia, pool, esleipen finkoak eta ondoriozko kliente-sabaia. Hurrengo kapazitate-galdera aritmetika izango da, ikerketa bat izan beharrean.