OpenVPN: Часть 3 — Вход через Keycloak (SSO и двухфакторная аутентификация)

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

Решение — отдать проверку пользователя системе единого входа. Сотрудник подключается к VPN, клиент открывает браузер, человек входит в корпоративную учётную запись с паролем и одноразовым кодом, и только после этого туннель поднимается. Отключили учётную запись в одном месте — пропал и доступ к VPN.

В качестве такой системы часто используют Keycloak — сервер учётных записей с открытым исходным кодом. Штатной «кнопки Keycloak» в OpenVPN нет. Реальных путей два, и они зависят от редакции сервера.

Путь 1. Access Server и SAML

OpenVPN Access Server, начиная с версии 2.11, поддерживает вход по SAML. Keycloak умеет работать поставщиком удостоверений (IdP) по SAML, поэтому связка собирается средствами обоих продуктов без стороннего кода. В документации Access Server для Keycloak есть отдельное руководство.

Порядок настройки по документации Access Server:

1. Передать данные сервиса в Keycloak. В Access Server есть метаданные поставщика услуг (SP): идентификатор и адрес приёма ответов (ACS). В Keycloak создаётся клиент типа SAML: его Client ID равен идентификатору SP, а адрес ACS вносится в список разрешённых адресов перенаправления.
2. Передать данные Keycloak в Access Server. У каждой области (realm) Keycloak есть адрес метаданных SAML вида https://sso.example.ru/realms/<realm>/protocol/saml/descriptor. Его указывают в настройках SAML в веб-интерфейсе Access Server.
3. Включить SAML для всех пользователей или для отдельных групп.
4. Выдать доступ пользователям на стороне Keycloak.
5. Проверить вход: пользователь выбирает профиль в OpenVPN Connect, клиент открывает страницу входа Keycloak в браузере, после успешного входа туннель подключается.

Важная деталь: при входе через SAML встроенная двухфакторная аутентификация Access Server (TOTP) не работает. Второй фактор настраивается на стороне Keycloak.

Ограничение для российских компаний то же, что описано в первой части цикла: Access Server продаётся по подписке, а оплатить её российской картой нельзя. Без подписки доступно только два одновременных подключения.

Путь 2. OpenVPN Community и openvpn-auth-oauth2

Для свободного OpenVPN Community есть внешний проект openvpn-auth-oauth2 с лицензией MIT. Это отдельная служба, которая подключается к интерфейсу управления OpenVPN и проводит пользователя через вход по OpenID Connect. Keycloak в списке поддерживаемых поставщиков есть. Проект работает как клиент интерфейса управления или как подключаемый модуль (plugin) для Linux и FreeBSD.

Как проходит вход

1. Клиент подключается к серверу OpenVPN.
2. Сервер сообщает openvpn-auth-oauth2, что пользователь ожидает проверки.
3. Служба возвращает адрес для входа, сервер передаёт его клиенту, клиент открывает браузер.
4. Пользователь входит в Keycloak; Keycloak перенаправляет браузер обратно на службу с кодом авторизации, служба обменивает код на токены.
5. Служба разрешает или запрещает подключение, и сервер поднимает туннель либо отказывает.

Требования

По документации проекта: сервер OpenVPN не ниже 2.6.2 (Access Server не поддерживается), клиент — не ниже 2.5.0 с поддержкой входа через браузер. Проверенно работают OpenVPN GUI из пакета Community 2.6 и новее для Windows, Tunnelblick 4 для macOS, Viscosity, а в Linux — клиенты на основе библиотеки OpenVPN 3 (3.9 и новее). OpenVPN Connect поддерживается частично, а модуль NetworkManager для GNOME с таким входом не работает. Это нужно учесть до внедрения: клиенты сотрудников должны быть из списка.

Настройка OpenVPN

В конфигурацию сервера добавляются строки из документации проекта:

management /run/openvpn/server.sock unix /etc/openvpn/password.txt
management-client-auth
auth-user-pass-optional
auth-gen-token 28800 external-auth

• management … unix — интерфейс управления на локальном сокете с паролем из файла;
• management-client-auth — решение о допуске клиента принимает внешняя служба;
• auth-user-pass-optional — клиент не обязан вводить логин и пароль в самом OpenVPN;
• auth-gen-token 28800 external-auth — после входа сервер выдаёт клиенту токен на 8 часов. Без него при каждой смене ключей (по умолчанию раз в час) пользователю пришлось бы проходить вход заново.

Настройка Keycloak

В нужной области Keycloak создаётся клиент:

• тип — OpenID Connect, включена аутентификация клиента (Client authentication);
• в списке разрешённых адресов перенаправления — адрес службы, например https://vpn-login.example.ru/oauth2/callback;
• на вкладке Credentials — секрет клиента.

Настройка openvpn-auth-oauth2

Минимальный файл конфигурации в формате YAML по документации проекта:

http:
  listen: ":9000"
  baseurl: "https://vpn-login.example.ru"
openvpn:
  addr: "unix:///run/openvpn/server.sock"
  password: "<пароль из /etc/openvpn/password.txt>"
oauth2:
  issuer: "https://sso.example.ru/realms/company"
  client:
    id: "openvpn"
    secret: "<секрет клиента из Keycloak>"

baseurl — адрес, который откроется в браузере пользователя. Он должен быть доступен по HTTPS: часть клиентов, например Viscosity, по умолчанию отказывается открывать адрес без шифрования. Обычно службу ставят за обратный прокси с сертификатом.

Двухфакторная аутентификация в Keycloak

В обоих путях второй фактор проверяет Keycloak, а не OpenVPN. Самый простой вариант — одноразовые коды из приложения (TOTP):

1. В настройках области проверить политику одноразовых паролей (алгоритм, длина кода, период).
2. Для пользователей включить обязательное действие «Configure OTP»: при следующем входе Keycloak попросит отсканировать QR-код в приложении-аутентификаторе.
3. Проверить, что поток входа (Authentication flow) области требует OTP для нужных пользователей.

Так вход в VPN получает тот же второй фактор, что и остальные корпоративные сервисы на Keycloak.

Что выбрать

Типичные ошибки

• Нет auth-gen-token. Пользователя каждый час выбрасывает на страницу входа.
• Адрес службы по HTTP. Часть клиентов не откроет страницу входа, а пароль и код пойдут по сети открытым текстом.
• Неподходящие клиенты. Сотрудники на NetworkManager или старом клиенте не смогут войти — список проверенных клиентов нужно выбрать заранее.
• Сертификаты убрали совсем. Внешняя авторизация проверяет человека, а сертификат и tls-crypt по-прежнему защищают сам туннель. Отказываться от них не стоит.

Внедрение Keycloak и единого входа для VPN и других сервисов компании можно заказать на странице «Настройка Keycloak / SSO».