Який примірник OpenVPN насправді використовує ваш профіль PiVPN?

PiVPN записує конфігурацію сервера й профіль клієнта, а потім завершується; він ніколи не стає процесом, який несе ваш трафік. Тому невдале рукостискання, клієнт, що звертається до хибної кінцевої точки, або служба, яка після перезавантаження повертається неправильно, не пояснюються меню інсталятора. Ці симптоми належать тому демону OpenVPN, який працює зараз, конфігурації, яку він справді завантажив, і журналу, на який його спрямовано. Чотири команди лише для читання зазвичай це вирішують, і жодна з них не змінює ваші сертифікати чи ключі.

Помічник і демон — різні об'єкти

Плутанину легко пояснити: в одному каталозі лежить файл, створений помічником, файл, який читає демон, і іноді застаріла копія обох. Помічник — це скрипт підготовки. Він встановлює пакунки, пише файли юнітів і друкує профіль клієнта, після чого його робота завершується. Залишаються запис у менеджері служб і командний рядок.

На хості з systemd починайте з активного юніта, а не зі списку каталогу. Ім'я залежить від пакування: образи Debian і Raspberry Pi OS зазвичай надають шаблонний примірник на кшталт openvpn-server@server, тоді як старіші інсталяції використовують openvpn@server. Запитайте менеджер, який працює, замість того щоб здогадуватися з імені файлу.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Прочитайте ExecStart= у цьому виводі. Там указано виконуваний файл і параметри, які менеджер справді запускає, включно з будь-яким --config шляхом; файл конфігурації поруч, на який не посилається жодна команда, не входить до робочого тунелю.

Простежте ланцюг конфігурації, який розв'язав демон

OpenVPN не сканує каталог у пошуках налаштувань. Він читає файл, переданий з --config, виконує будь-які config директиви всередині нього й потім застосовує параметри командного рядка. Посібник 2.6 описує цей порядок, і це важливо, коли два файли розходяться щодо порту, пристрою чи шифру.

Спочатку виведіть фактичний виклик, потім подивіться на директиви, що визначають ідентичність і доступність. Обидві команди лише для читання й безпечні на робочому сервері, хоча друга друкує шляхи, які ви, можливо, не хочете бачити в публічному тікеті.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Файл .ovpn у домашньому каталозі — клієнтський артефакт. Демон сервера ніколи його не читає, тож редагування цього файлу для виправлення збою рукостискання на боці сервера нічого не дає.

Включення — інша пастка. Рядок config підтягує другий файл, параметри якого обробляються в цьому місці, тому пізніша директива з одним значенням може перекрити те, що нібито каже основний файл. Якщо видимий файл виглядає правильно, а демон поводиться інакше, прочитайте включений файл, перш ніж щось змінювати.

Зіставте журнал із процесом, а не з помилкою, яку пам'ятаєте

Два місця для журналу поширені, і лише одне з них — journal. З log-append демон пише в цей файл, а journal зберігає небагато, крім рядків запуску. Без цього journalctl є джерелом подій.

journalctl -u openvpn-server@server -n 80 --no-pager

Зв'яжіть одну спробу з'єднання з одним часовим вікном. Запишіть кінцеву точку клієнта, потім прочитайте події сервера за ті самі секунди. Рукостискання TLS, яке так і не доходить до обміну сертифікатами, вказує на доступність або невідповідність протоколу, а відмова автентифікації приходить після того, як параметри тунелю вже узгоджені.

Стара стаття журналу нічого не доводить про профіль, завантажений п'ять хвилин тому. Перегенеруйте клієнтський файл, підключіться один раз і читайте лише рядки, що з'явилися під час цієї спроби.

Записуйте першу конкретну помилку, а не останню загальну. Помилка прив'язки, невідповідь зовнішнього обміну, відмова сертифіката й відмова облікового запису ведуть кожна на свій рівень, а тайм-аут наприкінці часто приховує корисну подію вище.

Перебудова тунелю не є діагностичним кроком

Спокусливий короткий шлях — підняти другий, простіший тунель: статичний ключ, без сертифікатів, без додаткової автентифікації. Він часто підключиться, і доводить лише те, що два хости можуть пропускати UDP або TCP між собою. Він нічого не каже про те, чому сертифіковане розгортання не працює, і тихо замінює модель безпеки, яку просили зберегти.

Те саме стосується вимкнення tls-auth або tls-crypt, послаблення verify-x509-name, або відмови від другого фактора заради зеленого статусу. Тунель, який підключається тому, що перевірку прибрали, — це інша система, а не виправлена.

Зробіть одну обмежену зміну на рівні, який назвав журнал, перезапустіть той самий юніт і повторіть єдину спробу з'єднання. Це зберігає порівняння чесним і залишає зміну, яку можна відкотити.

Що передати наступній людині

Запишіть чотири факти, поки вони ще у вас: версію OpenVPN з openvpn --version, активний юніт, ланцюг конфігурації з його включеннями й вікно журналу, що покриває одну спробу. Ці чотири перетворюють розпливчасту скаргу на відтворюваний випадок.

Відредагуйте перед публікацією. Приватні ключі, auth-user-pass файли, матеріал статичного ключа й повні клієнтські пакети не місце в тікеті; назви параметрів і форма ланцюга зазвичай достатні для другої пари очей.

Якщо ланцюг цілий, а журнал досі вказує на мережу, наступний крок — шлях між клієнтом і сервером, а не ще одне встановлення. Це та частина історії, якою помічник ніколи не володів.