Як перевірити сервер профілю OpenVPN перед його імпортом

Хтось надсилає вам профіль, ви імпортуєте його, і через тридцять секунд клієнт набирає адресу, яку ніхто не перевіряв. Спершу прочитайте файл у текстовому редакторі, бо все важливе вміщається в жменю директив: remote, proto, port, ca, cert, tls-crypt і verify-x509-name. Усе інше — значення за замовчуванням, і саме там живуть сюрпризи.

Перелічіть усі кінцеві точки, які може використати файл

Почніть із кінцевих точок, бо один профіль може містити кілька. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn друкує кожного кандидата в порядку файлу, включно з вкладеними у вбудовані блоки <connection>.

Коли директива пропускає порт, клієнт повертається до значення за замовчуванням слухача, тож сам remote vpn.example.com означає порт 1194 з будь-яким proto, що трапиться далі у файлі. Кілька простих рядків remote є альтернативами: клієнт пробує їх по черзі, якщо remote-random не перемішає їх, і ніколи мовчки не підміняє хост іншого оператора. Два рядки remote на незв'язаних доменах — це точка, де ви зупиняєтесь і питаєте, який із них мався на увазі.

Зверніть увагу й на написання proto. tcp приймається як синонім клієнтського tcp-client, але tcp-server у клієнтському профілі — це помилка конфігурації, яка радше зависає, ніж чисто завершується.

Спершу підтвердьте ім'я, потім порт

dig +short vpn.example.com повідомляє, чи існує ім'я і які адреси воно повертає, а кінцева точка з кількома адресами або за проксі може законно повернути кілька. Розв'язання імені — це передумова, а не доказ належності; будь-хто може спрямувати ім'я на адресу, і одна адреса може відповідати за багато імен.

Потім перевірте слухача на знайденому порту, відповідно до транспорту. Через TCP openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com друкує ланцюжок, який подає сервер. Через UDP потрібен DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 виконує те саме рукостискання поверх датаграм. Завершене рукостискання доводить, що щось слухає і тримає сертифікат, — це більше, ніж показує ping, і менше, ніж вимагають власні налаштування довіри профілю.

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

Читайте закріплені відбитки окремо від адреси

Адреса вирішує, куди йде клієнт; блок довіри вирішує, кому він вірить після прибуття. verify-x509-name "vpn.example.com" name закріплює загальне ім'я суб'єкта, а remote-cert-tls server вимагає розширеного використання ключа для автентифікації сервера. Профіль, переданий вам оператором, має мати обидва.

Шукайте ca, вбудований блок <ca> і або tls-crypt, або tls-auth. Профілю з tls-auth потрібен key-direction 1 на клієнті, коли бік сервера використовує напрям 0, і невідповідність зриває рукостискання помилкою TLS, яка читається як дефект сертифіката. Вбудований CA, що не належить тому оператору, чиє ім'я ви щойно розв'язали, означає, що файл зібрано з двох джерел, і це саме той випадок, який варто рішуче відхилити.

verify-x509-name приймає режими name, name-prefix або subject, а останній очікує повне відмітне ім'я в точному порядку, у якому його друкує сервер. Виберіть режим, що відповідає формі значення, бо клієнт відхиляє кожне з'єднання замість попередження про майже збіг. Для файлу, який ви не писали, name з простим ім'ям хоста — найменш несподіваний вибір.

Перевірте параметри, що тихо відмовляють

OpenVPN 2.6 узгоджує шифри через data-ciphers, і профіль лише зі старим рядком cipher AES-256-CBC може завершити канал керування, а потім застрягти на даних. Читання цього значення каже, чи файл старіший за сервер, до якого ви приєднуєтесь; сторінка посібника версії 2.6 перелічує порядок узгодження, якщо треба процитувати його оператору.

auth-user-pass без імені файлу означає, що клієнт запитає, тож профіль, що виглядає самодостатнім, усе одно потребує облікових даних. auth-user-pass credentials.txt означає, що він чекає файл, який вам, імовірно, не надсилали. nobind і resolv-retry infinite звичайні та нешкідливі, тоді як explicit-exit-notify лише для UDP і безглуздий поверх TCP.

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

Вирішіть, а потім запишіть, що вирішили

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

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

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

Якщо ви все ж імпортуєте його і перша спроба не вдасться, запустіть клієнт з --verb 3 і прочитайте перші десять рядків: розв'язана адреса remote, узгоджений proto і помилка TLS з'являються саме в цьому порядку, що підкаже, яку з перевірок вище ви пропустили.