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

DNS клієнта Azure VPN у macOS міститься в імпортованому XML профілю. Відредагуйте, імпортуйте та перепідключіться, потім окремо перевірте шлях резолвера.

У 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, потім запитайте цей сервер напряму, щоб відокремити його відповідь від вибору резолвера програмою. Прямий запит доводить, що сервер працює. Він не доводить, що звичайні запити обирають саме його.

Передайте три окремі результати

Тримайте їх окремо під час передачі: виправлений профіль імпортовано, потрібний резолвер відповів на запитане ім'я, а програма досягла повернутої адреси. Кожен має іншого відповідального та інше рішення.

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

Схожі статті