Отчёт по исследованию: региональный VPN-доступ к камерам через MikroTik/BGP
Статус решения: зафиксирован основной подход sing-box + WireGuard + Broker; IKEv2/IPsec остаётся резервной альтернативой.
Контекст: система мониторинга и управления ИТ-инфраструктурой: Hub, MetricForge, MikroTik в филиалах, региональная mesh/BGP-топология.
Цель: дать региональным директорам доступ к камерам своего региона так, чтобы видеотрафик не шёл через головной офис/облако, а входил в сеть через живую региональную точку.
1. Исходная проблема
Сейчас региональные директора подключаются через офис/центральную точку, а затем смотрят камеры филиалов. Из-за этого трафик камер идёт через центральный канал и создаёт лишнюю нагрузку.
Целевая логика:
Региональный директор
-> VPN ingress внутри своего региона
-> региональная BGP/WG mesh-сеть
-> камеры филиалов региона
То есть основная задача не просто “выдать доступ к камерам”, а локализовать клиентский ingress.
2. Сеть и ограничения
2.1 Текущая инфраструктура
- Есть головной офис и облако.
- Между офисом и облаком — IPsec.
- Офис и облако сейчас являются головами звёздной топологии.
- К ним подключены филиалы по L2TP: сейчас около 75, планируется до 100.
- В каждом филиале MikroTik.
- В каждом филиале две основные подсети:
- ПК/офисная сеть;
- камеры.
- Планируется переход со статической маршрутизации на BGP.
- Для регионов планируется дополнительная mesh/full-mesh связность, чтобы трафик внутри региона ходил локально.
2.2 Пользовательские ограничения
- Основные клиенты — iPhone/Android.
- Устройства личные, не корпоративные.
- MDM нежелателен как обязательная часть, потому что устройства BYOD.
- Региональные директора не должны выбирать филиал вручную.
- Допустимо установить отдельный клиент, если это сильно улучшает решение.
- Нужно уметь централизованно отключать уволенного сотрудника.
- Бесшовный failover не обязателен; переподключение допустимо.
- На первом этапе “лучший edge” = любой живой edge нужного региона.
3. Ключевая декомпозиция
Важно разделить две разные задачи:
BGP начинает работать только после того, как клиент уже вошёл в сеть. Поэтому BGP не может сам выбрать точку входа для директора. Нужен отдельный access/control слой.
4. Рассмотренные варианты
4.1 Нативный WireGuard-клиент
Плюсы:
- простой;
- хорошо стыкуется с MikroTik RouterOS v7;
- стандартный протокол;
- Broker может удалять peer при увольнении.
Минусы:
- нет подписки/remote config update;
- смена endpoint/server key требует нового импорта конфига;
- слабый UX на iPhone/Android для нетехнических пользователей;
- failover приходится решать через DNS и синхронизацию peer’ов.
Вывод: годится как fallback/manual mode, но не как лучшее целевое решение.
4.2 MDM + native IKEv2/IPsec
Плюсы:
- нативно поддерживается iOS/Android/Windows/macOS;
- не требует отдельного VPN-приложения;
- можно использовать клиентские сертификаты;
- revoke сотрудника делается серверно через сертификаты.
Минусы:
- MDM для личных телефонов организационно тяжёлый;
- без MDM обновление профиля остаётся ручным;
- failover не должен зависеть от MDM, потому что MDM — канал конфигурации, а не runtime-failover;
- изменение региона/профиля требует переустановки или репуша.
Вывод: оставить как резервный/легаси-вариант, особенно для устройств, где нельзя ставить sing-box.
4.3 Headscale/Tailscale
Плюсы:
- готовый control-plane;
- хорошие мобильные клиенты;
- subnet routers;
- нормальный UX.
Минусы:
- плохо стыкуется с “голым” WireGuard на MikroTik;
- фактически заменяет собственный access-control слой;
- сложнее встроить в уже проектируемую MikroTik/BGP-оркестрацию.
Вывод: сильный ориентир, но не основной выбор для текущей архитектуры.
4.4 NetBird
Плюсы:
- хорошо ложится на routing peers / ZTNA;
- удобный UX;
- есть клиенты под основные платформы.
Минусы:
- не подходит по стоимости/лицензированию.
Вывод: исключён.
4.5 ZeroTier
Плюсы:
- есть официальный пакет для MikroTik на поддерживаемых архитектурах;
- можно строить overlay-сеть.
Минусы:
- модель ближе к L2/SDN, чем к точному access broker;
- политики и HA ingress хуже ложатся на задачу;
- зависимость от архитектуры MikroTik.
Вывод: запасной вариант, но не основной.
4.6 sing-box + WireGuard transport
Плюсы:
- устанавливается один раз как клиент;
- умеет remote profile/subscription;
- Broker может отдавать per-user/per-device конфиг по URL;
- можно менять список endpoint’ов региона без переустановки профиля;
- можно положить несколько WireGuard endpoints региона и использовать client-side failover;
- на проводе это стандартный WireGuard, совместимый с MikroTik;
- не требует MDM;
- revoke делается серверно через удаление peer’ов и инвалидирование подписки.
Минусы:
- требуется отдельное приложение;
- приватный ключ клиента лежит в конфиге, который отдаёт Broker;
- URL подписки становится bearer-secret, его нужно защищать;
- на iOS фоновое автообновление профиля может быть ненадёжным;
- нужно стандартизировать конкретный iOS/Android клиент и версию.
Вывод: основной целевой вариант.
5. Зафиксированное целевое решение
sing-box-compatible client
+ WireGuard transport
+ Broker subscription server
+ MikroTik WireGuard servers на региональных access-edge
+ BGP внутри региона
+ Hub как UI/управление
+ MetricForge как источник health/metrics
6. Роль компонентов
6.1 Hub
Hub — фронтовая обвязка и операторский интерфейс:
- пользователи;
- регионы;
- доступы;
- статус подключений;
- выдача ссылок;
- revoke;
- аудит;
- отображение health по регионам и edge.
Hub не должен сам принимать низкоуровневые сетевые решения. Он вызывает Broker.
6.2 MetricForge
MetricForge остаётся системой сбора метрик:
- доступность MikroTik;
- WireGuard handshake/session stats;
- BGP-сессии;
- наличие маршрутов до camera-prefix региона;
- загрузка каналов;
- packet loss / RTT;
- CPU/RAM/температура;
- состояние uplink.
MetricForge не должен быть control-plane. Он поставляет факты, а Broker принимает решения.
6.3 Broker
Broker — центральный компонент целевой архитектуры.
Он отвечает за:
- выдачу subscription URL;
- генерацию per-device sing-box config;
- хранение пользователей, устройств, регионов, edge-кандидатов;
- выбор живого edge региона;
- создание/удаление WireGuard peers на MikroTik через RouterOS API;
- синхронизацию peer’ов на нескольких edge региона;
- revoke сотрудника;
- аудит;
- reconcile реального состояния MikroTik с БД;
- подготовку данных для Hub.
6.4 MikroTik access-edge
MikroTik в филиале может выполнять роль access-edge, если:
- имеет статический публичный адрес или стабильный endpoint;
- на нём поднят WireGuard server для клиентского доступа;
- он участвует в региональной BGP-топологии;
- у него есть маршруты до camera VLAN региона;
- firewall ограничивает клиентов только разрешёнными подсетями.
7. Клиентский UX
Для регионального директора сценарий должен быть максимально простым.
Дальше пользователь не выбирает филиал. Он просто включает VPN в приложении.
8. Подписка и конфиг клиента
Broker отдаёт клиенту не статический .conf, а актуальный профиль по subscription URL.
В профиль входят:
- private key клиента;
- tunnel IP клиента;
- список WireGuard endpoints региона;
- public keys серверов;
- маршруты только до нужных сетей;
- DNS/routing rules;
- параметры failover;
- update interval.
Важно: subscription URL — это секрет. Его нельзя отправлять в открытом виде через небезопасные каналы, логировать или хранить в аналитике.
9. Intra-region failover
Для падения одного филиала внутри региона используем client-side failover через sing-box.
Принцип:
- Broker отдаёт клиенту несколько endpoints его региона.
- sing-box проверяет их доступность.
- При падении одного edge клиент переключается на другой.
- Бесшовность не требуется: активное соединение с камерой может оборваться, пользователь переподключится.
Минимальная политика выбора:
выбрать любой живой edge региона, у которого есть маршруты до camera-prefix региона
В будущем можно усложнить:
- RTT от клиента;
- загрузка uplink;
- близость к целевым камерам;
- packet loss;
- приоритет филиалов.
10. Cross-region failover
Cross-region failover — это не обычный failover, а миграция.
При переходе в другой регион могут измениться:
- tunnel IP;
- endpoint list;
- server public keys;
- allowed routes;
- firewall policy;
- набор MikroTik, где должен быть установлен peer.
Порядок безопасной миграции:
Критично: сначала завести peer на новом регионе, потом переключать клиента, и только после подтверждённого handshake удалять старую инсталляцию.
11. Revoke уволенного сотрудника
Так как телефоны личные, нельзя полагаться на удаление профиля с устройства. Отключение должно быть серверным.
При увольнении Broker должен:
Даже если приложение и старый конфиг остались на телефоне, handshake не должен проходить.
12. Безопасность
Основные правила:
-
Routes are not security.
То, что клиенту не выдали маршрут, не является полноценной защитой. Ограничения должны быть на firewall edge. -
Один пользователь/устройство = отдельный ключ и отдельный peer.
Нельзя использовать общий ключ региона. -
Subscription URL = bearer-secret.
Нужны TTL, ротация, отзыв, защита от логирования. -
Конфиги нельзя отправлять через Telegram.
Telegram можно использовать для уведомлений и ссылок, но не для тела конфига и не для приватных ключей. -
Peer должен удаляться со всех edge, где он мог быть установлен.
Для этого нужна таблицаpeer_installations. -
Нужна reconcile-петля.
Broker должен периодически сверять БД и фактическое состояние MikroTik.
13. Адресация
Рекомендуемая модель: пулы по регионам/edge.
Пример:
Region 01 director pool: 172.31.1.0/24
edge-01: 172.31.1.0/27
edge-02: 172.31.1.32/27
edge-03: 172.31.1.64/27
Region 02 director pool: 172.31.2.0/24
edge-11: 172.31.2.0/27
edge-12: 172.31.2.32/27
Плюсы:
- понятный аудит;
- можно видеть источник пользователя;
- не нужен NAT для клиентского трафика;
- BGP может рекламировать агрегаты/pools.
Важно заранее решить, будет ли клиент иметь один IP на весь регион или разные IP на разных edge. Для client-side failover проще, если один и тот же клиентский IP заранее разрешён на нескольких edge-кандидатах региона.
14. Firewall policy
На каждом access-edge должны быть правила:
allow src=user_vpn_pool_region_A dst=camera_prefixes_region_A ports=needed
allow src=user_vpn_pool_region_A dst=office/cloud allowed services
reject/drop src=user_vpn_pool_region_A dst=pc_vlan
reject/drop src=user_vpn_pool_region_A dst=other_regions
reject/drop src=user_vpn_pool_region_A any
Особенно важно запретить доступ из директорского VPN pool к ПК-сетям филиалов.
15. Что мониторить
По каждому edge:
- router alive/down;
- RouterOS API reachable;
- WireGuard port reachable;
- active WG sessions;
- latest handshake age;
- rx/tx bytes per peer;
- BGP peer state;
- количество полученных/анонсируемых routes;
- route coverage по camera-prefix региона;
- uplink rx/tx;
- packet loss;
- RTT до офиса/облака/региональных узлов;
- CPU/RAM/temperature;
- наличие публичного IP/endpoint;
- состояние power/uplink, если доступно.
16. Почему Elixir/Phoenix подходит для Broker
Да, Broker логично писать на Elixir/Phoenix.
Причины:
- много долгоживущих процессов: мониторинг edge, reconcile, provisioning jobs;
- удобно моделировать состояние регионов/edge через OTP supervision tree;
- Phoenix LiveView хорошо подходит для operator dashboard;
- Phoenix Channels/PubSub подходят для realtime-статуса в Hub;
- Oban можно использовать для фоновых задач: provision, cleanup, reconcile, revoke;
- Ecto/PostgreSQL хорошо ложится на inventory и audit log.
Broker не должен быть “VPN-сервером”. Он должен быть control-plane/orchestrator поверх MikroTik, sing-box subscriptions и MetricForge.
17. Предварительная модульная структура Broker
Основные bounded contexts:
Accounts— пользователи, роли, регионы доступа;Inventory— регионы, филиалы, MikroTik, prefixes, edge-кандидаты;Devices— пользовательские устройства, installations, keys;Access— policies, subscriptions, sessions;Provisioning— операции с MikroTik;Monitoring— ingestion/агрегация health из MetricForge;Audit— неизменяемый журнал действий.
18. Минимальная модель данных для будущего ТЗ
19. Основные риски
| Риск | Влияние | Компенсация |
|---|---|---|
| iOS sing-box/compatible client нестабилен или неудобен | Высокое | Зафиксировать конкретное приложение/версию; провести PoC на iPhone; держать IKEv2 fallback |
| URL подписки утёк | Высокое | Token hash, revoke, short TTL для первичной ссылки, device-bound subscription, audit |
| Peer остался на MikroTik после revoke | Высокое | peer_installations, reconcile, idempotent cleanup |
| Клиент видит чужие подсети | Критическое | Firewall ACL на edge, не полагаться на AllowedIPs |
| Edge жив, но нет маршрутов до камер | Среднее | route coverage перед выбором edge |
| Слишком много peer’ов на всех edge региона | Среднее | ограничить access-edge candidates; мониторить нагрузку; шардировать pools |
| Конфиги случайно логируются | Высокое | redaction middleware, запрет логирования response body, секреты отдельно |
| BGP full-mesh разрастается | Среднее | route-reflector per region, next-hop preservation |
20. Итоговое решение
Основной вариант:
sing-box-compatible client
+ WireGuard transport
+ Broker subscription server на Elixir/Phoenix
+ MikroTik WireGuard access-edge в филиалах региона
+ BGP для региональной маршрутизации до camera VLAN
+ Hub как UI
+ MetricForge как источник health/metrics
Резервный вариант:
native IKEv2/IPsec
+ client certificates
+ manual/profile-based delivery
Финальная формула:
BGP решает путь внутри региона.
Broker решает, какие edge доступны пользователю.
sing-box решает доставку и обновление client config.
WireGuard на MikroTik даёт транспорт.
Firewall на edge обеспечивает безопасность.
MetricForge даёт факты для выбора живого ingress.
Hub даёт операторский интерфейс.
21. Следующий шаг
Следующий документ должен быть ТЗ на Access Broker.
В ТЗ нужно отдельно описать:
- границы ответственности Broker;
- API для Hub;
- модель данных;
- RouterOS API operations;
- subscription endpoint format;
- sing-box config template;
- revoke flow;
- edge selection flow;
- reconcile flow;
- audit/security requirements;
- интеграцию с MetricForge;
- эксплуатационные сценарии и failure modes.