Два VPN, один резолвер: побеждает тот, кто записал последним
Оба клиента могут устанавливать политику DNS, и последний записавший может победить. Сопоставьте суффиксы с резолверами и держите путь начальной загрузки вне туннелей.
Подключены два клиента VPN — один для работы, другой для лабораторной сети, — и внутренние имена разрешаются только для того клиента, который подключился последним. Эта картина выглядит как ошибка в одном из клиентов. Обычно это предсказуемый результат двух программ, которые пишут одну и ту же конфигурацию резолвера без соглашения о том, кому принадлежит какое имя.
Миф: самый новый VPN владеет DNS
Нет общего правила, что побеждает самое последнее подключение. Что произойдёт, зависит от механизма платформы и от того, как его записывает каждый клиент. Клиент, заменяющий файл резолвера, даёт один результат; клиент, добавляющий домен для каждого подключения, — другой; клиент, который ничего не делает, оставляет прежнее состояние нетронутым.
Значит, наблюдаемое поведение — свойство двух реализаций, а не документированный приоритет. Рассуждения только по порядку запуска иногда будут верны, а иногда ошибочны так, что это трудно воспроизвести. Запишите сопоставление вместо этого. Дизайн, живущий в двух клиентах, — не дизайн.
Сопоставьте пространства имён с резолверами
Перечислите частные суффиксы и резолвер, который требует каждая сеть, затем решите, куда должны идти публичные имена. Этот список и есть дизайн. Без него клиенты принимают решение случайно.
Платформа, поддерживающая DNS для каждого подключения или домены маршрутизации, может выразить разделение намеренно: один домен идёт к одному подключению, другой — к другому, а всё остальное следует явному значению по умолчанию. Два плоских скрипта, перезаписывающих один файл, не могут сохранить этот дизайн, потому что каждый считает, что владеет всей конфигурацией.
В Windows таблица политики разрешения имён может направлять суффиксы к определённым серверам, и клиент VPN может устанавливать там правила. Проверяйте политику, а не список адаптеров, потому что имя разрешает не список адаптеров.
Держите путь начальной загрузки
Каждый клиент должен найти свою конечную точку, прежде чем сможет пользоваться услугой, которую эта точка предоставляет. Если имя хоста конечной точки разрешается только через туннель, а туннелю нужно разрешённое имя хоста, у вас циклическая зависимость, проявляющаяся как тайм-аут подключения. Держите один путь начальной загрузки вне обоих туннелей. Он ничего не стоит до того дня, когда спасает подключение.
Смотрите на путь к каждому резолверу, а не только на имя, заданное для него. Резолвер, доступный только через другой туннель, ведёт себя как отсутствующий, и симптом — тайм-аут, а не ошибка маршрутизации.
Перекрывающиеся адреса — не проблема DNS
Две частные сети с одинаковым диапазоном адресов нельзя исправить порядком DNS. Если оба туннеля претендуют на 10.0.0.0/8, имя, разрешаемое правильно, всё равно указывает на адрес, к которому хост не может направить правильный туннель. Это требует решения на уровне адресов, например разных диапазонов, пространства имён или трансляции, а не ещё одной настройки резолвера. Раннее решение избавляет от долгого обхода через конфигурацию DNS, которая никогда бы не работала.
Сравните назначения адресов обоих туннелей, прежде чем винить разрешение имён. Когда обе стороны продвигают один и тот же префикс, хост держит для него один маршрут, и имя, разрешённое через второй туннель, всё равно попадает на адрес, которым владеет первый туннель. Разные диапазоны, пространство имён для каждой сети или трансляция — это исправления; после подключения каждого клиента убедитесь, что таблица маршрутов показывает нужный путь.
Докажите это реальными приложениями
Выберите два хоста, существующих только в своём пространстве имён, и одно публичное имя, затем разрешите каждый через клиент, которому он должен принадлежать. Правильный ответ от ожидаемого резолвера не доказывает, что приложение доходит до хоста, потому что маршрут к этому адресу всё ещё может не работать. После каждого запроса выполняйте проверку соединения из программы, которую пользователь действительно запустит.
Клиент с собственной опцией зашифрованного DNS может обойти только что проверенную политику, поэтому проверьте эту настройку в рамках обзора. Затем переподключите оба клиента в порядке, поддерживаемом поставщиком, и повторите запросы; если ответы меняются местами при смене порядка, конкурирующий записывающий всё ещё владеет частью конфигурации. Выясните, какой компонент устанавливает правило — клиент, профиль ОС или агент управления, — прежде чем что-либо редактировать. Запишите порядок и владельцев, чтобы следующему человеку не пришлось открывать их заново.