Що насправді містить файл .ovpn і чого він не може

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

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

Файл описує ваш клієнт, а не сервер

Профіль об’єднує remote кінцеву точку, транспорт, тип інтерфейсу, матеріал ідентичності та будь-яку поведінку на боці клієнта, якої хоче оператор. Кожен рядок виконується клієнтом під час запуску. Жоден із них не потрапляє на сервер як зміна конфігурації, і жоден не може створити слухача, який ще не працює. Профіль, який указує TCP 443 для сервера, що слухає лише UDP 1194 зазнає невдачі вже на першому пакеті.

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

Рядки транспорту мають збігатися зі слухачем, який уже існує

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

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

Вбудовані ключі змінюють поводження з файлом

Сертифікати та ключі можуть бути вбудовані між тегами <ca>, <cert> і <key>, або вказані як окремі файли. Вбудований матеріал робить профіль самодостатнім і водночас робить його таємницею, бо закритий ключ клієнта подорожує всередині нього. Сертифікат CA — це публічний матеріал довіри, і ним безпечно ділитися; закритий ключ — ні, навіть коли він виглядає як нечитабельний блок тексту.

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

Маршрути й DNS можуть узагалі не надходити з файлу

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

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

Непідтримувані параметри — це питання версії клієнта

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

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

Після будь-якої заміни переконайтеся, який запис профілю використовує застосунок, бо імпорт нового файлу не завжди перезаписує старий.