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

Това търсене не е диагноз само по себе си, но ви премества от речника на протокола към действителен клас отказ с една стъпка.

Защо премахването на проверката е грешен рефлекс

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

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

Опкодът е полезен в разговор с поддръжката за едно: казва ви, че партньорът е стигнал достатъчно далеч, за да опита. Това, което се е случило след това, е това, което трябва да знаете, и то е записано в онзи журнал, който отбелязва първото конкретно отхвърляне. Започнете оттам и редът за нулиране спира да изглежда като причина и започва да изглежда като времева марка.