WireGuard DNS на iPhone: домен — це лише суфікс пошуку

Ви пишете один рядок з адресою резолвера й доменом компанії, очікуючи, що лише імена в цьому домені використовуватимуть резолвер тунелю. На клієнті Apple тепер усі імена йдуть туди, і короткі імена в домені також розв'язуються. Рядок робить дві окремі речі, і лише одна з них стосується того, які запити обробляє тунель. Інша — це зручність набору, яку бажане прочитання піднесло до політики.

На що розкладається рядок DNS

Клієнт читає запис як список і класифікує кожен елемент за формою. Усе, що виглядає як адреса, стає DNS-сервером; усе, що виглядає як домен, стає суфіксом пошуку. Обидва потрапляють у налаштування тунелю, але в різні поля. Ілюстративний рядок для тунелю з приватним резолвером і одним внутрішнім доменом виглядає так.

DNS = 10.24.8.53, lab.internal.example

Адреса надає резолвер. Домен надає суфікс, який дозволяє клієнтові ввести коротке ім'я, а системі дописати решту перед запитом. Жоден із них нічого не каже про обмеження резолвера цим доменом, і саме цього люди очікують і не отримують. Лише одне поле на платформі може виразити це обмеження, і це не це поле.

Два поля Apple, дві різні задачі

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

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

Тож домен у цьому рядку — не селектор простору імен. Додавання ще одного не звужує запити, які використовує тунель, а видалення не розширює їх. Змінюється лише те, скільки коротких імен доповнюється.

Чому кожне ім'я все одно досягає резолвера тунелю

Із порожнім записом відповідності тунель є кандидатом-резолвером для звичайних імен, а не лише для домену компанії. У конфігурації повного тунелю це зазвичай мало що означає, бо весь трафік і так у тунелі. У розділеному тунелі це дуже важливо. Публічні імена тепер можуть розв'язуватися резолвером, який має лише приватну зону, і збій виглядає як зламаний VPN, хоча насправді це резолвер, що відповідає лише частині простору імен. Тунель у порядку, запити виходять, а відповіді повертаються порожніми.

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

Чого насправді потребував би розділений DNS

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

На керованих пристроях Apple це зазвичай доставляється через профіль конфігурації, що несе DNS-налаштування для конкретного домену. Це інший механізм, ніж файл конфігурації WireGuard, і вони можуть співіснувати, лише якщо клієнт поважає профіль. Перевірте, як ваш клієнт насправді називає це поле, перш ніж припускати, що обидва продукти поводяться однаково. Скрипт wg-quick на Mac і застосунок WireGuard на iPhone читають схожі рядки й встановлюють їх через різні рівні.

Читайте встановлені налаштування, а не конфігурацію

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

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

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