Server OpenVPN s nopool: deklarujte explicitní rozsah poolu

Pomocníci serveru nakonfigurují podsíť a pak ji naplní dynamickým poolem podle vlastního výběru. Tento výchozí stav je pohodlný, dokud musí některé adresy zůstat mimo přidělování — ať už jsou vyhrazené pro pevná přiřazení, nebo zadržené pro budoucí segment. Potlačení automatického poolu a vlastní deklarace rozsahu vyžaduje dva řádky a jedno vědomé rozhodnutí o tom, které adresy nejsou k přidělení. Zbytek je provozní disciplína: inventura, nasazení, ověření, návrat.

Jde o změnu běžící služby, proto k ní přistupujte jako k provoznímu úkolu: nejprve inventura, nasazení běžným životním cyklem, ověření novým klientem a připravený návrat.

Začněte od podsítě, kterou už máte

Přečtěte si aktuální konfiguraci serveru a adresy, které klienti skutečně drží. Změna poolu má smysl jen vůči této základně a základna není vždy to, co soubor naznačuje, protože spravovaný produkt nebo generátor konfigurace může vlastnit soubor, který čtete.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Potvrďte platnou topologii. V topologii podsítě si každý klient bere jednu adresu z poolu; starší uspořádání net30 přidělují každému klientovi malý blok a aritmetika je úplně jiná. Pokud server stále běží na net30, tato stránka je špatný průvodce migrací a čísla poolu nebudou znamenat to, co očekáváte. Zkontrolujte tento řádek, než odjinud zkopírujete aritmetiku adres.

Zapište vlastní adresu serveru, každé pevné přiřazení v adresáři klientských konfigurací a každou adresu, na které závisí trasa nebo pravidlo přístupu. To jsou adresy, které musí zůstat mimo dynamický rozsah. Právě jejich první zapsání dělá z rozsahu rozhodnutí místo odhadu. Dává také návratu něco konkrétního k obnovení.

Přidejte nopool a deklarujte rozsah

Pomocné klíčové slovo přijímá nopool, které zachová konfiguraci podsítě a potlačí automatický dynamický pool, jak popisuje příručka OpenVPN 2.6. Explicitní řádek ifconfig-pool pak dodá zahrnutý rozsah, který zamýšlíte, a jeho maska sítě odpovídá podsíti. Oba řádky patří do stejného bloku serveru, protože pool bez své podsítě nemá smysl. Pořadí mezi nimi je důležité jen pro čitelnost, protože pomocník dvojici rozvine při startu služby.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Obě meze jsou včetně, takže příklad nabízí sedmdesát jedna adres. Držte adresu serveru a každé pevné přiřazení mimo tento rozsah; pevné přiřazení, které spadne dovnitř dynamického rozsahu, vytváří kolizi závislou na pořadí připojení, což je nejhorší druh k ladění. Pokud pevná přiřazení pravděpodobně porostou, nechte mezi vyhrazenou množinou a rozsahem rezervu.

Velikost rozsahu a souběžnost jsou oddělené limity. Sto adres neznamená sto současných klientů, pokud max-clients říká něco jiného, a pool větší než limit souběžnosti je normální, ne plýtvání. Důležité je, že se oba limity volí vědomě, místo aby se dědily z výchozí hodnoty.

Držte pevná přiřazení mimo dynamický rozsah

Klientský ifconfig-push je jiný mechanismus než přidělování z poolu a musí používat parametry odpovídající aktivní topologii. V režimu podsítě jde o jednu adresu a masku sítě; přenos dvojice net30 jen proto, že se objevila ve starém příkladu, je častá chyba.

Historie přidělení je nápověda, ne autorita. Soubor persist si pamatuje, který klient měl kterou adresu, takže klienti, kteří se znovu připojují, obvykle dostanou stejnou, a adresy nerezervuje, neuvolňuje ani nenahrazuje pevné přiřazení. Pokud konkrétní zařízení musí vždy držet konkrétní adresu, použijte pevné přiřazení, místo abyste spoléhali na soubor persist.

Potom zkontrolujte cesty, které na adresách závisí. Trasa protlačená klientům, pravidlo firewallu, které propouští podsíť, nebo monitorovací kontrola očekávající konkrétního hostitele mohou předpokládat starý rozsah. Změna poolu bez jejich přečtení přesouvá selhání na místo, které vypadá nesouvisele.

Nasaďte přes životní cyklus a pak ověřte

Nasazení proveďte tak, jak služba obvykle dostává konfiguraci — ať už přímý soubor a restart, nebo správcovská vrstva, která soubor znovu generuje. Ruční úprava generovaného souboru přežije do příští generace a ne déle. Zaznamenejte, který mechanismus soubor vlastní, protože příští operátor bude muset vědět, kde udělat stejnou změnu. Potom jednou restartujte a přečtěte log, než pozvete klienta.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Připojte klienta, který se předtím nepřipojoval, a potvrďte, že adresa spadá do deklarovaného rozsahu a mimo vyhrazenou množinu. Potom potvrďte zpáteční cestu: klient by měl dosáhnout toho, co politika dovoluje, a nic víc. Adresa, která odpovídá plánu, ale nemá funkční trasu, není úspěšná změna.

Znovu připojte klienta, který držel adresu ze starého rozsahu. Měl by dostat adresu z nového rozsahu a jakýkoli stav na úrovni relace vázaný na starou adresu by měl zmizet. Pokud si starou adresu ponechá, přiděluje mu ji něco jiného a pool není vlastník, kterého si myslíte.

Návrat změny rozsahu

Uchovejte předchozí tři řádky ve svém záznamu o změně, ne jen předchozí soubor. Jejich obnovení a restart vrátí přidělování ke starému chování a klienti, kteří se potom připojí, dostanou adresy z něj.

Do záznamu patří dvě upozornění. Klienti už připojení v okamžiku návratu si ponechají současné adresy, dokud se znovu nepřipojí, takže návrat není okamžitý pro celou flotilu. A pokud se starý rozsah překrýval s pevným přiřazením, obnovení vrátí i kolizi; právě to překrytí bylo důvodem změny a vyžaduje jiné řešení než návrat.

Změna poolu je hotová, když nový klient dostane adresu v rozsahu, vyhrazená adresa se nikdy nevydá a trasy a pravidla, které tyto adresy spotřebovávají, se stále chovají podle záměru. Cokoli méně nechává na dalším člověku, aby zjistil, které ze tří neplatí.