Kāpēc OpenVPN /24 klientus izsmeļ agrāk, nekā gaidīts

Koppooli, kas būvēti uz /24 un pārstāj pieņemt klientus ap sešdesmit, darbojas tā, kā projektēts, nevis sasniedz licences limitu. Izmantojot net30, katram klientam tiek piešķirts virtuāls punkts-punktam savienojums, kas patērē četras adreses, tāpēc 256 adrešu apakštīkls atbalsta aptuveni ceturtdaļu no tā, ko liecina prefikss. Svarīgais skaitlis ir piešķīrumi, nevis adreses. Prefiksa lasīšana kā klientu skaita ir kļūda, kas liek meklēt slēptu lietotāju limitu.

Divas topoloģijas, divi aritmētiskie modeļi, un tikai viens no tiem atbilst prefiksam, ko cilvēki pieņem.

net30 patērē četras adreses uz klientu

net30 katram klientam piešķir /30 bloku, jo katra sesija tiek modelēta kā punkts-punktam savienojums ar adresi abos galos. Šajā blokā ietilpst četras adreses, un divas ir izmantojamas, tāpēc faktiskais klientu skaits ir ceturtdaļa no apakštīkla. /24 gadījumā tas atstāj 64 blokus, pirms iznāk paša servera bloks un jebkuri fiksētie piešķīrumi. Ziņotie griesti ap 63 ir aritmētika, kas izpaužas, nevis konfigurēts maksimums.

Arī serverim vajadzīgs savs piešķīrums, un statiskie klientu ieraksti patērē blokus neatkarīgi no tā, vai šie klienti pieslēdzas. Abi samazina dinamisko diapazonu, nemainot prefiksu, ar kuru sākāt.

Koppoola robežas ir svarīgākas par prefiksu

Servera direktīva var definēt koppoolu šaurāku par apakštīklu, ko tā nosauc, un palīgskripts var izvērsties papildu iestatījumos, kas nav redzami atvērtajā profilā. Fiksētās adreses no client-config direktorijas atrodas šajā diapazonā, un tās nevar izsniegt divreiz. Prefikss apraksta maksimālo iespējamo telpu; efektīvais koppools ir tas, ko darbojošā konfigurācija faktiski piedāvā.

Salīdziniet abus, pirms izdarāt kādu secinājumu par ietilpību, jo mazāks konfigurētais diapazons izskaidro griestus tikpat labi kā topoloģija.

Atrodiet limitu, kas klientam faktiski atteica

Vispirms izlasiet topoloģiju un efektīvo koppoolu, pēc tam ņemiet vērā fiksētos piešķīrumus un rezervētās adreses. Pirms vainot adrešu telpu, pārbaudiet max-clients un jebkuru piekļuves kontroli ārpus OpenVPN. Visbeidzot, salīdziniet paša servera ziņojumu atteikuma brīdī ar šiem kandidātiem. Ziņojums nosauc ierobežojumu; skaits tikai sašaurina lauku.

Atteikums, kas nāk ar vienlaicības kļūdu, un atteikums, kas nāk ar piešķīruma kļūdu, prasa dažādus labojumus, un minēšana starp tiem izšķiež apkopes logu.

Topoloģijas maiņa maina adrešu plānu

Pāreja uz apakštīkla topoloģiju katram klientam dod vienu adresi bloka vietā, un tas ir pareizais solis, ja prefikss patiešām ir pārāk mazs. Tas maina arī to, ko nozīmē klienta adreses parametri, tāpēc katrs piesaistītais piešķīrums un katra klientam raksturīgā datne ir jāatvasina no jauna, nevis jāpārnumurē ar roku. Izplānojiet jauno diapazonu, migrējiet statiskos ierakstus un atjauniniet maršrutus, kas uz tiem atsaucas.

Pāreja nav vecās konfigurācijas sinonīms. Uztveriet to kā adrešu plāna izmaiņu ar savu pārskatīšanu un gaidiet, ka vismaz viens klients saglabās iepriekšējās shēmas adresi.

Koppoola lielumu nosakiet no plāna, nevis no maskas

Izvēlieties lielumu pēc vienlaicīgo klientu skaita plus rezerves atkalpieslēgšanās un testēšanai, pēc tam izvēlieties mazāko prefiksu, kas to nosedz izvēlētajā topoloģijā. Paplašināšana līdz /16, lai atrisinātu sešdesmit klientu griestus, apmaina ietilpības problēmu pret maršrutēšanas un pārklāšanās problēmu, jo lielāks privātais diapazons biežāk saduras ar kaut ko tādu, ko klients jau sasniedz.

Kopā dokumentējiet topoloģiju, koppoolu, fiksētos piešķīrumus un izrietošos klientu griestus. Tad nākamais ietilpības jautājums būs aritmētika, nevis izmeklēšana.