Сценарии
Два типовых сценария: единая точка выхода в нужном регионе и композиция с уже развёрнутым VPN-стеком.
Сценарий 1: единая точка выхода в нужном регионе
Корпоративное окружение, где часть рабочих сервисов, B2B-порталов или регуляторных интерфейсов доступна только из определённых регионов, а организация физически находится в другом.
[клиенты в офисе]
│
▼
┌───────────────────────────────────┐
│ Мастер-узел relay на шлюзе │
│ организации. Включена роль │
│ выходного узла. Хранит политику. │
└───────────────┬───────────────────┘
│
┌───────────────┴───────────────┐
│ │
Маршрут A: По умолчанию:
домены и адреса целевых трафик идёт прямо
сервисов из региона X → с мастер-узла.
выходной узел в регионе X.
│
▼
┌───────────────────┐
│ Выходной узел │
│ relay в регионе X │
└─────────┬─────────┘
│
▼
[целевые сервисы с гео-фильтрацией]
Что это даёт
- Доступ к рабочим сервисам, которые отказывают по гео-адресу источника запроса.
- Отказоустойчивость на уровне политики: при недоступности
целевого выходного узла соединение явно ломается с ошибкой
(
connection refused/host unreachable). Незаметного обхода напрямую — с риском засветить настоящий адрес — не происходит. - Самоконтроль человеческого фактора: пользователь не может «забыть включить нужный VPN». Маршрут зашит в политике на шлюзе и применяется всегда, без действий со стороны клиента.
- Никаких настроек на клиентах. Смена региона выхода — это правка политики на мастер-узле; машины пользователей не трогаются.
- Непрерывность работы при отвале мастера. Выходные узлы продолжают работать на закешированной политике; падает только возможность менять её, не пропускать трафик.
Минимальная топология
Два узла: мастер (с включённой ролью выходного узла) на шлюзе организации + один выходной узел в другом регионе. Дальше масштабируется добавлением выходных узлов в нужных регионах — каждое добавление это новая виртуальная машина и одна правка в политике; пользователи об этом не узнают.
Сценарий 2: композиция с уже развёрнутым VPN-стеком
Когда в организации уже работает классический VPN — например, OpenVPN. Поверх OpenVPN удобно ставить административную обёртку: PritunlТолковый opensource-проект, экономит время по сравнению с ручной настройкой OpenVPN. Менять пользовательский слой при появлении relay не нужно.
[сотрудники]
│
│ VPN-клиент (OpenVPN)
▼
[шлюз организации]
├── OpenVPN-сервер
│ терминирует VPN-сессии,
│ выпускает трафик в локальную сеть шлюза.
│ Управляется через Pritunl (если используется).
│
└── ololo-relay
│
│ применяет политику к исходящему трафику
▼
┌──┴───────────────────────────────────┐
│ │
уходит с этого же направляется на
узла напрямую другой выходной
(роль выходного узла узел relay
включена в самом relay) в другом регионе
│
▼
[выходной узел relay]
│
▼
[исходящий трафик
из другого региона]
Что это даёт
- Не требует переустройства существующей инфраструктуры. Пользователи продолжают подключаться к привычному OpenVPN; настройки на устройствах не меняются.
- Разделение ролей. OpenVPN (с Pritunl) отвечает за доступ пользователей: аутентификацию, OTP, аудит соединений. Relay отвечает за выбор региона выхода для разных классов трафика.
- Гибкость без замены стека. Добавить выходной узел в новом регионе — это развернуть ещё одну виртуальную машину, прописать её в политике и сделать пару кликов в административном интерфейсе — хоть с десктопа, хоть с телефона.
- Тестирование локализованных продуктов. Посмотреть, как сервис выглядит для клиентов из другого региона: валюты, цены, контент, доступность функций, корректность гео-чувствительной выдачи.
Минимальная топология
Два узла: на шлюзе организации работает связка OpenVPN-сервер + relay (мастер с включённой ролью выходного узла); второй узел — выходной, в другом регионе. Дальше масштабируется по числу нужных регионов выхода.