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

Розділіть збій на два, перш ніж змінювати директиву

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Другий слухач — чесне місце для слабшого порогу

Коли пристрій зупиняється на TLS 1.0 з каналом даних до 2.5, сервер має запропонувати нижчий поріг каналу керування й шифр даних, який упізнає старий клієнт. Резервна директива існує саме для такого піра, а список шифрів утримує сучасних клієнтів на сучасних наборах. Обидві директиви належать слухачеві, а не користувачу чи з'єднанню, і жодна опція окремого клієнта потім їх не звужує. Тому один старий пристрій на головному порту — це рішення про кожного піра, який ділить цей порт.

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

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Що насправді ламає старий сертифікат постачальника

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

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

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Читайте узгоджені значення, а не банер

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

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

Кожному винятку потрібен власник і дата

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

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

Схожі статті