Azure VPN Client di Mac: taruh server DNS di dalam profil

Di macOS, tiga pertanyaan berbeda dijawab dengan angkat bahu yang sama. Klien mana ini? Dari mana server DNS-nya berasal? Dan setelah pengaturannya ada, mengapa nama pendek masih gagal? Ketiganya punya jawaban terpisah, dan hanya yang pertama soal berkas profil. Urutan yang benar mengubah masalah DNS yang kabur menjadi satu langkah yang bisa diverifikasi setiap kali.

Pastikan klien mana yang Anda konfigurasi

Ini adalah Azure VPN Client dari Microsoft yang memakai OpenVPN untuk akses titik ke situs. XML-nya bukan profil IKEv2 asli macOS, dan juga bukan berkas konfigurasi untuk setiap klien OpenVPN pihak ketiga.

Jika Mac terhubung lewat dialog sistem bawaan, Anda ada di dokumen yang salah.

DNS berada di dalam XML profil

Unduh profil terbaru untuk gateway dan metode autentikasi yang dituju, lalu simpan salinan yang belum diubah sebelum menyentuh apa pun. Sunting hanya salinan kerjanya, dan jangan tempel materi autentikasinya ke tiket dukungan.

Panduan pengaturan opsional menaruh entri DNS di dalam elemen clientconfig. Fragmen minimalnya seperti ini, dengan alamat yang benar-benar dijalankan organisasi Anda.

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

Alamat itu hanya ilustrasi, bukan resolver yang disediakan Azure. Integrasikan entri ke konfigurasi yang ada alih-alih menempel elemen clientconfig kedua, karena Microsoft menyatakan elemen duplikat tidak didukung di macOS. Profil yang dihasilkan juga bisa membawa placeholder nil di tempat konfigurasi sebenarnya, dan menambahkan pengaturan di samping elemen nil bukanlah perbaikan.

Impor adalah perubahannya

Menyimpan berkas tidak mengubah apa pun dengan sendirinya. Buka Azure VPN Client, pilih Import, pilih XML yang sudah direvisi, lengkapi kolom yang diperlukan, dan simpan koneksinya.

Lalu sambungkan ulang lewat koneksi yang diimpor itu. Profil yang menganggur di disk sementara koneksi lama tetap aktif adalah penyebab paling umum suntingan yang benar tampak tidak melakukan apa pun.

Batasan sufiks menentukan uji pertama Anda

Seperti didokumentasikan pada 30 Oktober 2026, nilai sufiks DNS tambahan dalam konfigurasi ini tidak bertahan dengan benar di macOS. Menyalin contoh sufiks dari Windows lalu menjanjikan perilaku yang sama adalah cara sebuah resolver yang bekerja dilaporkan sebagai rusak. Masukkan sufiksnya, simpan, sambungkan ulang, dan periksa apakah bertahan setelah penyambungan ulang. Jika tidak, rencanakan dengan nama yang sepenuhnya memenuhi syarat alih-alih berkelahi dengan klien.

Uji dulu dengan nama host privat yang sepenuhnya memenuhi syarat. Jika FQDN berhasil diresolusi dan nama pendek tidak, Anda belajar sesuatu yang spesifik: resolver dapat dijangkau dan perluasan nama pendek tidak ada. Itu cacat yang berbeda dari server DNS yang tak terjangkau, dan butuh pemilik yang berbeda.

Resolver tetap butuh jalur

Mencantumkan alamat di XML tidak membuat layanan DNS. Alamat itu harus menjalankan resolver resmi yang bisa menjawab atau meneruskan ruang nama privat, dan Mac harus diizinkan menjangkaunya lewat terowongan. Jika resolver itu berada di balik aturan firewall yang tidak mengenal rentang terowongan, kueri habis waktu tanpa galat yang berguna. Saat itu batas waktu tampak persis seperti alamat yang salah, dan orang menyunting XML lagi selama satu jam.

Periksa keadaan resolver aktif Mac yang terhubung, lalu tanyakan server itu secara langsung untuk memisahkan jawabannya dari pilihan resolver aplikasi. Kueri langsung membuktikan servernya bekerja. Itu tidak membuktikan pencarian biasa memilihnya.

Serahkan tiga hasil terpisah

Pisahkan ketiganya dalam serah terima: profil revisi sudah diimpor, resolver yang dituju menjawab nama yang diminta, dan aplikasi mencapai alamat yang dikembalikan. Masing-masing punya pemilik dan perbaikan berbeda.

Satu baris per hasil sudah cukup, dan itu mencegah orang berikutnya menyunting ulang profil yang sudah benar.