Azure VPN Client på Mac: læg DNS-serverne ind i profilen

Tre forskellige spørgsmål besvares med samme skuldertræk på macOS. Hvilken klient er det? Hvor kommer dens DNS-servere fra? Og når indstillingen er på plads, hvorfor fejler et kort navn så stadig? De har hver sit svar, og kun det første handler om profilfilen. Den rigtige rækkefølge gør et vagt DNS-problem til ét verificerbart skridt ad gangen.

Bekræft, hvilken klient du konfigurerer

Det er Microsofts Azure VPN Client, som bruger OpenVPN til punkt-til-site-adgang. Dets XML er ikke en native macOS IKEv2-profil og heller ikke en konfigurationsfil til enhver tredjeparts OpenVPN-klient.

Hvis Mac’en forbinder via den indbyggede systemdialog, er du i det forkerte dokument.

DNS ligger inde i profil-XML’en

Download den aktuelle profil til den tilsigtede gateway og godkendelsesmetode, og gem derefter en uændret kopi, før du rører noget. Rediger kun arbejdskopien, og læg ikke dens godkendelsesmateriale i en supportbillet.

Vejledningen til valgfrie indstillinger placerer DNS-posterne inde i et clientconfig-element. Et minimalt uddrag ser sådan ud, med en adresse som din organisation faktisk kører.

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

Adressen er illustrativ og ikke en resolver, Azure stiller til rådighed. Integrer posterne i den eksisterende konfiguration i stedet for at indsætte et ekstra clientconfig-element, fordi Microsoft oplyser, at dublerede elementer ikke understøttes på macOS. Genererede profiler kan også indeholde en nil-pladsholder, hvor den rigtige konfiguration hører hjemme, og at tilføje indstillinger ved siden af et nil-element er ikke en reparation.

Importen er ændringen

At gemme filen ændrer intet i sig selv. Åbn Azure VPN Client, vælg Import, vælg den reviderede XML, udfyld eventuelle påkrævede felter, og gem forbindelsen.

Genopret derefter forbindelsen via den importerede forbindelse. En profil, der ligger på disken, mens en ældre forbindelse forbliver aktiv, er den mest almindelige grund til, at en korrekt rettelse ser ud til at gøre ingenting.

Suffiksbegrænsningen afgør din første test

Som dokumenteret den 30. oktober 2026 bevares yderligere DNS-suffiksværdier i denne konfiguration ikke korrekt på macOS. At kopiere et Windows-suffikseksempel og love identisk adfærd er måden, hvorpå en fungerende resolver bliver rapporteret som brudt. Indtast suffiksene, gem, genopret forbindelsen, og kontroller, om de overlevede genoprettelsen. Hvis ikke, planlæg ud fra fuldt kvalificerede navne i stedet for at kæmpe med klienten.

Test først med et fuldt kvalificeret privat værtsnavn. Hvis FQDN’et opløses, og det korte navn ikke gør, har du lært noget konkret: resolveren kan nås, og udvidelsen af korte navne mangler. Det er en anden fejl end en utilgængelig DNS-server og kræver en anden ejer.

Resolveren har stadig brug for en rute

At liste en adresse i XML skaber ikke en DNS-tjeneste. Adressen skal køre en autoriseret resolver, som kan svare på eller videresende det private navnerum, og Mac’en skal have tilladelse til at nå den gennem tunnelen. Hvis resolveren står bag en firewallregel, der ikke kender tunnelområdet, udløber forespørgslerne uden en brugbar fejl. Så ser timeouten præcis ud som en forkert adresse, og folk redigerer XML’en igen i en time.

Undersøg den tilsluttede Macs aktive resolver-tilstand, og spørg derefter serveren direkte for at isolere dens svar fra programmets valg af resolver. En direkte forespørgsel beviser, at serveren virker. Den beviser ikke, at almindelige opslag vælger den.

Aflever tre separate resultater

Hold dem adskilt i overdragelsen: den reviderede profil blev importeret, den tilsigtede resolver svarede på det ønskede navn, og programmet nåede den returnerede adresse. Hver har en anden ejer og en anden løsning.

Én linje pr. resultat er nok, og det forhindrer den næste person i at redigere en profil, der allerede var korrekt.