Как на iPhone разделить маршруты AllowedIPs, туннельный DNS и On-Demand, проверить доступ по IP и имени и не принять недоступный резолвер за полный отказ split tunnel.
Разделите три независимых регулятора
AllowedIPs определяет, какие IP-направления добавляются в included routes туннеля. Строка DNS создаёт отдельные настройки resolver. On-Demand решает, когда система автоматически запускает или останавливает VPN по условиям сети и обращения. Эти три механизма взаимодействуют, но не заменяют друг друга. Поэтому фраза «split tunnel настроен правильно» недостаточна: маршруты могут работать, а разрешение имён — зависеть от недоступного DNS. Не публикуйте конфигурационный файл для проверки: в нём находятся ключи, endpoint и адреса.
Поймите поведение текущего WireGuardKit
В текущем исходном коде wireguard-apple непустой список DNS-серверов превращается в NEDNSSettings, после чего matchDomains получает массив с пустой строкой. Комментарий к коду говорит, что все DNS-запросы сначала должны пройти через DNS туннеля. Apple объясняет: пустая строка делает этот resolver default domain. Отдельно WireGuardKit превращает адреса из AllowedIPs в included routes. Следовательно, ограниченный список маршрутов не означает автоматического ограничения DNS теми же адресами или доменами.
Проведите четыре безопасных наблюдения
Не меняя профиль, сравните доступ к одному публичному IP, одному публичному имени, одному разрешённому внутреннему IP и соответствующему внутреннему имени. Используйте только свои или разрешённые тестовые цели и записывайте результат как «да/нет», без адресов. Если оба IP доступны, а оба имени нет, транспорт и resolver разделились. Если внутренний IP недоступен, проблема не сводится к DNS. Если публичное имя работает, а внутреннее нет, проверяется доступность и зона конкретного DNS, а не весь Интернет. Значок активного туннеля не заменяет эти наблюдения.
Учитывайте On-Demand без ожидания fail-open
Apple описывает VPN On Demand как автоматический запуск или остановку соединения по правилам. Механизм не обещает переключить DNS на локальную сеть, если туннель остаётся активным, но указанный resolver недоступен. Поэтому сценарий «сервер выключен, а On-Demand включён» нужно оценивать как отдельную зависимость. Не выключайте On-Demand на управляемом устройстве ради эксперимента. В пользовательском профиле сначала сохраните исходное состояние и меняйте DNS только в отдельной копии после подтверждения владельца; на рабочем iPhone передайте вопрос администратору.
Передайте матрицу вместо профиля
Для поддержки укажите версию iOS и WireGuard, наличие On-Demand, факт ограниченных AllowedIPs, наличие строки DNS и четыре обезличенных результата. Не отправляйте private key, preshared key, endpoint, внутренние IP, домены и QR-код. Если без изменения профиля видно, что IP работает, а имена нет, попросите проверить доступность туннельного DNS и ожидаемую DNS-политику. Удаление строки DNS может вернуть системный resolver, но одновременно лишить доступа к внутренним именам; это проектное решение, а не универсальный ремонт. Остановитесь до изменения, если назначение DNS не документировано.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; маршруты, matchDomains и назначение On-Demand вручную сверены с текущим кодом WireGuard и документацией Apple.
Источники и проверка
- WireGuard Apple — PacketTunnelSettingsGenerator проверено 2026-08-05
- Apple Developer — NEDNSSettings matchDomains проверено 2026-08-05
- Apple Developer — VPN On Demand rules проверено 2026-08-05
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.