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