WireGuard DNS на iPhone: домен — это лишь суффикс поиска
Добавление домена в строку DNS выглядит как разделённый DNS. На клиентах Apple он лишь дополняет короткие имена, и каждый запрос по-прежнему уходит к резолверу туннеля.
Вы пишете одну строку с адресом резолвера и доменом компании, ожидая, что только имена в этом домене будут использовать резолвер туннеля. На клиенте 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-серверы активной службы. Если резолвер туннеля отображается как резолвер по умолчанию без ограничения домена, конфигурация делает ровно то, о чём просил клиент. Исправьте это, изменив механизм, а не добавив второй суффикс и надеясь, что поведение изменится.