Azure VPN Client на Mac: поместите DNS-серверы в профиль

В macOS на три разных вопроса отвечают одним и тем же пожиманием плечами. Какой это клиент? Откуда берутся его DNS-серверы? И почему после настройки короткое имя всё ещё не работает? Ответы разные, и только первый касается файла профиля. Правильный порядок превращает смутную проблему DNS в один проверяемый шаг за раз.

Убедитесь, какой клиент вы настраиваете

Это Azure VPN Client от Microsoft, использующий OpenVPN для доступа «точка — сайт». Его XML не является родным профилем IKEv2 для macOS и не является файлом конфигурации для любого стороннего клиента OpenVPN.

Если Mac подключается через встроенный системный диалог, вы открыли не тот документ.

DNS живёт внутри XML профиля

Скачайте текущий профиль для нужного шлюза и метода проверки подлинности, а затем сохраните неизменённую копию, прежде чем что-либо трогать. Редактируйте только рабочую копию и не вставляйте её материал проверки подлинности в заявку в поддержку.

Руководство по дополнительным параметрам помещает записи DNS в элемент clientconfig. Минимальный фрагмент выглядит так, с адресом, который ваша организация действительно использует.

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

Этот адрес приведён для примера и не является резолвером, который предоставляет Azure. Встройте записи в существующую конфигурацию, а не вставляйте второй элемент clientconfig, поскольку Microsoft указывает, что дублирующиеся элементы в macOS не поддерживаются. Созданные профили могут также содержать заполнитель nil там, где должна быть настоящая конфигурация, а добавление параметров рядом с элементом nil не является исправлением.

Импорт и есть изменение

Сохранение файла само по себе ничего не меняет. Откройте Azure VPN Client, выберите Import, выберите исправленный XML, заполните нужные поля и сохраните подключение.

Затем переподключитесь через это импортированное подключение. Профиль, лежащий на диске, пока старое подключение остаётся активным, — самая частая причина, по которой правильная правка выглядит бездейственной.

Ограничение суффикса определяет первую проверку

Как задокументировано 30 октября 2026 года, дополнительные значения суффикса DNS в этой конфигурации не сохраняются корректно в macOS. Скопировать пример суффикса из Windows и обещать идентичное поведение — это путь к тому, чтобы работающий резолвер объявили сломанным. Введите суффиксы, сохраните, переподключитесь и проверьте, пережили ли они переподключение. Если нет, планируйте работу с полными именами, а не боритесь с клиентом.

Сначала проверьте с полным частным именем узла. Если FQDN разрешается, а короткое имя нет, вы узнали конкретное: резолвер доступен, а расширение коротких имён отсутствует. Это другой дефект, чем недоступный DNS-сервер, и он требует другого ответственного.

Резолверу всё ещё нужен путь

Перечисление адреса в XML не создаёт службу DNS. На адресе должен работать уполномоченный резолвер, способный отвечать на частное пространство имён или пересылать его, а Mac должен иметь разрешение достучаться до него через туннель. Если этот резолвер стоит за правилом межсетевого экрана, которое не знает диапазон туннеля, запросы истекают без полезной ошибки. Тогда тайм-аут выглядит в точности как неверный адрес, и люди час заново правят XML.

Проверьте активное состояние резолвера на подключённом Mac, затем опросите этот сервер напрямую, чтобы отделить его ответ от выбора резолвера приложением. Прямой запрос доказывает, что сервер работает. Он не доказывает, что обычные запросы выбирают именно его.

Передайте три отдельных результата

Держите их раздельно при передаче: исправленный профиль импортирован, нужный резолвер ответил на запрошенное имя, а приложение достигло возвращённого адреса. У каждого свой ответственный и своё решение.

Одной строки на результат достаточно, и это мешает следующему человеку заново править профиль, который уже был верным.