Чому додавання opt-verify не виправить помилку шифрування OpenVPN

Ви знаходите пораду додати opt-verify, додаєте рядок, а помилка шифрування залишається рівно там, де була. Такий результат передбачуваний, бо опція ніколи не узгоджувала шифр. Це була перевірка узгодженості опцій, застаріла в 2.6 і видалена в 2.7, і профіль, який із нею все ще розбирається, тим самим нічого не забезпечив.

Корисно знати, що рядок робив раніше, перш ніж робити висновок, що це відсутня частина. Історія також пояснює, чому зараз він не може допомогти.

Що опція забезпечувала раніше

Посібник для 2.6 позначає opt-verify як застарілу й описує попередню поведінку: сервер відкидає клієнтів, оголошені опції яких не збігаються з його власними, порівнюючи такі речі, як тип пристрою та MTU. Ця перевірка також залежить від того, що перевірка узгодженості опцій залишається ввімкненою, тож сервер, який працює з disable-occ, ніколи її не мав. Зверніть увагу, з чого побудоване порівняння: з тексту, що описує конфігурацію іншої сторони. Він нічого не каже про те, який шифр використовуватиме канал даних.

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

Що робить 2.7, коли бачить рядок

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

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

Де насправді живе збій

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

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

Замініть намір, а не лише рядок

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

Не відповідайте на стару пораду, що всі шифри вимкнено, увімкненням кожного історичного алгоритму.

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

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