Видалення key-method із профілю OpenVPN нічого не змінює

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

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

Симптом — помилка розбору, а не збій рукостискання

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

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

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

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

Директива й формат передавання — дві різні речі

Стара опція key-method вибирала, як обрамляється обмін ключами TLS, а сучасний обмін — це багатопакетний метод, який ця опція колись вимагала. Опція зникла, бо більше нічого не вибирала; формат, який вона називала, став єдиним. Тому видалення рядка залишає сеанс із тим самим обрамленням, що й раніше. Правка тексту не може змінити це в жодному напрямку.

Тому повертати старий бінарник, щоб «відновити» метод 2, — неправильний ремонт. Він не відновлює нічого, крім старішого парсера зі старішими типовими значеннями, і позбавляє вас виправлень, що прийшли після нього. Те саме міркування стосується ослаблення перевірки сертифіката або списку шифрів у надії, що з'єднання повернеться.

Корисна перевірка — це версія та розібрана конфігурація, а не наявність слова у файлі:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Що видаляти і з якого файлу

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

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

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

Відхилений профіль і відхилений клієнт виглядають однаково

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

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

Питання сумісності, на які рядок так і не відповів

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

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

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