Статичний ключ чи TLS для з’єднання OpenVPN між двома вузлами?

Дві машини, які спілкуються лише одна з одною, можуть зберегти цю топологію і все ж отримати узгоджені ключі трафіку. Форма мережі та режим захисту — незалежні рішення, і саме їх змішування змушує людей намагатися оновити статичний секрет заміною файлу, поки обидва демони продовжують працювати. Заміна файлу ключа в працюючої пари не оновлює нічого. Статичний режим, який OpenVPN 2.6 позначає як застарілий, тримає один ключ протягом усього життя тунелю, тому файл на диску та ключ у пам’яті знову збігаються лише після перезапуску обох кінців. Якщо вимога — автоматичне оновлення, режим захисту має змінитися.

Чого не може статичний режим

У секретному режимі обидва вузли використовують спільний заздалегідь розподілений ключ, який безпосередньо шифрує та автентифікує тунель. Рукостискання немає, тому немає механізму, який дозволив би будь-якій стороні запропонувати новий ключовий матеріал, довести особу або відновитися після розбіжності без втручання оператора. Обидві властивості випливають із відсутності каналу керування, а не з відсутньої опції, і жоден прапорець конфігурації не додає його в цей режим.

У посібнику OpenVPN 2.6 прямо сказано, що ключ зберігається, доки не буде створено новий. Це прийнятно для лабораторного з’єднання або фіксованої пари пристроїв із задокументованою процедурою зміни, і неприйнятно там, де довготривалий секрет є реальним ризиком. Заміна файлу не створює нового ключа для працюючої пари; вона створює два вузли, які розходяться. Тому заміна файлу додає простій, не додаючи зміни ключів.

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

Перехід на TLS без переробки з’єднання

Режим TLS додає канал керування і разом із ним можливість узгоджувати ключі каналу даних. У розгортанні «точка — точка» одна сторона бере роль сервера, а інша — клієнта, але топологія залишається з’єднанням двох вузлів: кожна сторона знає кінцеву точку іншої, і жоден пул чи багатокористувацька служба не з’являється. Ролі — деталь рукостискання, а не нова архітектура.

Дайте кожній машині власну особу. Кожній стороні потрібні сертифікат і закритий ключ, якір довіри, що перевіряє іншу сторону, і правило перевірки вузла, яке називає, кого очікують. Не використовуйте закритий ключ одного вузла на іншому заради економії часу; це перетворює дві особи на одну й позбавляє можливості відкликати будь-яку сторону окремо. Реєстрація — місце, де це робиться правильно, бо виправлення пізніше означає перевипуск сертифікатів.

Тримайте мережевий договір незмінним, поки захист змінюється. Ті самі адреси тунелю, маршрути й дозволені служби мають діяти до і після, щоб збій під час міграції був проблемою захисту, а не замаскованим сюрпризом маршрутизації. Запишіть адреси й маршрути до зміни; порівняти їх потім швидше, ніж відновити з пам’яті.

Деякі розгортання захищають і канал керування власним статичним ключем, який не оновлюється разом із каналом даних. Цей ключ охороняє рукостискання, а не корисне навантаження, тому його компрометація розкриває узгодження, а не трафік. Зберігайте його окремо від матеріалу каналу даних і призначте дату заміни, за яку відповідає названа особа. Його оновлення означає перезапуск обох вузлів у узгодженому вікні, тому він заслуговує на запис у календарі, а не в пам’яті.

Хто що оновлює і коли

У режимі TLS оновлення визначається налаштованими межами: інтервалом часу, кількістю байтів або кількістю пакетів. Задокументоване керування часом — те, на що покладається більшість розгортань, і менше чинне значення на двох вузлах може запустити заміну, тому підвищення лише з одного боку не стримає подію. Межі за обсягом існують тому, що завантажене з’єднання може вичерпати ключ задовго до того, як це зробить годинник. Жодна межа не є перевіркою стану, і жодна не повідомляє, що оновлення вдалося.

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

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

Повне вимкнення оновлення встановленням інтервалу в нуль не є рішенням для галасливого журналу. Воно перетворює здорову подію життєвого циклу на постійний ключ, що повертає вас до властивості, від якої ви намагалися піти.

Прийняття зміни

Будуйте нову конфігурацію з підтримуваного прикладу встановленого випуску, а не зі старого мінімального фрагмента, чиї алгоритми й шляхи до файлів успадковані з іншого місця. Узгодьте перемикання так, щоб обидва вузли змінилися разом, і тримайте затверджений шлях відновлення на випадок, якщо одна сторона не підніметься. Спустіть з’єднання навмисно, а не чекайте збою, щоб перевірити відкат. Відкат, який ви відпрацювали, цінніший за відкат, який ви описали.

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

Те, що приховала б обіцянка нульового простою, — це збій, якого ви ще не бачили. Невдале оновлення, сертифікат, що спливає, або дефект шляху все ще можуть порушити з’єднання, і жоден із них не виключається чистим тестовим прогоном. Властивість, заради якої варто проєктувати, вужча й корисніша: рутинна заміна ключів перестає бути ручною заміною файлу.