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

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

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

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

Сачувајте претходна три реда у свом запису о промени, не само претходну датотеку. Њихово враћање и рестарт враћају доделу на старо понашање, а клијенти који се потом повежу добијаће адресе из ње.

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

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