Mac の Azure VPN Client: DNS サーバーはプロファイルに入れる

macOS では、三つの別の問いが同じ肩すかしで片づけられます。これはどのクライアントか。その DNS サーバーはどこから来るのか。そして設定が入ったあとで、なぜ短い名前はまだ失敗するのか。答えはそれぞれ別で、プロファイルファイルの話は最初の一つだけです。順序を正せば、曖昧な DNS の問題が一度に一つずつ検証できる手順になります。

設定しているクライアントを確かめる

これはポイント対サイト接続に OpenVPN を使う Microsoft の Azure VPN Client です。その XML は macOS ネイティブの IKEv2 プロファイルではなく、サードパーティ製 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 を選択し、必要な項目を埋めて接続を保存します。

そのうえで、インポートした接続でつなぎ直します。古い接続が有効なままプロファイルがディスクに残っていると、正しい編集が何もしていないように見えます。これが最もよくある原因です。

サフィックスの制限が最初のテストを決める

2026 年十月 30 日の文書によれば、この構成で追加の DNS サフィックス値を設定しても macOS では正しく保持されません。Windows のサフィックス例を写して同じ動作を約束すると、動いているリゾルバーが壊れていると報告されることになります。サフィックスを入力し、保存し、再接続して、再接続後も残っているかを確認してください。残らない場合は、クライアントと格闘するのではなく完全修飾名で運用を組み立てます。

まず完全修飾のプライベートホスト名で試します。FQDN は解決できて短い名前は解決できないなら、具体的なことが分かります。リゾルバーには到達できており、短い名前の展開が欠けているのです。これは到達不能な DNS サーバーとは別の不具合で、担当者も別になります。

リゾルバーには経路が要る

XML にアドレスを書いても DNS サービスは生まれません。そのアドレスで、プライベートな名前空間に応答または転送できる正規のリゾルバーが動いている必要があり、Mac はトンネル経由でそこへ到達できることを許可されていなければなりません。そのリゾルバーがトンネルの範囲を知らないファイアウォール規則の内側にあると、問い合わせは有用なエラーもなくタイムアウトします。するとタイムアウトは誤ったアドレスとまったく同じに見え、人は一時間 XML を編集し直します。

接続中の Mac のリゾルバーの状態を確認し、そのサーバーに直接問い合わせて、アプリのリゾルバー選択と切り分けます。直接の問い合わせはサーバーが動いていることを示します。通常の名前解決がそのサーバーを選ぶことは示しません。

三つの結果を分けて引き継ぐ

引き継ぎでは別々に扱ってください。修正したプロファイルをインポートしたこと、目的のリゾルバーが要求した名前に応答したこと、アプリが返されたアドレスに到達したことです。それぞれ担当者も対処も違います。

結果ごとに一行で十分で、次の人がすでに正しいプロファイルを編集し直すのを防げます。