OpenVPN сървър с nopool: обявете явен диапазон на пула

Сървърните помощни програми настройват подмрежа и след това я запълват с динамичен пул по свой избор. Тази стойност по подразбиране е удобна, докато някои адреси трябва да останат извън разпределението — било то запазени за фиксирани назначения или задържани за бъдещ сегмент. Потискането на автоматичния пул и обявяването на диапазона сами отнема два реда и едно съзнателно решение кои адреси не са за разпределение. Останалото е оперативна дисциплина: инвентаризация, прилагане, проверка, връщане назад.

Това е промяна в работеща услуга, затова я третирайте като оперативна задача: първо инвентаризация, прилагане през нормалния жизнен цикъл, проверка с нов клиент и запазен план за връщане назад.

Започнете от подмрежата, която вече имате

Прочетете текущата конфигурация на сървъра и адресите, които клиентите действително заемат. Промяната на пула има смисъл само спрямо тази база, а базата не винаги е това, което файлът подсказва, защото управляван продукт или генератор на конфигурация може да притежава файла, който четете.

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

Потвърдете действащата топология. При топология подмрежа всеки клиент взема един адрес от пула; по-старите схеми net30 отделят малък блок за всеки клиент и аритметиката е напълно различна. Ако сървърът все още е на net30, тази страница е грешното ръководство за миграция и числата на пула няма да означават това, което очаквате. Проверете този ред, преди да копирате аритметика за адреси от друго място.

Запишете собствения адрес на сървъра, всяко фиксирано назначение в директорията с клиентски конфигурации и всеки адрес, от който зависи маршрут или правило за достъп. Това са адресите, които трябва да останат извън динамичния диапазон. Записването им първо превръща диапазона в решение, а не в предположение. То също дава на връщането назад нещо конкретно за възстановяване.

Добавете nopool и обявете диапазона

Помощната ключова дума приема nopool, което запазва конфигурацията на подмрежата и потиска автоматичния динамичен пул, както описва ръководството на OpenVPN 2.6. След това явният ред ifconfig-pool дава включващия диапазон, който искате, а мрежовата му маска съвпада с подмрежата. Двата реда принадлежат на един и същ сървърен блок, защото пул без своята подмрежа няма смисъл. Редът между тях е важен само за четливост, тъй като помощникът разгръща двойката при стартиране на услугата.

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

Двете граници са включващи, така че примерът предлага седемдесет и един адреса. Дръжте адреса на сървъра и всяко фиксирано назначение извън този обхват; фиксирано назначение, което попадне в динамичния диапазон, създава сблъсък, зависещ от реда на свързване, а това е най-лошият вид за отстраняване. Оставете запас между резервирания набор и диапазона, ако фиксираните назначения е вероятно да растат.

Размерът на диапазона и едновременността са отделни ограничения. Сто адреса не означават сто едновременни клиента, ако max-clients казва друго, а пул, по-голям от границата за едновременност, е нормално, а не разхищение. Важното е двете граници да са избрани съзнателно, а не наследени от стойност по подразбиране.

Дръжте фиксираните назначения извън динамичния диапазон

Клиентският ifconfig-push е различен механизъм от разпределението от пул и трябва да използва параметри, подходящи за активната топология. В режим подмрежа това е един адрес и мрежова маска; пренасянето на двойка net30, защото се е появила в стар пример, е често срещана грешка.

Историята на разпределението е подсказка, не авторитет. Файлът persist помни кой клиент кой адрес е имал, така че пресвързващите се клиенти обикновено получават същия, и той не резервира адреси, не ги освобождава и не заменя фиксирано назначение. Ако конкретно устройство трябва винаги да държи конкретен адрес, използвайте фиксирано назначение, вместо да разчитате на файла persist.

След това проверете пътищата, които зависят от адресите. Маршрут, изпратен към клиентите, правило на защитна стена, което допуска подмрежа, или проверка за наблюдение, която очаква конкретен хост, могат да предполагат стария диапазон. Промяната на пула без прочитането им премества отказа на място, което изглежда несвързано.

Приложете през жизнения цикъл, после проверете

Приложете промяната така, както услугата обикновено получава конфигурация — дали директен файл и рестарт, или слой за управление, който прегенерира файла. Ръчната редакция на генериран файл оцелява до следващото генериране и не по-дълго. Запишете кой механизъм притежава файла, защото следващият оператор ще трябва да знае къде да направи същата промяна. След това рестартирайте веднъж и прочетете журнала, преди да поканите клиент.

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

Свържете клиент, който не е бил свързван преди, и потвърдете, че адресът попада в обявения диапазон и извън резервирания набор. После потвърдете обратния път: клиентът трябва да достига това, което политиката позволява, и нищо повече. Адрес, който съвпада с плана, но няма работещ маршрут, не е успешна промяна.

Свържете отново клиент, който е държал адрес от стария диапазон. Той трябва да получи адрес от новия диапазон и всяко състояние на ниво сесия, свързано със стария адрес, трябва да е изчезнало. Ако запази стария адрес, нещо друго го назначава и пулът не е собственикът, който мислите.

Връщане назад на промяна в диапазона

Пазете предишните три реда в записа си за промяната, не само предишния файл. Възстановяването им и рестарт връщат разпределението към старото поведение и клиентите, които се свържат след това, ще получат адреси от него.

Две предупреждения принадлежат в записа. Клиентите, които вече са свързани при връщане назад, запазват текущите си адреси, докато не се свържат отново, така че връщането назад не е мигновено за целия парк. И ако старият диапазон се е припокривал с фиксирано назначение, възстановяването му връща и сблъсъка; това припокриване е причината за промяната и изисква различно решение от връщане назад.

Промяната на пула е завършена, когато нов клиент получи адрес в диапазона, резервиран адрес никога не бъде издаден и маршрутите и правилата, които консумират тези адреси, продължават да работят както е предвидено. Всичко по-малко оставя на следващия човек да открие кое от трите не е вярно.