Нюансы и пределы¶

Что механизм не обещает и где он ведёт себя не так, как кажется на первый взгляд. Для запуска читать необязательно — но лучше прочитать до того, как это выяснится на работающем туннеле.

Главное, что стоит знать заранее: почти все пределы этой цели лежат на стороне клиента OpenVPN, а не на стороне Alatyr. Выдача сертификата — условие необходимое, но не достаточное.

OpenVPN Connect не берёт ключ из чипа¶

Замерено на обеих платформах: Windows — Connect 3.9.0, macOS — Connect 3.8.1.

Connect принимает клиентскую личность только двумя способами:

файлом PKCS#12 — то есть выгружаемым закрытым ключом;
токеном PKCS#11 — картой или USB-токеном.

Платформенные хранилища он не читает. Профиль со строкой cryptoapicert импортируется без ошибок, но вместо чтения хранилища Connect выводит Missing external certificate и требует дать сертификат «внешним». На macOS вкладка Hardware Tokens отвечает No hardware tokens found при живом токене в системе — он ищет PKCS#11, а наш токен на macOS другого интерфейса.

Что из этого следует. Первый путь обесценивает всю затею: ключ, который можно скопировать, больше не привязан к устройству. Поэтому разговор с заказчиком, назвавшим Connect, — не «когда заработает», а выбор клиента.

Почему на Windows вкладка `Hardware Tokens` пуста¶

Вопрос, который задают первым: на машине есть смарт-карта и считыватель Alatyr — почему Connect пишет No hardware tokens found?

Потому что вкладка перечисляет токены PKCS#11, а ни один ключ Alatyr на Windows через PKCS#11 не публикуется:

ключ цели vpn — ключ TPM в контейнере CNG (Microsoft Platform Crypto Provider), он виден приложениям через хранилище сертификатов Windows;
смарт-карта Alatyr (вход в домен) публикуется минидрайвером, то есть тоже через CryptoAPI/CNG.

Модуль PKCS#11 для Windows Alatyr не поставляет, и для VPN он не нужен: тот же ключ берёт community-клиент директивой cryptoapicert. Считыватель и карта при этом не участвуют вовсе — VPN работает и на машине, где их нет.

Замерено 2026-09-22 (Connect на Windows 11) и 2026-09-23 (туннель community OpenVPN GUI 2.6.14 на чистой установке, пользователь без прав администратора).

Что вместо него работает: community-клиент openvpn — на Windows OpenVPN GUI через cryptoapicert с ключом CNG/TPM, на Linux --pkcs11-providers с ключом в tpm2-pkcs11, на macOS — openvpn из командной строки с подписью через интерфейс управления (ниже). Все три пути проверены живьём.

macOS: ключ отдаётся через интерфейс управления, а не PKCS#11¶

Путь PKCS#11 на macOS закрыт подписью клиентов, а не платформой. Замер 2026-09-20 и 2026-09-21.

Внутри Tunnelblick четыре сборки openvpn; у всех стоит hardened runtime и ни у одной нет разрешения com.apple.security.cs.disable-library-validation, поэтому загрузку любого стороннего модуля PKCS#11 блокирует система, а подписать модуль «правильно» чужой команде нельзя. Человек видит при этом тексты, которые причину не называют:

Сборка	Что видит человек
по умолчанию (без PKCS#11)	`Options error: Unrecognized option … pkcs11-providers (2.6.14)`
с PKCS#11	`PKCS#11: Cannot initialize provider … CKR_FUNCTION_FAILED`

OpenVPN Connect 3.8.1 не умеет ни PKCS#11, ни связку ключей.

Рабочий путь — интерфейс управления openvpn (management-external-key). openvpn не загружает ничего: в момент рукопожатия он присылает по локальному сокету хэш, и его подписывает агент ключом Secure Enclave (alatyr-agent vpn serve-key). Проверено 2026-09-23 настоящим ключом анклава на сборках из самого Tunnelblick:

Сборка `openvpn`	Итог
2.4.12	не поддерживается
2.5.9 (OpenSSL 1.1.1w)	рукопожатие прошло
2.6.14 (OpenSSL 1.1.1w)	рукопожатие прошло
2.6.14 (OpenSSL 3.0.16, сборка по умолчанию)	рукопожатие прошло

Пределы этого пути, и их надо знать заранее:

Это путь командной строки. Графический Tunnelblick профиль с management не поднимет — у него свой клиент интерфейса управления. Поднимать туннель — sudo openvpn --config …, как на Linux.
Нужны две стороны: alatyr-agent vpn serve-key в сеансе сотрудника и openvpn от root. Остановили serve-key — следующее рукопожатие (в том числе плановая смена ключей сеанса) не пройдёт.
Подпись получает любой процесс root, открывший этот сокет. serve-key подключается к сокету в /var/run и проверяет по ядру, что на том конце root; подменить сокет пользователь не может. Но root на машине может всё, в том числе поднять свой сокет по этому пути и попросить подпись. Это осознанная граница: ключ защищён от других программ пользователя, а не от администратора машины — так же, как на Windows и Linux.
Туннель с интерфейсом tun от root на маке ещё не проверялся — рукопожатие выше шло без туннельного интерфейса (dev null), выдача цели с живым одобрением — отдельно.

Дубль имени профиля глушит OpenVPN GUI молча¶

Проверено на Windows 11.

Если один и тот же файл профиля лежит в обоих каталогах, которые читает OpenVPN GUI —

C:\Program Files\OpenVPN\config\<имя>.ovpn        (машинный)
C:\Users\<кто>\OpenVPN\config\<имя>.ovpn          (пользовательский)

— то запуск подключения не делает ничего:

процесс openvpn.exe не появляется;
каталог журналов %USERPROFILE%\OpenVPN\log остаётся пустым — файла нет вовсе, смотреть не во что;
GUI живёт в трее и ошибки не показывает.

Лечится удалением одного из двух файлов. Ровно в этот момент на машине могут стоять и наш сертификат, и наш ключ в TPM, а alatyr-agent vpn — печатать готовую строку cryptoapicert: продукт говорит «всё на месте», туннель не поднимается, и причину не называет ни одна сторона.

Отчёт alatyr-agent vpn на Windows такие дубли перечисляет, но вердикт готовности из-за них не меняет — файл в двух каталогах не обязательно ошибка.

«Журнала клиента нет» — это не «клиент не дошёл до подключения»

Это «клиент не запускался». Два разных состояния, и различать их надо по наличию процесса openvpn.exe, а не по содержимому журнала, которого может не быть вовсе.

Профиль из пользовательского каталога требует группы `OpenVPN Administrators`¶

Замер на Windows 11, 2026-09-23, сотрудник без прав администратора.

OpenVPN GUI различает два каталога профилей:

Где профиль	Что происходит
`C:\Program Files\OpenVPN\config\` (кладёт администратор)	подключается у любого пользователя
`%USERPROFILE%\OpenVPN\config\`	только у членов группы `OpenVPN Administrators`; остальным GUI показывает «Starting this connection (…) requires membership in "OpenVPN Administrators" group. Do you want to add yourself to this group?»

Правило принадлежит самому OpenVPN: профиль в пользовательском каталоге может содержать что угодно, включая скрипты, и запускать его от имени службы разрешено только доверенной группе. Установщик OpenVPN группу не заводит.

Поэтому раскладывайте профиль в машинный каталог. Если он всё же нужен в пользовательском — заведите группу, добавьте сотрудника, и членство вступит в силу после перелогина.

Поправка к прежней редакции

Раньше здесь было написано, что группа не нужна. Это верно только для профиля в машинном каталоге: на проверочной машине после удаления дубля остался именно он.

Отзыв действует только через `crl-verify` на вашем сервере¶

Alatyr отзывает сертификат у своего УЦ. Принудить сервер доступа перепроверить уже принятую личность он не может: без строки crl-verify со свежим списком отозванный сертификат продолжает подключаться, и агент на это не влияет.

Отчёт alatyr-agent vpn говорит об этом отдельной строкой при каждом запуске — именно потому, что промолчать значило бы оставить ложное чувство, что всё сделано.

Настройка серверной стороны — «Приёмники сертификатов».

Адрес на интерфейсе и успешный пинг про туннель не говорят¶

Измерено на Windows: после убитого клиента виртуальный адаптер сохранил адрес туннеля, а пинг адреса сервера отвечал успехом — при полностью отсутствующем туннеле.

Единственный надёжный ответ на вопрос «туннель есть?» даёт сторона сервера: список клиентов или соответствующая строка в его журнале. Ни адрес на интерфейсе клиента, ни пинг адреса сервера доказательством не являются: на Linux адрес сервера туннеля может быть достижим по обычной сети.

Неверный PIN токена на Linux расходует попытку чипа¶

На Linux клиент открывает ключ PIN'ом токена, и неверный PIN — это не бесплатная диагностика: счётчик защиты от подбора в TPM увеличивается. На живом чипе это цена, а не проба.

Отказ выглядит как ошибка проверки в чипе, туннель не поднимается.

PIN спрашивается на Linux и не спрашивается на Windows¶

Это разница механизмов, а не настройки, и её стоит учесть при планировании необслуживаемого запуска:

Windows — ключ CNG под платформенным провайдером открывается без ввода, необслуживаемый клиент возможен сразу;
Linux — PIN токена нужен, и отдаётся он клиенту через служебный канал management (флаг --unattended у команды отчёта). Через обычный ввод это не работает: запрос PIN уходит в консоль, которой у службы нет.

Сертификат цели `vpn` сам не перевыпускается¶

По истечении срока цель vpn автоматически не перевыпускается — в отличие от wifi и ad_logon. Вернуть её можно командой alatyr-agent reissue vpn на устройстве либо переустановкой агента. Срок — год; следить за ним должен администратор. Подробнее — Агенты → Продление.

Профиль клиента продукт не пишет¶

Alatyr печатает строки, описывающие его ключ, и ничего больше. Адрес сервера, якорь доверия, маршруты и политика — ваши, и продукт их не сочиняет и не переписывает. Если вы ждали от агента готового .ovpn — его не будет намеренно.