DNS для VPN на iPhone: хто володіє налаштуванням, вирішує, де воно діє

Введіть адресу приватного резолвера в налаштування Wi-Fi iPhone, і він працюватиме, доки телефон не залишить цю мережу, — саме тоді VPN і має взяти керування. Це перша пастка мобільного DNS: місце, куди ви ввели налаштування, визначає його область дії, а область вужча, ніж припускає більшість. Перш ніж щось змінювати, дайте відповідь на три запитання про розгортання, бо відповіді визначають, який елемент керування слід торкатися. Ставтеся до послідовності як до проєктної перевірки, а не як до полювання за налаштуваннями.

Три запитання, перш ніж вводити адресу резолвера

По-перше, які імена справді потребують особливої обробки? Приватна зона на кшталт corp.example — це простір імен, а не один хост, і відповіддю має бути домен, а не один запис. По-друге, який резолвер для неї авторитетний і хто володіє цією службою? По-третє, який шлях робить цей резолвер доступним із телефона: тунель, маршрутизована мережа Wi-Fi чи щось зовсім інше?

Якщо в когось із цих трьох немає власника, зупиніться. Зміна DNS, зроблена без простору імен, авторитетного джерела й доступного шляху, — це здогад, який у стільниковій мережі провалиться інакше, ніж в офісі.

Запис DNS для Wi-Fi належить цій мережі Wi-Fi

Ручна конфігурація DNS в iOS зберігається для кожної мережі окремо. Вона діє, поки телефон підключений до цього SSID, і перестає діяти, коли ні, а отже, не може керувати стільниковим трафіком або описувати, що робить клієнт VPN. Правити її, щоб полагодити застосунок, який збоїть у стільниковій мережі, — це змінювати налаштування, яке збійний шлях ніколи не читає.

Це не робить DNS для окремих мереж марним. Для домашньої лабораторії або єдиного офісного SSID це найпростіший спосіб дістатися внутрішнього резолвера, і він чесний щодо своєї межі.

Механізм DNS у VPN залежить від протоколу та клієнта

Постачальник пакетного тунелю в iOS може налаштовувати DNS через API налаштувань DNS від Apple, який відкриває тунелю, що володіє з'єднанням, адреси резолверів і зіставлення доменів. Власна конфігурація IKEv2 може отримувати DNS через корисне навантаження конфігурації IKE, коли шлюз його проштовхує, але чи застосовує конкретний клієнт отримане — це деталь реалізації, яку треба перевірити. Клієнт на основі застосунку може повністю реалізувати власний шлях розв'язання.

Це різні точки інтеграції, і результат однієї з них не стає правилом для всіх iPhone. Підтримуваний механізм — це те, що профіль або постачальник документує для використовуваного протоколу.

Вирішуйте за володінням, а не за зручністю

Якщо пристрій керований, власник профілю має доставляти налаштування DNS разом із конфігурацією VPN, щоб повторна реєстрація відновлювала його без того, щоб користувач щось пам'ятав. Якщо тунелем володіє застосунок постачальника, його екран налаштувань — місце, куди дивитися, а його документація — авторитет у тому, що він може розділяти. Якщо телефон особистий і потреба — одне внутрішнє ім'я в одній мережі, налаштування для мережі є співмірним.

Правило рішення коротке: налаштування належить тому місцю, де забезпечується з'єднання. Будь-де інде це локальний виняток, який зітре наступна зміна мережі.

Перевіряйте на шляхах, які телефон справді використовує

Перевірте свіжий запит із застосунку, якому потрібне приватне ім'я, в офісному Wi-Fi, у стільниковій мережі та під час переходу між ними. Застосунок із власною інтеграцією резолвера може піти іншим шляхом, ніж система, тому перевіряйте сам застосунок, а не вкладку браузера, яка випадково працює.

Коли приватне ім'я не працює, збережіть точний текст помилки та стан профілю. Публічний резолвер, який відповідає, що імені не існує, дає правильну відповідь на неправильне запитання, і додавати його поруч із корпоративним резолвером — не проєктування простору імен.

Насамкінець зберігайте перевірену політику разом із джерелом підготовки. Наступне перепідключення або реєстрація мають відновити ту саму службу імен, бо так сказав профіль, а не тому, що хтось згадав правку, зроблену на одній точці доступу два роки тому.