Какой экземпляр 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 файлы, материал статического ключа и полные клиентские наборы не место в тикете; названия опций и форма цепочки обычно достаточны для второй пары глаз.

Если цепочка цела и журнал всё ещё указывает на сеть, следующий шаг — путь между клиентом и сервером, а не ещё одна установка. Это та часть истории, которой помощник никогда не владел.