OpenVPN не запускається: читайте перший рядок, а не конфігурацію

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

До цього ведуть три команди лише для читання: спершу journalctl -u openvpn@server -b --no-pager, другою systemctl status openvpn@server і ss -lunp для слухачів UDP та їхніх власників.

Перший рядок обирає гілку

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

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

Хто ще тримає порт 1194

Винуватець зазвичай не другий сервер, який хтось навмисно налаштував. Очікуйте запущеного вручну клієнта, що досі живий в іншому терміналі, другого профілю, який випадково обрав той самий порт, або постачальницького пакета, чий власний тунель тримає 1194. Власник сокета з'являється в ss -lunp; передайте цей PID у systemctl status, щоб дізнатися, чи відповідальний модуль. Скиньте його через власний шлях керування, а не сигналом.

Сигнал процесу, яким керує модуль, зазвичай спричиняє перезапуск, і той самий збій за мить повертається, виглядаючи як нова проблема. Для модуля використовуйте systemctl stop, для постачальницької установки — власну сервісну команду пакета, а сигнал — лише для того, що ви запустили вручну в тій оболонці.

Залишкові модулі після очищення

Очищення видаляє двійкові файли; написані вручну файли модулів, зазвичай під /etc/systemd/system, його переживають. Systemd тоді повторює модуль, що вказує на шлях, якого більше немає, і повідомлення стосується того відсутнього файлу, а не вчорашнього видалення. systemctl status показує шлях фрагмента модуля ближче до верху, тож перевірте його за допомогою dpkg -S, перш ніж щось видаляти. Коли сирота зник, systemctl daemon-reload і systemctl reset-failed очищають стан; інакше кожна пізніша перевірка стану його успадковує.

Коли which openvpn відповідає чимось під /usr/local, двійковий файл у грі походить від постачальницького інсталятора, а не з apt. Такий інсталятор зазвичай приносить власний слухач, власний запис завантаження й власний каталог конфігурації, тож видалення видимої команди залишає сокет зайнятим.

Видаліть його так, як документує постачальник, підтвердьте, що порт вільний, за допомогою ss -lunp, і додайте клієнт дистрибутива лише за потреби.

Заспокойте стан перед повторною спробою

Очистіть невдалий стан, перш ніж робити з нього висновки: systemctl reset-failed прибирає лічильники, а systemctl status потім повідомляє поточний стан модуля, а не його історію. Запустіть його один раз і прочитайте журнал саме цього примірника, а не зведений стан машини. Модуль, що звітує про активність, коли тунель нічого не несе, — окрема проблема, і значно поширеніша. У звітах про помилки обидва зливаються, бо обидва закінчуються тим, що користувач каже, ніби VPN не працює.

Занотуйте, яку гілку ви обрали: конфлікт портів, відсутній двійковий файл, відсутня конфігурація. Наступний випадок розпізнаєте швидше.