P_CONTROL_HARD_RESET_CLIENT_V2 в журнале: это ошибка?

Строка повторяется каждые несколько секунд и выглядит причиной всего: пакет с именем control hard reset, который приходит от клиента, никуда не доходящего. Это не ошибка. Это первое сообщение нового сеанса, а повторение — симптом того, что дальше не работает что-то другое. Отделить то, что говорит метка, от того, что сделало соединение потом, и есть весь диагноз.

Опкод обозначает позицию в протоколе

OpenVPN мультиплексирует несколько видов пакетов через один сокет, и опкод сообщает получателю, какой вид он держит. Пакеты hard-reset открывают сеанс, управляющие пакеты несут материал рукопожатия, подтверждения подтверждают приём, а пакеты данных несут полезную нагрузку туннеля. Чтение первого байта показывает, где в этом обмене находится пакет, а определения пакетов в исходном коде называют каждое семейство явно.

Это всё, что он говорит. Пакет, помеченный как начальный сброс клиента, доказывает, что пакет дошёл до вашей точки наблюдения и что партнёр хочет начать сеанс. Он не доказывает, что клиент доверился вашему сертификату, что его учётные данные были приняты или что канал данных когда-либо стал пригодным.

Суффикс V2 — это маркер поколения протокола для этого семейства пакетов, а не версия продукта и не настройка, которую вы устанавливаете. Ничто в имени не относится к сбросу туннеля, перезапуску службы или очистке кэша.

Что клиент на самом деле делает в этот момент

Клиент открывает идентификатор сеанса, к которому обе стороны привяжут последующий управляющий трафик. Если настроена защита управляющего канала, этот первый пакет уже несёт HMAC, позволяющий получателю решить, стоит ли тратить силы на остаток обмена. Получатель, который не может его проверить, молча отбрасывает пакет, и поэтому неверный общий ключ выглядит как клиент, говорящий в пустоту.

Ничего видимого пользователю ещё не произошло. Ни один сертификат не проверен, ни одно имя пользователя не предложено и ни один адрес туннеля не назначен. Сброс — это преамбула рукопожатия, поэтому любое суждение о соединении в этот момент преждевременно.

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

Где прячется настоящий сбой после сброса

Прочитайте два журнала рядом и найдите первое событие, которое не является сбросом. У клиента сбой проверки сертификата сообщается с конкретной причиной: истёкший сертификат, несовпадение имени или неизвестный издатель. У сервера отказ в учётных данных сообщается как сбой аутентификации с собственной причиной. Оба гораздо конкретнее, чем повторяющийся взгляд сервера на новые попытки.

Сопоставляйте одну попытку по отметке времени, а не читайте каждый журнал по отдельности, потому что один и тот же сбой появляется в обоих местах с разными формулировками и разной тяжестью. Партнёр, который сдаётся, обычно называет причину.

Если ни одна сторона не сообщает об отказе, а обмен всё равно застревает, граница — это достижимость, а не доверие. Межсетевой экран, отбрасывающий обратное направление, устройство трансляции сетевых адресов, у которого истекает сопоставление, или проблема MTU, убивающая более крупные пакеты рукопожатия, дают застрявший обмен вообще без ошибки аутентификации.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

Этот поиск сам по себе не диагноз, но за один шаг переводит вас от словаря протокола к реальному классу сбоя.

Почему отключение проверки — неверный рефлекс

Когда сброс продолжает появляться, самое быстрое на вид решение — отключить проверку сертификатов или отказаться от защиты управляющего канала, чтобы что-то подключилось. Это меняет диагностируемый сбой на недиагностируемый и оставляет развёртывание принимать тех партнёров, которых оно было построено отклонять.

Вместо этого измените границу, которая действительно отказала. Проблема доверия принадлежит центру сертификации и профилю, который на него ссылается. Проблема времени принадлежит часам. Проблема учётных данных принадлежит серверной части аутентификации, которая их отклонила, а недостижимый партнёр принадлежит пути между двумя хостами.

Опкод полезен в разговоре с поддержкой для одного: он говорит, что партнёр зашёл достаточно далеко, чтобы попробовать. Что произошло после, — это то, что вам нужно знать, и это записано в том журнале, который фиксирует первый конкретный отказ. Начните оттуда, и строка сброса перестаёт выглядеть причиной и начинает выглядеть отметкой времени.