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 і канфігурацыю разам, потым перазапусціце. Сертыфікаты для ўсяго гэтага перазадаваць не трэба, і менавіта стаўленне да праблемы каталога як да праблемы ўліковых даных ператварае пяціхвіліннае выпраўленне ў акно абслугоўвання.