client-config-dir се игнорише након што је OpenVPN постао услуга

Тунел се подиже и клијент се повезује, али фиксна адреса и пропуштене руте које сте дефинисали за тог једног корисника недостају. У дневнику не пише “file not found”, и управо то шаље људе да поново генеришу сертификате. У већини ових случајева демон ради из другог директоријума од љуске у којој сте тестирали, а client-config-dir никада није разрешен онако како сте претпоставили. Поправка је исправка путање, не ресетовање акредитива.

Прочитајте unit пре него што дирнете конфигурацију

Почните од процеса који стварно ради, а не од датотеке коју сте уредили. Питајте systemd за линију извршавања, радни директоријум и налог на који прелази. Та три одговора објашњавају већину кварова ове врсте:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Празан WorkingDirectory значи да unit почиње у /, па се релативни client-config-dir ccd тражи у /ccd. Тај директоријум готово никада не постоји, а демон његово одсуство не сматра кобним.

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

Према чему се разрешава релативна путања

Кључна реч се разрешава према радном директоријуму процеса у тренутку када се опција користи. То не значи “поред конфигурационе датотеке коју сам проследио са --config”. OpenVPN ће радо прочитати конфигурацију са апсолутне путање и ипак разрешити релативне вредности негде другде, а то је управо замка овде. Приручник OpenVPN 2.6 наводи правило под --client-config-dir и поново под --cd.

Кључна реч cd мења тај контекст пре него што се читају друге датотеке, па се unit који поставља cd /etc/openvpn/server и затим client-config-dir ccd разрешава у /etc/openvpn/server/ccd. Ако додате cd, проверите редослед директива и запамтите да утиче на сваку другу релативну референцу у истој датотеци.

Прођите путању као налог демона

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

namei исписује дозволе сваке компоненте редом, што је брже од провере директоријума један по један:

namei -l /etc/openvpn/server/ccd/client1

Затим тестирајте читање као налог услуге, а не као себе:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Ако unit користи chroot, директоријум мора да постоји унутар затвора, а путања у конфигурацији се тумачи после примене chroot. Датотека која постоји на хосту изван затвора невидљива је изнутра.

Потврдите претрагу уместо нагађања

Подигните ниво дневника за једно поновно покретање и прочитајте шта сервер каже о опцијама специфичним за клијента. На verb 4 демон извештава о увезеној конфигурацији по клијенту, па је одсутан ред директан доказ да ниједна датотека није прочитана за ту везу.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Покрените то у првом плану на резервном порту и повежите једног клијента. То потпуно уклања systemd из слике: ако се надјачавања појаве овде, а не под услугом, разлика је у контексту unit, не у датотеци.

Одлучите шта треба да се догоди када ниједна датотека не одговара. Без ccd-exclusive клијент се прима само са глобалним поставкама базена, и то је тихи квар описан горе. Са њом недостајућа датотека постаје одбијена веза, а такво одбијање је лакше приметити, али теже отклонити под оптерећењем.

Поправите, рестартујте, проверите

Учините директоријум апсолутним у конфигурацији и оставите га тако. Релативне путање су безбедне само када unit фиксира радни директоријум, а фиксирање је додатни покретни део који ће неко касније уклонити.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Рестартујте инстанцу, поново повежите једног познатог клијента и прочитајте адресу коју је добио заједно са рутама послатим ка њему. Ако се адреса поклапа са редом ifconfig-push у датотеци тог клијента, претрага је успела. Ако клијент и даље заврши у општем базену, вратите се на број редова у дневнику: нула увоза значи да су путања или идентитет погрешни, један увоз са погрешним садржајем значи да уређујете другу датотеку од оне коју демон чита.

Вратите се враћањем претходног unit и конфигурације заједно, па рестартујте. Сертификате није потребно поново издавати због ичега од овога, а третирање проблема са директоријумом као проблема са акредитивима је начин на који петоминутна поправка постаје прозор за одржавање.