Кліент Azure VPN на Mac: DNS-серверы ўнутры профілю

На macOS на тры розныя пытанні адказваюць адным пацісканнем плячэй. Які гэта кліент? Адкуль бяруцца яго DNS-серверы? І пасля таго як налада ўжо на месцы, чаму кароткае імя ўсё яшчэ не працуе? У іх асобныя адказы, і толькі першы датычыцца файла профілю. Правільны парадак ператварае неакрэсленую праблему DNS у адзін правяральны крок за раз.

Пацвердзіце, які кліент вы наладжваеце

Гэта кліент Azure VPN ад 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, затым запытайце гэты сервер напрамую, каб аддзяліць яго адказ ад выбару рэзалвера праграмай. Прамы запыт даказвае, што сервер працуе. Ён не даказвае, што звычайныя запыты выбіраюць менавіта яго.

Перадайце тры асобныя вынікі

Трымайце гэта асобна ў перадачы: зменены профіль імпартаваны, патрэбны рэзалвер адказаў на запытанае імя, і праграма дасягнула вернутага адраса. У кожнага розны ўладальнік і розны спосаб выпраўлення.

Аднаго радка на вынік дастаткова, і гэта не дазваляе наступнаму чалавеку зноў рэдагаваць профіль, які ўжо быў правільным.