OpenVPN продължава да опитва след TLS грешка: как да го спрем

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

Цикълът, който скрива първата грешка

Това, което виждате, е повтарящ се блок, а не една повреда: опит за свързване, TLS грешка, пауза и след това същата последователност. Всяко повторение избутва оригиналния ред все по-нагоре в журнала. Ако устройството се рестартира при повреда, цикълът може да продължи с часове, без никой да прочете причината. Симптомът е цикълът, макар основната неизправност да е един-единствен проблем с преговорите.

Интерактивните сесии понасят това, защото преходен проблем може да се изчисти при следващия опит. Автоматизираните връзки не могат да си позволят същия оптимизъм: процесът трябва да спре, за да може човек или монитор да види състоянието.

Преди да промените нещо, запишете един пълен цикъл. Отбележете отдалечения адрес, етапа на TLS, посочен в грешката, и дали процесът изобщо излиза.

Механизмът за повторни опити зад цикъла

Повторният опит е по подразбиране, защото няколко несвързани таймаута споделят един и същ механизъм. connect-retry задава интервала между опитите за свързване, connect-retry-max може да ограничи колко често се опитва всеки отдалечен запис, а resolv-retry управлява повторните търсения на имена. Неуспехът на TLS преговорите стига до този механизъм като транспортно събитие, затова клиентът планира още един опит вместо да докладва. Подразбиращото се е полезно за нестабилна връзка и вредно за неизправност, която не може да се излекува.

Опцията --tls-exit променя само случая с преговорите. Ръководството я описва като излизане при неуспех на TLS преговорите, което е по-тясно от излизане при всяка грешка. Таймаутите, отказите на резолвера и отхвърлянията при удостоверяване запазват собственото си поведение.

Накарайте клиента да излезе при TLS неуспех

Поставете tls-exit в профила, който клиентът действително зарежда, или подайте --tls-exit при стартиране, и го пуснете веднъж на преден план. Четете кода на изхода и последния ред от журнала, защото надзорникът реагира именно на кода. Ненулев изход след неуспех при преговорите е желаният резултат. Ако процесът продължава да опитва вместо да приключи, опцията не е в профила, който клиентът действително зарежда.

Надзорникът решава дали този изход ще бъде видим. systemd устройство с Restart=always или Restart=on-failure стартира клиента отново, затова цикълът продължава и опцията изглежда че не прави нищо. Проверете политиката, преди да обвините клиента:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no позволява на процеса да остане спрян, а Restart=on-failure все още рестартира след ненулев статус. Ако искате повредата да е видима, но услугата да се възстановява от несвързани сривове, задайте Restart=on-failure и използвайте StartLimitBurst и StartLimitIntervalSec, за да спрете бурята от рестарти. След това прочетете състоянието на устройството, за да потвърдите последния код на изхода: systemctl status го съобщава, а журналът пази първата грешка над рестартите.

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

Докажете го с временна крайна точка

За да видите поведението, преди да му се доверите, копирайте профила и насочете копието към крайна точка, която приема TCP връзка, но никога не говори OpenVPN. Достатъчен е слушател, който отговаря и след това млъква. С tls-exit клиентът трябва да приключи, когато ръкостискането се провали; без него същият профил трябва да продължи да цикли. Използвайте копието, никога работещия профил.

Сравнете двата пуска по код на изхода и по първия ред с грешка, а не по това колко е продължил всеки. Кодът показва дали опцията е сработила, а първият ред — кой етап се е провалил.

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

Етапи, до които тази опция не стига

Отхвърлянето при удостоверяване е по-късен етап. Ако сървърът оцени акаунта и го откаже, TLS вече е договорен, така че tls-exit не сработва. Настройките за повторни опити при удостоверяване са следващото място за проверка и причината от сървъра е по-важна от последния ред при клиента. Грешна парола и липсващ сертификат могат да дадат сходни съобщения от страна на клиента.

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

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