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

Поврзете клиент што претходно не бил поврзан и потврдете дека адресата паѓа во објавениот опсег и надвор од резервираното множество. Потоа потврдете го повратниот пат: клиентот треба да стигне до она што политиката го дозволува и ништо повеќе. Адреса што одговара на планот, но нема работна рута, не е успешна промена.

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

Враќање на промена на опсег

Зачувајте ги претходните три линии во вашиот запис за промени, не само претходната датотека. Нивното враќање и рестартирање го враќа доделувањето на старото однесување, а клиентите што ќе се поврзат потоа ќе добијат адреси од него.

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

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