Pritunl high availability cluster

Почему этот продукт

VPN-точка входа — инфраструктура, от которой зависят другие команды; одна ВМ — единая точка отказа. Этот продукт превращает Pritunl OSS в действительно отказоустойчивый сервис в Yandex Cloud:

• Zero-touch настройка. При первом запуске развёртывание настраивает себя само: создаёт VPN-сервер, организацию и первого пользователя, открывает маршруты до ваших подсетей VPC, направляет клиентов на VIP и кладёт учётные данные администратора и API в Lockbox. Никакого мастера в веб-интерфейсе, SSH и default-password — взяли учётные данные, скачали первый профиль, подключились. (Большинство HA-сборок Pritunl настраиваются руками в веб-интерфейсе при каждом развёртывании.)
• REST API включён из коробки. HMAC REST API Pritunl включается автоматически, токен и секрет лежат в Lockbox — можно скриптовать пользователей, профили и изменения сервера с первого дня, без ручного включения.
• Настоящее общее состояние, а не синхронизация конфигурации. Все данные Pritunl (пользователи, серверы, организации) хранятся в кластере Yandex Managed MongoDB из трёх хостов. Оба узла видят одну и ту же конфигурацию сразу; нет ни лага репликации, ни механизма синхронизации, который может сломаться.
• Переключение без split-brain. Выбор лидера построен на атомарном MongoDB-лизинге с монотонными fencing-токенами. Два узла не могут быть активными одновременно, а устаревший экс-лидер не может переписать маршруты после потери лизинга.
• Оба пути трафика переключаются вместе. Входящий трафик следует за health-check балансировщика; обратный — за next-hop таблицы маршрутизации VPC. Демон переключает оба пути вместе со сменой лидерства, поэтому трафик никогда не сходится на полуживом узле.
• Клиенты сохраняют свою идентичность. Маршрутизируемый режим без source NAT: VPN-клиенты видны внутри VPC под своими реальными VPN-адресами, поэтому группы безопасности, правила межсетевого экрана и аудит работают по каждому клиенту.
• Облачно-нативно и без ключей. Без файлов ключей сервисного аккаунта: демон использует короткоживущие IAM-токены из сервиса метаданных, а все секреты хранятся в Yandex Lockbox.
• Создан специально для Yandex Cloud. Собственные мультиоблачные инструменты Pritunl не интегрируются с Yandex Cloud; этот продукт закрывает пробел нативным failover через таблицы маршрутизации YC, Managed MongoDB, health-gating на NLB и Lockbox — отказоустойчивый VPN, работающий «по-яндексовски» из коробки.

Полное описание

Pritunl HA разворачивает два VPN-сервера Pritunl OSS (Ubuntu 24.04) как активно-пассивную пару в разных зонах доступности за одним статическим публичным VIP на сетевом балансировщике нагрузки. Кластер Yandex Managed MongoDB из трёх хостов (TLS, по хосту в каждой зоне доступности) хранит всё состояние Pritunl и лизинг лидерства, поэтому оба узла всегда обслуживают идентичную конфигурацию.

Демон переключения работает на обоих узлах. Каждые ~5 секунд узел пытается получить или продлить MongoDB-лизинг (TTL 15 секунд) атомарным условным обновлением с монотонным fencing-токеном. Держатель лизинга при успешной локальной проверке здоровья гарантирует работу Pritunl, переписывает next-hop клиентского пула в таблице маршрутизации VPC на себя и сообщает балансировщику о готовности (/healthz = 200). Остальные узлы отвечают 503 и остаются пассивными.

Переключение покрывает оба направления трафика сразу. Входящий (клиент -> VPN): NLB пересылает клиентский трафик только на узел, проходящий health-check. Обратный (ресурс VPC -> VPN-клиент): next-hop маршрута клиентского пула указывает на внутренний IP активного узла и переписывается через API Yandex Cloud при смене лидера. Каждое изменение маршрута несёт fencing-токен, поэтому устаревший экс-лидер отклоняется.

Демон отказывает безопасно (fail-closed): если любой шаг после получения лизинга не удался (Pritunl не работает, IAM-токен недоступен, переключение маршрута отклонено), узел отвечает 503 и активно освобождает лизинг, чтобы здоровый сосед перехватил его сразу, не дожидаясь истечения TTL. При любом сомнении узел уходит в пассив; обслуживание входящего трафика без обратного пути исключено. Автоматического возврата на прежний узел нет — восстановившийся узел остаётся пассивным, пока не откажет активный, что исключает «дребезг».

Полная сходимость инфраструктуры — около 20-60 секунд (graceful-остановка узла добавляет окно его выключения; реальный краш — по нижней границе). Переключение — это переподключение клиента к тому же VIP с сохранением VPN-адреса: OpenVPN обычно за ~30-60с, но при graceful-остановке узла может занять до нескольких минут, т. к. backoff реконнекта OpenVPN-клиента растёт, пока идёт сходимость (краш быстрее; помогает ограничение connect-retry на клиенте). OpenVPN работает поверх TCP, который идёт по надёжному TCP-пути балансировщика.

Ключевые возможности

• Активно-пассивная пара Pritunl OSS в двух зонах доступности, один статический публичный VIP.
• Zero-touch настройка: VPN-сервер, организация и первый пользователь создаются автоматически при первом запуске; учётные данные администратора и API — в Lockbox; REST API Pritunl включён. Без мастера в веб-интерфейсе и без SSH.
• OpenVPN поверх TCP (порт 1194), идёт по надёжному TCP-пути NLB, который Yandex распределяет надёжно. WireGuard и опция OpenVPN-over-UDP отложены до общедоступности UDP-балансировки на Yandex NLB (см. «Ограничения»).
• Всё состояние — в кластере Yandex Managed MongoDB 8.0 из трёх хостов (TLS, PRODUCTION) — без синхронизации конфигурации и общего файлового хранилища.
• Атомарный MongoDB-лизинг с fencing-токенами для выбора лидера: без split-brain, устаревший экс-лидер не может изменять маршруты.
• Двухпутевое переключение: health-gate NLB для входящего трафика, next-hop таблицы маршрутизации VPC для обратного; переключаются вместе за ~20-40 секунд.
• Fail-closed демон: при любом сбое узел уходит в пассив и отдаёт лизинг; без автоматического failback, без «дребезга».
• Маршрутизируемый режим без source NAT: VPN-клиенты видны в VPC под реальными VPN-адресами для правил межсетевого экрана и аудита.
• HA-тюнинг без ручной настройки: сервер автоматически реплицируется на оба узла (горячий резерв), пул потоков под число CPU узла, а ping-таймауты OpenVPN снижены для быстрого переподключения клиента после переключения — ничего из этого настраивать вручную не нужно.
• Встроенная двухфакторная аутентификация: PIN пользователя плюс OTP (Google Authenticator). Со стандартным OpenVPN-клиентом пароль подключения = PIN+OTP (проприетарный клиент не нужен).
• Отдельный балансировщик веб-интерфейса: у админ-консоли свой VIP, достигающий любого живого узла (независимо от того, какой узел активен по VPN), с опциональным Let’s Encrypt для доверенного сертификата на обоих узлах.
• OpenVPN поверх TCP идёт по надёжному TCP-пути балансировщика и работает сквозь VIP. WireGuard и OpenVPN-over-UDP появятся, когда Yandex сделает UDP-балансировку на NLB общедоступной (см. «Ограничения»).
• Без ключей: короткоживущие IAM-токены из метаданных инстанса; секреты (MongoDB URI, CA) в Yandex Lockbox; сервисный аккаунт с минимальными правами (lockbox.payloadViewer, vpc.privateAdmin).
• SSH только по ключу; парольная аутентификация отключена.

Что создать перед развёртыванием

Продукт создаёт пару VPN-узлов и их HA-инфраструктуру (две ВМ, сервисный аккаунт, группу безопасности, NLB с VIP, кластер Managed MongoDB, таблицу маршрутизации, секрет Lockbox со строкой подключения). Перечисленные ниже ресурсы он намеренно не создаёт — они долгоживущие или чувствительные к безопасности, и ими управляете вы. Подготовьте их заранее:

• Три подсети в одной VPC-сети, по одной в каждой зоне доступности: зоны a и b — для VPN-узлов, зона d — для третьей реплики MongoDB. Все три должны принадлежать одной сети — группа безопасности, таблица маршрутизации и балансировщик работают в пределах одной сети.
• Два свободных внутренних IP-адреса — один в подсети зоны a, один в подсети зоны b. Они становятся адресами узлов, целями NLB и next-hop маршрутов, поэтому фиксируются при развёртывании и не должны быть заняты.
• Секрет Lockbox с паролем MongoDB — пароль выделенного пользователя БД pritunl. Развёртывание читает первую текстовую запись текущей версии секрета. См. «Создание секрета с паролем MongoDB» ниже.
• Открытый SSH-ключ для пользователя ubuntu — аварийный доступ для отладки и чтения первоначальных учётных данных Pritunl.
• CIDR клиентского пула вне всех диапазонов подсетей VPC (например, 172.18.0.0/22, если VPC использует 10.0.0.0/8). VPN-клиенты получают адреса из этого пула; он маршрутизируется через таблицу VPC и не должен пересекаться ни с одной подсетью.

Создание секрета с паролем MongoDB

Развёртывание использует первую текстовую запись текущей версии секрета как пароль пользователя MongoDB pritunl. Создайте секрет через CLI Yandex Cloud:

yc lockbox secret create \
  --name pritunl-mongo-password \
  --payload '[{"key":"password","text_value":"<пароль-mongodb>"}]'

В консоли: Lockbox -> Создать секрет -> добавьте одну запись «ключ/значение» с паролем в значении. Выберите этот секрет в поле mongo_password_secret формы развёртывания.

Параметры развёртывания

Поля, отображаемые в форме развёртывания:

• Имя развёртывания — префикс имён всех создаваемых ресурсов (шаблон ^[a-z][a-z0-9-]{2,30}$).
• Подсеть (зона a) — подсеть первого VPN-узла и первого хоста MongoDB.
• Подсеть (зона b) — подсеть второго VPN-узла и второго хоста MongoDB (другая зона доступности).
• Подсеть (зона d) — подсеть третьего хоста MongoDB (третья зона доступности).
• Внутренний IP узла A — свободный внутренний IPv4-адрес в подсети зоны a.
• Внутренний IP узла B — свободный внутренний IPv4-адрес в подсети зоны b.
• Секрет с паролем MongoDB — секрет Lockbox с паролем пользователя БД (первая текстовая запись текущей версии).
• Открытый SSH-ключ — ключ, прописываемый на обе ВМ для пользователя ubuntu.
• Email администратора — email первого VPN-пользователя, создаваемого автоматически (его локальная часть становится именем пользователя).
• Шифрование VPN (опц.) — standard (AES-128/SHA1, по умолчанию) или strong (AES-256/SHA256).
• Двухфакторная аутентификация (PIN+OTP) (опц., по умолчанию выкл.) — требует OTP на сервере и выдаёт первому пользователю управляемый PIN; PIN и OTP-секрет пользователя пишутся в Lockbox-секрет с учётными данными (USER_PIN, USER_OTP_SECRET). Работает с обычными клиентами: пароль подключения = PIN + текущий OTP-код.
• DNS-серверы (опц., по умолчанию 8.8.8.8) — DNS-серверы для клиентов (через запятую), например внутренний резолвер.
• DNS search domain (опц.) — передаётся клиентам.
• Трафик между клиентами (опц., по умолчанию вкл.) — выключение изолирует клиентов друг от друга.
• SSL-сертификат веб-консоли (опц.) — Lockbox-секрет с ключами WEB_SSL_CERT (полная PEM-цепочка) и WEB_SSL_KEY; веб-консоль отдаёт его на обеих нодах вместо самоподписанного. Пусто — остаётся самоподписанный (или используйте Let’s Encrypt в Settings). Приватный ключ остаётся в Lockbox и не попадает в метаданные ВМ.
• CIDR клиентского пула VPN — пул адресов VPN-клиентов; должен быть вне всех диапазонов подсетей VPC.
• Тип окружения — prod или dev; задаёт размеры ВМ, дисков и кластера MongoDB (см. «Архитектура»).

Входящий трафик открыт на 0.0.0.0/0 по TCP 1194 (OpenVPN), TCP 443 (веб-интерфейс Pritunl HTTPS), TCP 22 (SSH, только по ключу — парольная аутентификация отключена) и ICMP. Порт 8080 (/healthz) принимает трафик только из диапазона health-check балансировщика. Исходящий трафик — полнотуннельный интернет-шлюз (TCP все порты + ICMP + UDP в интернет), чтобы VPN-клиенты выходили в интернет через туннель. При необходимости ограничьте доступ на уровне группы безопасности.

После развёртывания: zero-touch настройка

При первом запуске bootstrap настраивает VPN автоматически. На HA-паре ровно один узел (под защитой блокировки в MongoDB) включает REST API Pritunl, пишет учётные данные в Lockbox и создаёт организацию, VPN-сервер, обратные маршруты до ваших подсетей VPC и первого пользователя; задаёт Public Address сервера равным VIP и подавляет первичный мастер настройки Pritunl. Общая MongoDB распространяет всё на оба узла, а демон failover держит сервер горячим на обоих узлах, снимает NAT с маршрутов в приватные (RFC1918) сети (клиенты сохраняют реальные VPN-адреса, маршрутизируемый режим), снижает ping-таймауты (60/120 -> 20/40 для быстрого переподключения) и держит Public Address каждого хоста равным VIP. Чтобы настраивать Pritunl вручную, разверните с pritunl-enable-provision=false.

Что делаете вы после развёртывания:

1. Возьмите учётные данные из Lockbox-секрета <deployment>-<app-id>-api-credentials (выход развёртывания api_creds_secret_id):

   yc lockbox payload get --id <api_creds_secret_id>
   

   В нём ADMIN_USERNAME / ADMIN_PASSWORD (вход в веб-интерфейс) и API_TOKEN / API_SECRET (REST API). SSH и pritunl default-password не нужны.

2. Скачайте профиль первого пользователя и подключитесь. Откройте веб-интерфейс по адресу https://<web_public_ip> и войдите с ADMIN_USERNAME/ADMIN_PASSWORD (сертификат самоподписанный, пока вы не направите DNS A-запись на web_public_ip и не зададите домен Let’s Encrypt в Settings — это HA-безопасно: токен ACME и сертификат лежат в общей MongoDB, любой узел отвечает на проверку, оба отдают доверенный сертификат). В разделе Users первый пользователь (назван по локальной части admin_email) уже существует; скачайте его профиль и подключитесь к VIP.

   У авто-созданного пользователя нет PIN, а на сервере отключён OTP, поэтому аутентификация — только по сертификатному профилю. Если OpenVPN-клиент запрашивает логин/пароль, оставьте пароль пустым. Чтобы требовать двухфакторную аутентификацию, включите PIN + OTP у пользователя в веб-интерфейсе (поддерживается в Pritunl OSS — тогда клиент вводит PIN+OTP как пароль подключения).

3. Привяжите таблицу обратной маршрутизации к своим подсетям — единственный сетевой шаг, который продукт не может сделать за вас (см. «Обратная маршрутизация из VPC к VPN-клиентам» ниже).

4. (Опционально) Добавьте пользователей, задайте домен Let’s Encrypt, включите PIN+OTP или управляйте сервером через веб-интерфейс или REST API.

Доступ к Pritunl по REST API

Провижн включает HMAC-аутентифицируемый REST API Pritunl (в Pritunl OSS он есть) и кладёт API_TOKEN / API_SECRET в Lockbox-секрет с учётными данными. Подписывайте каждый запрос заголовками Auth-Token, Auth-Timestamp, Auth-Nonce, Auth-Signature, где подпись — base64(HMAC_SHA256(API_SECRET, "API_TOKEN&timestamp&nonce&METHOD&path")). Используйте его для автоматизации пользователей, профилей и изменений сервера на https://<web_public_ip>.

Обратная маршрутизация из VPC к VPN-клиентам

VPN-клиенты сохраняют адреса пула внутри VPC (без source NAT), поэтому ресурсам VPC нужен обратный маршрут. Продукт создаёт таблицу маршрутизации, клиентский маршрут которой всегда указывает на активный узел, но не привязывает её к вашим подсетям — ассоциируйте её с каждой подсетью, которая должна достигать VPN-клиентов:

yc vpc subnet update <SUBNET_ID> --route-table-id <route_table_id>

Без этого пакеты от ресурса VPC обратно к VPN-клиенту отбрасываются. Поскольку клиенты сохраняют реальные адреса, вы можете писать правила групп безопасности и вести аудит трафика по адресу каждого VPN-клиента.

Перед удалением развёртывания сначала отвяжите эту таблицу маршрутизации от своих подсетей — развёртывание владеет таблицей и не может удалить её, пока она привязана к подсети (привязывали вы, вам и отвязывать):

yc vpc subnet update <SUBNET_ID> --disassociate-route-table

Ограничения

• Пока только OpenVPN поверх TCP. WireGuard и опция OpenVPN-over-UDP пока не предлагаются: они идут по UDP-пути NLB, а UDP-балансировка на Yandex NLB в тестах была интермиттентной (на одном развёртывании туннель WireGuard прошёл handshake, но перестал пропускать обратный трафик) и всё ещё требует тикета в поддержку. Продукт поставляется с OpenVPN поверх TCP, который работал сквозь во всех тестах. WireGuard/UDP добавим, когда Yandex сделает UDP-балансировку на NLB общедоступной.
• Сходимость переключения ~20-40 секунд. Health-gate NLB и распространение маршрута VPC — независимые ветви; должны завершиться обе.
• Сессии при переключении не сохраняются. Клиенты переподключаются к тому же VIP: OpenVPN — в пределах окна keepalive.
• Нет автоматического failback. Восстановившийся узел остаётся пассивным, пока не откажет активный; именно это исключает «дребезг».
• Zero-touch провижн — opt-out. Организация, VPN-сервер и первый пользователь создаются автоматически при первом запуске, и включается HMAC REST API Pritunl (учётные данные в Lockbox). Задайте pritunl-enable-provision=false, чтобы пропустить провижн и настроить Pritunl вручную в веб-интерфейсе.
• CIDR клиентского пула не должен пересекаться с подсетями VPC, иначе запись в таблице маршрутизации не может быть создана.
• Таблица маршрутизации не привязывается к подсетям автоматически — оператор ассоциирует её сам (см. «Обратная маршрутизация из VPC к VPN-клиентам»).
• Managed MongoDB — платный ресурс, тарифицируемый отдельно от ВМ; кластер из трёх хостов — самая значимая статья расходов развёртывания.
• Одна VPC-сеть. У узлов по одному NIC, и они находятся в одной VPC-сети, а демон failover пишет единственный next-hop (внутренний IP активного узла) в таблицы маршрутизации. Yandex требует, чтобы next-hop маршрута был в той же сети, что и таблица, поэтому VPN-клиенты достигают ресурсов в любой подсети и зоне этой сети, но не ресурсов в другой VPC-сети. В Yandex Cloud нет VPC peering, поэтому размещайте ресурсы, к которым должны достучаться VPN-клиенты, в той же VPC-сети, что и развёртывание.

• Создание VPN-туннелей.
• Обеспечение безопасного доступа к корпоративным ресурсам.

OpenNix осуществляет техническую поддержку пользователей Pritunl в Yandex Cloud. Вы можете связаться с технической поддержкой по электронной почте support@opennix.ru. Время работы технической поддержки с 9:00 до 18:00 (МСК) по рабочим дням.