Щогодинне обривання 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 і втрату пакетів.