Skip to main content

00 — Обзор архитектуры

Это входной документ. Он даёт картину целиком и ссылается на остальные. Цель системы: управляемый клиентский VPN для розничной сети — 12 регионов × 5–6 магазинов, роутеры MikroTik hAP ac² на RouterOS v7+ (нативный WireGuard), которыми управляет наш control plane через ROS API. Здесь документируется только клиентская часть (оркестрация самих роутеров — отдельная тема).

Из чего состоит система​

Система делится на четыре слоя. Их полезно держать в голове раздельно, потому что они живут на разных временных масштабах и ломаются по-разному.

1. Data plane (между магазинами). Внутри региона между роутерами поднят full mesh WireGuard-туннелей — трафик магазин↔магазин идёт напрямую. Поверх туннелей бежит BGP.

2. Control plane маршрутизации (BGP). В каждом регионе одна точка входа выступает route-reflector'ом: роутеры держат iBGP-сессию с RR, а не друг с другом, и узнают маршруты через него. Next-hop сохраняется, поэтому трафик всё равно идёт напрямую по mesh-туннелям. То есть data plane — mesh, control plane — звезда к RR. Это не противоречие, а классическое разделение «full-mesh underlay + route-reflector overlay».

3. Региональная точка входа (WG-сервер для клиентов). Один узел на регион, к которому подключаются роуминговые клиенты (телефоны/ноуты сотрудников и директоров). Он же RR для региона. Клиентский трафик входит здесь и дальше по BGP уходит в нужный магазин.

4. Control plane клиентов. Наш сервис, который: выпускает доступ по одноразовой ссылке, ведёт реестр клиентов, регистрирует/снимает их как WG-пиры на региональных серверах, доставляет конфиги (через MDM или подписку sing-box) и выполняет миграцию между регионами.

Сбоку — Telegram-ассистент. Канал уведомлений, подтверждений (аппрув миграции, второй фактор) и «пинков» пользователю (особенно на iOS — «открой приложение, чтобы применить»).

Путь клиента в двух абзацах​

Сотруднику выдаётся одноразовая ссылка. По клику control plane определяет канал доставки (Apple / Android / Windows / Linux), регистрирует клиента в БД, заводит его как WG-пира на региональной точке входа и доставляет конфиг — либо тихо через MDM (управляемые устройства), либо как подписку sing-box (см. файл 05). Клиент поднимает туннель и работает.

Если клиента надо перевести в другой регион, control plane заводит его пира на новой точке входа, обновляет отдаваемый конфиг (новый pool-IP, endpoint и серверный pubkey), дожидается рукопожатия на новом сервере и только потом снимает старого пира. Это не «смена endpoint», а перенос пира — подробности в файле 03.

Ключевые решения, принятые по ходу​

  • Модель адресации B (пул IP на регион): клиент получает разный tunnel-IP в каждом регионе. BGP остаётся чистым (каждый сервер владеет своим агрегатом), ценой большего числа изменений в конфиге при миграции. См. файл 01.
  • Целевой RTO — минуты. Секундный failover не требуется; это разрешает использовать и DNS-failover, и подписочную модель доставки.
  • iOS — узкое место. Штатный WireGuard-app переконфигурируется только через MDM. Чтобы получить удалённый реконфиг без MDM, выбран sing-box (WG как транспорт + подписка). См. 05–06.

Глоссарий​

  • Control plane — наш управляющий сервис (роутеры + клиенты).
  • Точка входа / entry point — региональный WG-сервер, к которому подключаются клиенты; он же BGP RR.
  • Re-homing (перенос пира) — перевод клиента с одной точки входа на другую; больше чем смена endpoint.
  • MDM — Mobile Device Management (Fleet/Scalefusion); тихая доставка профилей на управляемые устройства.
  • Подписка (subscription) — URL, по которому клиент (sing-box) сам тянет и обновляет конфиг.
  • Managed / unmanaged — устройство, заэнролленное в MDM / личное (BYOD) без MDM.
  • RTO — Recovery Time Objective, целевое время восстановления после сбоя.

Индекс документов​