Pse një /24 e OpenVPN mbaron me klientë më shpejt nga sa prisni

Pool-et e ndërtuara mbi një /24 që ndalojnë pranimin e klientëve rreth të gjashtëdhjetave sillen siç është projektuar, nuk po godasin një kufi licence. Nën net30 çdo klient merr një lidhje virtuale pikë-për-pikë që harxhon katër adresa, kështu që një nënrrjet me 256 adresa mbështet rreth një të katërtën e asaj që sugjeron prefiksi. Numri që ka rëndësi janë ndarjet, jo adresat. Leximi i prefiksit si numër klientësh është gabimi që prodhon kërkimin e një kufiri të fshehur përdoruesish.

Dy topologji, dy modele aritmetike, dhe vetëm njëri prej tyre përputhet me prefiksin që njerëzit supozojnë.

net30 harxhon katër adresa për klient

net30 ndan një bllok /30 për klient, sepse çdo sesion modelohet si një lidhje pikë-për-pikë me një adresë në çdo skaj. Në atë bllok hyjnë katër adresa dhe dy janë të përdorshme, prandaj numri efektiv i klientëve është një e katërta e nënrrjetit. Mbi një /24 kjo lë 64 blloqe përpara se të dalin blloku i vetë serverit dhe çdo caktim fiks. Një tavan i raportuar rreth 63 është aritmetikë që shfaqet, jo një maksimum i konfiguruar.

Edhe serverit i duhet ndarja e vet, dhe zërat statikë të klientëve harxhojnë blloqe pa marrë parasysh nëse ata klientë lidhen apo jo. Të dyja zvogëlojnë intervalin dinamik pa ndryshuar prefiksin me të cilin filluat.

Kufijtë e pool-it kanë më shumë rëndësi se prefiksi

Direktiva e serverit mund të përcaktojë një pool më të ngushtë se nënrrjeti që emërton, dhe një skript ndihmës mund të zgjerohet në cilësime shtesë që nuk duken në profilin që hapët. Adresat fikse nga një direktori client-config qëndrojnë brenda atij intervali dhe nuk mund të lëshohen dy herë. Prefiksi përshkruan hapësirën maksimale të mundshme; pool-i efektiv është ajo që konfigurimi në punë ofron në të vërtetë.

Krahasoji të dyja përpara se të nxirrni ndonjë përfundim për kapacitetin, sepse një interval më i vogël i konfiguruar e shpjegon tavanin po aq mirë sa topologjia.

Gjej kufirin që e refuzoi vërtet klientin

Lexo fillimisht topologjinë dhe pool-in efektiv, pastaj merr parasysh caktimet fikse dhe adresat e rezervuara. Përpara se të fajësosh hapësirën e adresave, kontrollo max-clients dhe çdo kontroll pranimi jashtë OpenVPN. Së fundi, krahaso mesazhin e vetë serverit në momentin e refuzimit me ata kandidatë. Mesazhi emërton kufizimin; numri vetëm e ngushton fushën.

Një refuzim që vjen me një gabim njëkohësie dhe një refuzim që vjen me një gabim ndarjeje kanë rregullime të ndryshme, dhe hamendësimi mes tyre harxhon një dritare mirëmbajtjeje.

Ndryshimi i topologjisë ndryshon planin e adresave

Kalimi në topologjinë e nënrrjetit i jep çdo klienti një adresë në vend të një blloku, që është hapi i duhur kur prefiksi është vërtet shumë i vogël. Ndryshon edhe çfarë kuptojnë parametrat e adresës së klientit, prandaj çdo caktim i gozhduar dhe çdo skedar specifik i klientit duhet të nxirret përsëri, jo të rinumërohet me dorë. Planifiko intervalin e ri, migro zërat statikë dhe përditëso rrugët që i referohen.

Kalimi nuk është sinonim i konfigurimit të vjetër. Trajtoje si një ndryshim të planit të adresave me rishikimin e vet, dhe prit që të paktën një klient të mbajë një adresë nga skema e mëparshme.

Përcakto madhësinë e pool-it nga plani, jo nga maska

Zgjidh madhësinë nga numri i klientëve njëkohësisht plus hapësirë për rilidhje dhe testime, pastaj zgjidh prefiksin më të vogël që e mbulon nën topologjinë e zgjedhur. Zgjerimi në një /16 për të zgjidhur një tavan prej gjashtëdhjetë klientësh e këmben një problem kapaciteti me një problem rrugëtimi dhe mbivendosjeje, sepse një interval privat më i madh ka më shumë gjasa të përplaset me diçka që klienti tashmë e arrin.

Dokumento së bashku topologjinë, pool-in, caktimet fikse dhe tavanin e klientëve që rezulton. Pyetja tjetër e kapacitetit bëhet atëherë aritmetikë në vend të një hetimi.