Как собрать клиентский профиль OpenVPN из выданных файлов
Файл ovpn — это конфигурация, а не сертификат. Соберите один клиентский профиль из выданных CA, сертификата и ключа, затем закрепите идентичность и каталог.
Ваш оператор передаёт пакет CA, клиентский сертификат и его ключ, и клиент не запустится, пока они не будут связаны в одном профиле. Профиль — это конфигурация: он указывает на эти файлы, не содержит их, и редактирование не превратит его в сертификат. Инструкция начинается с уже одобренного ноутбука и заканчивается профилем, который можно запустить из известного каталога. Она не создаёт CA, не регистрирует новый сертификат и не трогает сервер.
Цель здесь — клиент командной строки OpenVPN 2.6 для Linux, маршрутизируемый через TUN поверх UDP, с аутентификацией по сертификату.
Соберите только файлы клиентской стороны
Работайте в защищённом каталоге и соберите одобренный материал доверия CA, выданный вам клиентский сертификат и соответствующий ему закрытый ключ. В этом примере имена — ca.crt, laptop-a.crt и laptop-a.key. Имена файлов — только метки; они ничего не говорят о том, что содержит каждый файл.
Если вы создали ключ при регистрации, он никогда не покидал машину; от издателя должны вернуться только подписанный сертификат и публичная цепочка. Проверьте, что сертификат несёт клиентскую роль, которую ожидает служба. Проверьте также, что ключ принадлежит именно этому сертификату, а не более раннему из прошлой попытки. Несовпадающая пара даёт сбой TLS гораздо позже, и он выглядит как проблема сервера.
Оставьте закрытый ключ подписи CA, закрытый ключ сервера и параметры DH вне этого пакета.
Свяжите файлы в небольшой профиль
Профиль ниже намеренно короткий. Каждая строка либо выбирает конечную точку, либо ограничивает идентичность, которую примет клиент, либо указывает на один из трёх файлов.
client
dev tun
proto udp
remote vpn.example.net 1194
nobind
remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key
Строка remote выбирает сетевую конечную точку. remote-cert-tls server требует, чтобы противоположная сторона предъявила сертификат с ролью сервера. verify-x509-name закрепляет ожидаемое имя, здесь vpn-gateway как Common Name сертификата сервера с полем имени по умолчанию в OpenVPN. Это значение не выводится из DNS-имени хоста, поэтому используйте схему идентичности, которую дал оператор.
Не отказывайтесь от этих проверок только потому, что тестовая конечная точка показывает другой сертификат.
Этот базовый профиль предполагает отсутствие отдельного challenge учётной записи и ключа канала управления. Если службе нужны auth-user-pass, tls-auth или tls-crypt, сохраните конфигурацию и материал, который вам дали, потому что секрет канала управления, созданный вами самостоятельно, не совпадёт с тем, что хранит сервер. Сохраните и политику шифрования службы вместо того, чтобы импортировать строки сжатия или шифра из старого примера.
Сделайте рабочий каталог явным
Относительные пути следуют рабочему каталогу процесса, а не расположению файла .ovpn.
Это удивляет тех, кто переносит профиль в новую папку и ожидает, что ключ последует за ним. Для каталога, выбранного администратором, команда ниже переходит в абсолютный путь перед чтением профиля и его ссылок.
sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn
Мастер импорта на рабочем столе или системная служба могут упаковать зависимости за вас и применить собственные правила. Они могут использовать и другой рабочий каталог, не тот, в котором вы тестировали. Убедитесь, как ваш способ запуска разрешает пути к ключу, сертификату и CA. Перемещение только файла .ovpn не перемещает отдельный закрытый ключ.
Держите ключ читаемым только для предназначенного пользователя или идентичности службы.
Проверяйте передачу, а не имена файлов
Перед первым разрешённым подключением проверьте конечную точку, идентичность сертификата, издателя и окно действия. Затем убедитесь, что ссылки на файлы разрешаются из того рабочего каталога, который вы действительно будете использовать. После подключения проверьте поведение приложения и DNS, которое должна обеспечить политика маршрутизации. Три читаемых файла ничего не доказывают ни об авторизации сервера, ни о пригодном пути к ресурсу.
Если появляется запрос парольной фразы, он относится к закрытому ключу, а не к учётной записи VPN.
Наконец, проведите инвентаризацию пакета как материала учётных данных. Передача того же сертификата и ключа на второй ноутбук копирует идентичность, а переименование файла не даёт второй регистрации. В этом разница между сборкой профиля и его выдачей.