Как проверить сервер профиля 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 появляются именно в этом порядке, что подскажет, какую из проверок выше вы пропустили.