Skip to main content

02 — Доставка через MDM

Как MDM реально доставляет конфиги, чем отличаются платформы, какие задержки ждать, и почему MDM нельзя класть в основу failover.

Что MDM делает на самом деле​

MDM — это не транспорт, а две функции сразу:

  1. Тихое применение конфига без действий пользователя.
  2. Управляемый trust-anchor на устройстве (профиль ставится в системное хранилище, ключ уезжает в keychain мимо пользователя).

Если эти две функции заменить чем-то своим (агент + device-credential), MDM из схемы выпадает, и конфиги можно гонять по публичной сети напрямую (см. файл 03). Поэтому «нужен ли MDM» = «есть ли у меня другой способ тихо применить конфиг и держать доверие на устройстве».

Тихо — только на заэнролленном устройстве​

«Тихо» — свойство managed-популяции, не схемы вообще. И степень тишины зависит от уровня управления:

  • Apple supervised (корпоративные, через ADE) — полностью молча, включая установку профиля и приложения.
  • Apple user-enrolled (BYOD) — молча на обновления, но первичный энроллмент требовал согласия пользователя; есть ограничения по разделению данных.
  • Android Enterprise (под DPC) — managed config применяется молча.
  • Unmanaged / BYOD без MDM — тихого пути нет в принципе.

По платформам — канал и нюансы​

  • Apple: профиль .mobileconfig с VPN payload. Декларативно — заменил профиль, ОС применила. Для WireGuard на устройстве должно стоять приложение WireGuard (или своё на NetworkExtension); MDM может доставить и его (managed app).
  • Android: managed config через Android Enterprise. Тоже декларативно.
  • Windows: у WireGuard нет Apple-подобного VPN-payload. «Тихо» = положить .conf + выполнить скрипт под агентом (wireguard /installtunnelservice, перезапуск службы). Императивно.
  • Linux: не MDM, а твой агент — .conf + wg syncconf/wg-quick. Интервал и поведение полностью под твоим контролем.

Примерные задержки доставки​

Гарантий нет ни у кого — всё best-effort, «цифра» это распределение с длинным хвостом. Для бодрствующего онлайн-устройства:

ПлатформаТипичная задержка (онлайн)Хвост
Apple (iOS/macOS)секунды – 1–2 мин (APNs будит, чекин, тянет команду)спящее/офлайн — не ограничен
Android Enterpriseсекунды – пара минут (триггер через FCM)аналогично
Windows (Intune)минуты; без форс-синка — часы (синки разрежены, ~до 8ч)худший на доставку
Linux (свой агент)сколько настроишь (хоть раз в минуту)под твоим контролем

Главное — хвост, а не среднее. Для спящего/офлайн устройства на Apple/Android доставка не ограничена по времени. Но спящее устройство и не гоняет трафик через туннель — failover ему в эту секунду не нужен. Когда проснётся и попробует туннель, его подхватит DNS-путь (см. файл 04), без зависимости от того, долетел ли MDM-пуш.

Порядок при смене конфига (важно)​

MDM-пуш — это fire-and-forget: ты получаешь «профиль установлен», но не «туннель поднялся и гонит трафик». Поэтому при любой смене конфига (особенно миграции региона) порядок жёсткий — подробно в файле 03, кратко здесь:

  1. завести пира на новом сервере (его pubkey там — до переключения);
  2. запушить новый профиль через MDM;
  3. подтвердить по самому WG-серверу (видим handshake), а не по ответу MDM;
  4. только потом снять пира со старого сервера.

Нарушишь порядок — клиент прилетит на сервер, который его не знает, и «тихо» превратится в «тихо отвалился».

Почему MDM не годится для failover​

Failover точки входа должен укладываться в секунды–десятки секунд. MDM — это timescale управления конфигурацией: даже «хороший случай» это минута–две, а хвост не ограничен. Завязать доступность на ре-пуш профиля = прицепить требование секундного масштаба к минутному и ненадёжному каналу. Failover делается на уровне DNS/маршрутизации/клиента (файл 04), а MDM остаётся для первичной выдачи и редкой катастрофы «упал весь регион».

Роль MDM при использовании sing-box​

Если уходишь на подписочную модель (sing-box, файл 05), MDM не исчезает, но роль становится лёгкой:

  • один раз доставить приложение (через MDM/VPP) на управляемые устройства;
  • при желании запушить URL подписки как managed-app-config — тогда даже первичный импорт становится тихим.

Это разовая операция установки, а не пуш конфига на каждое изменение. Все последующие изменения (включая миграцию региона) едут по подписке, не по MDM.