Зошто /24 мрежа на OpenVPN ги исцрпува клиентите порано од очекуваното

Базени изградени на /24 што престануваат да примаат клиенти кај шеесеттите се однесуваат како што е проектирано, а не удираат во лиценцен лимит. Со net30 на секој клиент му се дава виртуелна точка-до-точка врска што троши четири адреси, така што подмрежа од 256 адреси поддржува приближно една четвртина од она што го навестува префиксот. Бројот што е важен се распределбите, а не адресите. Читањето на префиксот како број на клиенти е грешката што предизвикува барање на скриен лимит на корисници.

Две топологии, два аритметички модели и само еден од нив одговара на префиксот што луѓето го претпоставуваат.

net30 троши четири адреси по клиент

net30 доделува /30 блок на секој клиент, бидејќи секоја сесија се моделира како точка-до-точка врска со адреса на секој крај. Во тој блок влегуваат четири адреси, а две се употребливи, поради што ефективниот број на клиенти е една четвртина од подмрежата. На /24 тоа остава 64 блокови пред да излезат сопствениот блок на серверот и сите фиксни доделувања. Пријавениот горен праг околу 63 е аритметика што се покажува, а не конфигуриран максимум.

И серверот има потреба од сопствена распределба, а статичните записи за клиенти трошат блокови без оглед на тоа дали тие клиенти се поврзуваат. И двете го намалуваат динамичкиот опсег без да го менуваат префиксот со кој почнавте.

Границите на базенот се поважни од префиксот

Серверската директива може да дефинира базен потесен од подмрежата што ја именува, а помошната скрипта може да се прошири во дополнителни поставки што не се видливи во профилот што сте го отвориле. Фиксните адреси од client-config директориумот стојат во тој опсег и не можат да се издадат двапати. Префиксот го опишува максималниот можен простор; ефективниот базен е она што конфигурацијата што работи навистина го нуди.

Споредете ги двете пред да заклучите нешто за капацитетот, бидејќи помал конфигуриран опсег го објаснува прагот исто толку добро колку топологијата.

Најдете го лимитот што навистина го одбил клиентот

Прво прочитајте ја топологијата и ефективниот базен, потоа земете ги предвид фиксните доделувања и резервираните адреси. Пред да го обвините адресниот простор, проверете max-clients и секоја контрола на приемот надвор од OpenVPN. На крајот, споредете ја сопствената порака на серверот во моментот на одбивањето со тие кандидати. Пораката го именува ограничувањето; бројот само го стеснува полето.

Одбивање што доаѓа со грешка во истовременоста и одбивање што доаѓа со грешка во распределбата имаат различни поправки, а погодувањето меѓу нив троши работен прозорец за одржување.

Промената на топологијата го менува планот за адреси

Преминот кон подмрежна топологија му дава на секој клиент една адреса наместо блок, што е вистинскиот чекор кога префиксот е навистина премал. Тоа менува и што значат параметрите за адреса на клиентот, така што секоја закачена распределба и секоја датотека специфична за клиентот мора да се изведат повторно, а не да се пренумерираат рачно. Планирајте го новиот опсег, преместете ги статичните записи и ажурирајте ги маршрутите што се однесуваат на нив.

Преминот не е синоним за старата конфигурација. Третирајте го како промена на планот за адреси со сопствена проверка и очекувајте барем еден клиент да задржи адреса од претходната шема.

Димензионирајте го базенот според планот, а не според маската

Изберете ја големината според бројот на истовремени клиенти плус простор за повторни поврзувања и тестирање, па изберете го најмалиот префикс што го покрива според избраната топологија. Проширувањето до /16 за да се реши прагот од шеесет клиенти ја заменува проблема со капацитетот со проблем со рутирање и преклопување, бидејќи поголем приватен опсег е поверојатно да се судри со нешто што клиентот веќе го достигнува.

Документирајте ги заедно топологијата, базенот, фиксните доделувања и добиениот праг на клиенти. Следното прашање за капацитетот тогаш е аритметика наместо истрага.