tls-auth key-direction: 0 і 1 мають відрізнятися, а не збігатися
З tls-auth обом кінцям потрібні протилежні напрямки, 0 і 1, або обидва мають пропустити налаштування. Те саме число не працює, а tls-crypt ніколи його не використовує.
Одна сторона тунелю підписує канал керування ключовим слотом, який інша сторона ніколи не перевіряє, і з'єднання помирає з помилкою автентифікації ще до обміну бодай одним сертифікатом. Так виглядає незбіг напрямку в tls-auth, і він детермінований: ті самі два файли зазнають невдачі за кожної спроби, з будь-якої мережі. Ніщо в журналі не називає параметр, який ви шукаєте, тому люди перестворюють ключі й перевипускають сертифікати, які ніколи не були зламані. Рішення — зробити обидва кінці взаємодоповнювальними або залишити обидва двонапрямними, а не послаблювати перевірку.
Збій стається до сертифікатів
З tls-auth обидві сторони тримають той самий спільний ключ, і кожна використовує один із двох похідних від нього слотів: один слот підписує вихідні пакети керування, інший перевіряє вхідні. Напрямок 0 і напрямок 1 призначають ці ролі в зворотному порядку, тому пара має бути взаємодоповнювальною, щоб перевірки HMAC збіглися. Коли призначення на одній стороні перевернуто, отримувач шукає підпис не в тому слоті й відкидає пакет. Сеанс на цьому завершується, тому помилка стосується автентифікації пакетів, а не того, що створило б сховище сертифікатів.
Детермінованість важлива для діагностики, бо проблема часу або маршруту залишає інший слід: періодичні обриви, відмова одного напрямку або сеанс, що вмирає лише в певній мережі. Незбіг напрямку зазнає невдачі на першому рукостисканні щоразу й зазнає її однаково на іншій машині з тими самими двома файлами. Читайте журнал при --verb 4 і знайдіть перший відкинутий пакет, а не останній рядок. Якщо ця відмова відбувається до будь-якого обміну сертифікатами, спільний ключ і його напрямок — це дві речі, які варто перевірити.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Де живе число
Посібник OpenVPN 2.6 описує два місця для напрямку: другий аргумент tls-auth, коли ключ лежить в окремому файлі, і окремий рядок key-direction, коли ключ вбудований у профіль. Обидва задають те саме значення, тож профіль має використовувати одну форму або іншу, ніколи обидві. Пропуск теж є вибором, і він ставить обидві сторони в двонапрямне розташування, яке працює, коли жодна сторона не називає напрямку. Дві сторони з тим самим числом не перебувають у цьому розташуванні: кожна очікує підписувати в одному слоті й перевіряти в іншому, і обидві роблять це однаково.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
Вбудована форма — це директива в окремому рядку, а не атрибут на відкривальному тегу блоку ключа, і додавання аргументу до цього тегу є помилкою, а не зміною напрямку. Розташування теж важливе: директива стоїть поза блоком, до якого належить, тож значення, записане всередині блоку, читається як ключовий матеріал. Копіюйте розташування, яке задумав розповсюджувач профілю, замість вигадувати пару, бо профіль, що працює проти одного сервера, можливо, вже віддзеркалений з іншого боку.
Чого параметр не торкається
Він не шифрує трафік застосунків. tls-auth ставить HMAC навколо пакетів каналу керування, тоді як канал даних захищений сеансовими ключами, узгодженими під час рукостискання, тому питання про пропускну здатність або шифр не має нічого спільного з числом напрямку. Параметр також не додає другого шару шифрування, і саме це припущення відправляє людей шукати довший ключ.
Він не застосовується до tls-crypt, іншого механізму каналу керування з власними параметрами й обробкою ключів, і нічого не каже про ідентичність сертифіката будь-якої сторони. Тому робочий збіг напрямку доводить лише те, що обидва кінці згодні, як автентифікувати канал керування, а не те, що ланцюг довіри було перевірено.
Вирівняйте пару, потім перепідключіться
Порівняйте обидві конфігурації, перш ніж змінювати якусь, бо редагування сторони, яка вже була правильною, подвоює роботу. Наведений нижче grep показує, який механізм вибирає кожен файл; докладний запуск показує, чи канал керування взагалі автентифікувався. Збережіть обидва виводи, щоб наступну зміну можна було порівняти з відомим станом.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Перезапустіть обидві сторони після будь-якої зміни, бо ці параметри читаються один раз під час запуску, і перезавантаження однієї сторони залишає пару неузгодженою на весь час життя старого сеансу. Якщо розгортання зараз працює без налаштованого напрямку, додавання параметра на одній стороні відтворює збій, з якого ви почали; або залиште обидві, або налаштуйте обидві. Змінюйте один кінець за раз і зберігайте попередній файл, щоб регресія була двохвилинним відкатом, а не перезбиранням.
Запишіть механізм, файл ключа й напрямок для кожного кінця в нотатках про розгортання, бо інакше наступна людина прочитає два схожі файли й припустить, що числа мають збігатися одне з одним. Напрямок — це деталь координації, а не покращення безпеки: він розділяє два напрямки каналу керування і більше нічого не робить.