Azure VPN Client på Mac: legg DNS-serverne inn i profilen

På macOS besvares tre forskjellige spørsmål med samme skulderrykk. Hvilken klient er dette? Hvor kommer DNS-serverne dens fra? Og når innstillingen er på plass, hvorfor feiler fortsatt et kort navn? De har hvert sitt svar, og bare det første handler om profilfilen. Riktig rekkefølge gjør et vagt DNS-problem til ett verifiserbart steg om gangen.

Bekreft hvilken klient du konfigurerer

Dette er Microsofts Azure VPN Client, som bruker OpenVPN for punkt-til-område-tilgang. XML-en er ikke en innebygd macOS IKEv2-profil, og heller ikke en konfigurasjonsfil for enhver tredjeparts OpenVPN-klient.

Hvis Macen kobler til via den innebygde systemdialogen, er du i feil dokument.

DNS bor inne i profil-XML-en

Last ned gjeldende profil for den tiltenkte gatewayen og autentiseringsmetoden, og ta vare på en uendret kopi før du rører noe. Rediger bare arbeidskopien, og ikke lim inn autentiseringsmaterialet i en støttebillett.

Veiledningen for valgfrie innstillinger plasserer DNS-oppføringene inne i et clientconfig-element. Et minimalt utdrag ser slik ut, med en adresse organisasjonen din faktisk kjører.

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

Den adressen er illustrativ, ikke en resolver Azure leverer. Integrer oppføringene i den eksisterende konfigurasjonen i stedet for å lime inn et ekstra clientconfig-element, fordi Microsoft opplyser at dupliserte elementer ikke støttes på macOS. Genererte profiler kan også ha en nil-plassholder der den ekte konfigurasjonen hører hjemme, og å legge innstillinger ved siden av et nil-element er ikke en reparasjon.

Importen er endringen

Å lagre filen endrer ingenting i seg selv. Åpne Azure VPN Client, velg Import, velg den reviderte XML-en, fyll ut eventuelle påkrevde felt og lagre tilkoblingen.

Koble deretter til på nytt via den importerte tilkoblingen. En profil som ligger på disken mens en eldre tilkobling forblir aktiv, er den vanligste grunnen til at en korrekt endring ser ut til å gjøre ingenting.

Suffiksbegrensningen avgjør den første testen

Som dokumentert 30. oktober 2026 bevares ikke ekstra DNS-suffiksverdier i denne konfigurasjonen korrekt på macOS. Å kopiere et Windows-suffikseksempel og love identisk oppførsel er måten en fungerende resolver blir rapportert som ødelagt. Skriv inn suffiksene, lagre, koble til på nytt og sjekk om de overlevde gjenoppkoblingen. Hvis ikke, planlegg med fullt kvalifiserte navn i stedet for å kjempe med klienten.

Test først med et fullt kvalifisert privat vertsnavn. Hvis FQDN-en løses opp og det korte navnet ikke, har du lært noe konkret: resolveren er nåbar, og utvidelsen av korte navn mangler. Det er en annen feil enn en utilgjengelig DNS-server, og den trenger en annen eier.

Resolveren trenger fortsatt en vei

Å liste en adresse i XML lager ikke en DNS-tjeneste. Adressen må kjøre en autorisert resolver som kan svare på eller videresende det private navnerommet, og Macen må ha tillatelse til å nå den gjennom tunnelen. Hvis resolveren står bak en brannmurregel som ikke kjenner tunnelområdet, går spørringene ut på tid uten en nyttig feil. Da ser tidsavbruddet nøyaktig ut som en feil adresse, og folk redigerer XML-en på nytt i en time.

Undersøk den aktive resolver-tilstanden til den tilkoblede Macen, og spør deretter serveren direkte for å isolere svaret fra applikasjonens valg av resolver. En direkte spørring beviser at serveren virker. Det beviser ikke at vanlige oppslag velger den.

Overlever tre separate resultater

Hold dem atskilt i overleveringen: den reviderte profilen ble importert, den tiltenkte resolveren svarte på det etterspurte navnet, og applikasjonen nådde adressen som ble returnert. Hver har en annen eier og en annen løsning.

Én linje per resultat er nok, og det hindrer neste person i å redigere en profil som allerede var korrekt.