Proč OpenVPN /24 dojde s klienty dřív, než čekáte

Pooly postavené na /24, které přestanou přijímat klienty kolem šedesátky, se chovají podle návrhu a nenarazí na licenční limit. Při net30 dostane každý klient virtuální spojení bod-bod, které spotřebuje čtyři adresy, takže podsíť s 256 adresami podporuje zhruba čtvrtinu toho, co prefix naznačuje. Důležitý je počet alokací, ne adres. Číst prefix jako počet klientů je chyba, která vede k hledání skrytého limitu uživatelů.

Dvě topologie, dva aritmetické modely a jen jeden z nich odpovídá prefixu, který lidé předpokládají.

net30 spotřebuje čtyři adresy na klienta

net30 přiděluje každému klientovi blok /30, protože každá relace se modeluje jako spojení bod-bod s adresou na každém konci. Do toho bloku jdou čtyři adresy a dvě jsou použitelné, proto je efektivní počet klientů čtvrtina podsítě. Na /24 to ponechá 64 bloků, než přijdou na řadu vlastní blok serveru a případná pevná přiřazení. Hlášený strop kolem 63 je aritmetika, která prosakuje, ne konfigurované maximum.

Server potřebuje také vlastní alokaci a statické záznamy klientů zabírají bloky bez ohledu na to, zda se tito klienti připojí. Obojí snižuje dynamický rozsah, aniž by změnilo prefix, se kterým jste začali.

Hranice poolu jsou důležitější než prefix

Direktiva serveru může definovat pool užší než podsíť, kterou pojmenovává, a pomocný skript se může rozšířit do dalších nastavení, která v otevřeném profilu nejsou vidět. Pevné adresy z adresáře client-config leží uvnitř tohoto rozsahu a nelze je vydat dvakrát. Prefix popisuje maximální možný prostor; efektivní pool je to, co běžící konfigurace skutečně nabízí.

Porovnejte obojí, než cokoli uzavřete o kapacitě, protože menší nakonfigurovaný rozsah vysvětluje strop stejně dobře jako topologie.

Najděte limit, který klienta skutečně odmítl

Nejprve si přečtěte topologii a efektivní pool, potom zohledněte pevná přiřazení a rezervované adresy. Zkontrolujte také max-clients a jakoukoli kontrolu přístupu mimo OpenVPN, než obviníte adresní prostor. Nakonec porovnejte vlastní zprávu serveru v okamžiku odmítnutí s těmito kandidáty. Zpráva pojmenovává omezení; počet jen zužuje pole.

Odmítnutí, které přijde s chybou souběhu, a odmítnutí, které přijde s chybou alokace, mají různé opravy, a hádání mezi nimi plýtvá servisním oknem.

Změna topologie mění adresní plán

Přechod na topologii podsítě dá každému klientovi jednu adresu místo bloku, což je správný krok, když je prefix skutečně příliš malý. Mění také význam parametrů adresy klienta, takže každé připnuté přiřazení a každý soubor specifický pro klienta je nutné znovu odvodit, ne ručně přečíslovat. Naplánujte nový rozsah, přeneste statické záznamy a aktualizujte trasy, které na ně odkazují.

Přepnutí není synonymem staré konfigurace. Berte ho jako změnu adresního plánu s vlastní revizí a očekávejte, že alespoň jeden klient si podrží adresu z předchozího schématu.

Určete velikost poolu z plánu, ne z masky

Velikost vyberte z počtu souběžných klientů plus rezervy na opětovná připojení a testování, poté zvolte nejmenší prefix, který to při zvolené topologii pokryje. Rozšíření na /16 kvůli stropu šedesáti klientů mění problém kapacity za problém směrování a překryvu, protože větší privátní rozsah pravděpodobněji koliduje s něčím, co klient už dosahuje.

Zdokumentujte společně topologii, pool, pevná přiřazení a výsledný strop klientů. Další otázka kapacity je pak aritmetika místo vyšetřování.