Pomocníci servera nakonfigurujú podsiet a potom ju naplnia dynamickým poolom podľa vlastného výberu. Tento predvolený stav je pohodlný dovtedy, kým niektoré adresy musia zostať mimo prideľovania — či už sú vyhradené pre pevné priradenia alebo zadržané pre budúci segment. Potlačenie automatického poolu a vlastné deklarovanie rozsahu si vyžaduje dva riadky a jedno vedomé rozhodnutie o tom, ktoré adresy nie sú na prideľovanie. Zvyšok je prevádzková disciplína: inventúra, nasadenie, overenie, návrat.

Toto je zmena bežiacej služby, preto k nej pristupujte ako k prevádzkovej úlohe: najprv inventúra, potom nasadenie bežným životným cyklom, overenie novým klientom a pripravený návrat.

Začnite od podsiete, ktorú už máte

Prečítajte si aktuálnu konfiguráciu servera a adresy, ktoré klienti skutočne držia. Zmena poolu má zmysel len voči tejto základni a základňa nie je vždy to, čo naznačuje súbor, pretože spravovaný produkt alebo generátor konfigurácie môže vlastniť súbor, ktorý čítate.

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

Potvrďte platnú topológiu. V topológii podsiete si každý klient berie jednu adresu z poolu; staršie usporiadania net30 prideľujú každému klientovi malý blok a aritmetika je úplne iná. Ak server stále beží na net30, táto stránka je nesprávny sprievodca migráciou a čísla poolu nebudú znamenať to, čo očakávate. Skontrolujte ten riadok, než odinakiaľ skopírujete aritmetiku adries.

Zapíšte vlastnú adresu servera, každé pevné priradenie v adresári klientskych konfigurácií a každú adresu, od ktorej závisí trasa alebo pravidlo prístupu. To sú adresy, ktoré musia zostať mimo dynamického rozsahu. Práve ich prvé zapísanie robí z rozsahu rozhodnutie namiesto odhadu. Dáva tiež návratu niečo konkrétne na obnovenie.

Pridajte nopool a deklarujte rozsah

Pomocné kľúčové slovo prijíma nopool, ktoré zachová konfiguráciu podsiete a potlačí automatický dynamický pool, ako opisuje príručka OpenVPN 2.6. Explicitný riadok ifconfig-pool potom dodá zamýšľaný rozsah vrátane a jeho sieťová maska zodpovedá podsieti. Oba riadky patria do toho istého bloku servera, pretože pool bez svojej podsiete nemá zmysel. Poradie medzi nimi je dôležité len pre čitateľnosť, pretože pomocník dvojicu rozvinie pri štarte 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

Obe hranice sú vrátane, takže príklad ponúka sedemdesiatjeden adries. Držte adresu servera a každé pevné priradenie mimo tohto rozpätia; pevné priradenie, ktoré spadne do dynamického rozsahu, vytvára kolíziu závislú od poradia pripojení, a to je najhorší druh na ladenie. Ak pevné priradenia pravdepodobne porastú, nechajte medzi vyhradenou množinou a rozsahom rezervu.

Veľkosť rozsahu a súbežnosť sú oddelené limity. Sto adries neznamená sto súčasných klientov, ak max-clients hovorí niečo iné, a pool väčší ako limit súbežnosti je normálny, nie plytvanie. Dôležité je, že sa oba limity volia vedome, namiesto toho aby sa dedili z predvolenej hodnoty.

Držte pevné priradenia mimo dynamického rozsahu

Klientsky ifconfig-push je iný mechanizmus ako prideľovanie z poolu a musí používať parametre zodpovedajúce aktívnej topológii. V režime podsiete ide o jednu adresu a sieťovú masku; prenášanie dvojice net30 len preto, že sa objavila v starom príklade, je častá chyba.

História prideľovania je pomôcka, nie autorita. Súbor persist si pamätá, ktorý klient mal ktorú adresu, takže klienti, ktorí sa znova pripájajú, zvyčajne dostanú tú istú, a adresy nerezervuje, neuvoľňuje ani nenahrádza pevné priradenie. Ak konkrétne zariadenie musí mať vždy konkrétnu adresu, použite pevné priradenie namiesto spoliehania sa na súbor persist.

Potom skontrolujte cesty, ktoré závisia od adries. Trasa pretlačená klientom, pravidlo firewallu, ktoré prepúšťa podsiet, alebo monitorovacia kontrola očakávajúca konkrétneho hostiteľa môžu predpokladať starý rozsah. Zmena poolu bez ich prečítania presúva zlyhanie na miesto, ktoré vyzerá nesúvisle.

Nasaďte cez životný cyklus a potom overte

Nasadenie vykonajte tak, ako služba zvyčajne dostáva konfiguráciu — či už priamy súbor a reštart, alebo správcovská vrstva, ktorá súbor znova generuje. Ručná úprava generovaného súboru prežije do ďalšej generácie a nie dlhšie. Zaznamenajte, ktorý mechanizmus súbor vlastní, pretože nasledujúci operátor bude musieť vedieť, kde urobiť tú istú zmenu. Potom raz reštartujte a prečítajte 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

Pripojte klienta, ktorý sa predtým nepripájal, a potvrďte, že adresa spadá do deklarovaného rozsahu a mimo vyhradenej množiny. Potom potvrďte spiatočnú cestu: klient má dosiahnuť to, čo politika dovoľuje, a nič viac. Adresa, ktorá zodpovedá plánu, ale nemá funkčnú trasu, nie je úspešná zmena.

Znova pripojte klienta, ktorý držal adresu zo starého rozsahu. Mal by dostať adresu z nového rozsahu a akýkoľvek stav na úrovni relácie viazaný na starú adresu by mal zmiznúť. Ak si starú adresu ponechá, prideľuje mu ju niečo iné a pool nie je vlastník, ktorého si myslíte.

Návrat zmeny rozsahu

Uchovajte predchádzajúce tri riadky vo svojom zázname o zmene, nie iba predchádzajúci súbor. Ich obnovenie a reštart vrátia prideľovanie na staré správanie a klienti, ktorí sa potom pripoja, dostanú adresy z neho.

Do záznamu patria dve upozornenia. Klienti už pripojení v okamihu návratu si ponechajú aktuálne adresy, kým sa znova nepripoja, takže návrat nie je okamžitý v celej flotile. A ak sa starý rozsah prekrýval s pevným priradením, obnovenie vráti aj kolíziu; práve to prekrytie bolo dôvodom zmeny a vyžaduje iné riešenie ako návrat.

Zmena poolu je hotová, keď nový klient dostane adresu v rozsahu, vyhradená adresa sa nikdy nevydá a trasy a pravidlá, ktoré tieto adresy používajú, sa stále správajú podľa zámeru. Čokoľvek menej necháva na ďalšieho človeka zistiť, ktorá z troch vecí nie je pravda.

Súvisiace články