Почасово прекъсване на OpenVPN: предоговаряне или истинско повторно свързване?

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

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

Различавайте мекия ресет от рестартирането

Редът в журнала е цялата диагноза. Предоговарянето записва мек ресет и след това нов обмен на ключове в същия тунел: интерфейсът запазва адреса си, маршрутите не се добавят отново, а установените TCP сесии обикновено оцеляват с пауза. Истинското рестартиране разкъсва сесията, изгражда интерфейса наново, може да даде друг адрес на клиента и убива всяка дълготрайна връзка. И двете събития са обичайни; само едно от тях обяснява прекъснато обаждане.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

Редът за версията е важен, защото формулировките в журнала се менят между изданията и съобщение, което помните от 2.3, може да е формулирано различно в 2.6. Четете собствения си журнал, а не извадка от форум на някой друг. Цитирайте точния ред, когато искате помощ, защото преразказът губи подробността, която идентифицира събитието. Ако адресът на интерфейса не се е променил по време на събитието и списъкът със сесии е оцелял, виждате обновяване и останалите раздели се отнасят за вас.

Четете действащия таймер, а не своя файл

reneg-sec е броят секунди между предоговарянията на канала за данни и стойността по подразбиране е 3600. Всяка страна носи своята стойност и именно по-малката от двете задейства обновяването. Това единствено правило обяснява повечето съобщения: клиентски профил, който задава голямо число, пак се нулира на всеки час, докато сървърът пази стойността по подразбиране.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Прочетете и действащата конфигурация на сървъра, включително всичко, което той изпраща, преди да правите извод от клиентския файл. След това вдигнете подробността и проследете един интервал от начало до край: ниво 3 вече показва редовете за предоговаряне, а времевите отпечатъци казват дали събитието се повтаря на всеки 3600 секунди, или следва активността.

Променяйте го там, където наистина се изпраща

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

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

Решете също какво се случва при смесено разгръщане. Ако разпространите промяната първо към клиентите, остава прозорец, в който сървърът все още задейства обновяването; това е безобидно, но объркващо, ако следите журналите за потвърждение. Променете първо страната с по-малката стойност и симптомът изчезва в точката, която очаквате.

От какво се отказвате, като изключите предоговарянето

Редовното предоговаряне ограничава колко дълго един набор ключове на канала за данни защитава трафика. Изключването на таймера не чупи тунела и на домашен рутер или шлюз на малък офис практическата експозиция е скромна. Това все пак е размяна и размяната си струва да бъде назована, преди да я направите. Променя се колко дълго един набор ключове защитава сесия, а не дали тунелът работи изобщо.

Разумният случай за изключване е ресет, който чупи нещо, което не може да бъде възобновено: обаждане, което пада, сесия на отдалечен работен плот, която трябва да се установи наново, резервно копие, което започва отначало. Ако паузата е невидима за потребителите, запазването на стойността по подразбиране не струва нищо и ви запазва ротацията на ключове.

Предпочитайте да поправите причината, когато моделът го позволява. Обновяване, което се проваля по средата, докато първото ръкостискане е успяло, сочи към пътя, а не към таймера: търсете проблем с размера на пакета в по-големия обмен на контролния канал, защитна стена със следене на състоянието, която изхвърля потока, или предложение, което успява само от първия опит. Всяко от тях оставя следа в същия журнал, който току-що прочетохте. Изключването на таймера скрива това доказателство.

Когато интервалът сочи другаде

Двама съседи в конфигурацията дават подобни симптоми и различни поправки. ping-restart рестартира тунела, когато нищо не пристига за зададен период, а ping-exit изключва клиента напълно. Прекъсване при бездействие без никакво предоговаряне в журнала принадлежи на тях или на NAT устройство, на което картографирането на UDP е изтекло по собствен график.

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

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