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

På macOS blir tre ulike spørsmål svara med same skulderklapping. Kva klient er dette? Kvar kjem DNS-tenarane hans frå? Og når innstillinga er på plass, kvifor feilar framleis eit kort namn? Dei har kvar sitt svar, og berre det første handlar om profilfila. Rett rekkjefølgje gjer eit vagt DNS-problem til eitt stadfesta steg om gongen.

Stadfest kva klient du set opp

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

Viss Macen koplar til via den innebygde systemdialogen, er du i feil dokument.

DNS bur inne i profil-XML-en

Last ned gjeldande profil for den tiltenkte gatewayen og autentiseringsmetoden, og ta vare på ei uendra kopi før du rører noko. Rediger berre arbeidskopien, og lim ikkje inn autentiseringsmaterialet i ein støttebillett.

Retningslinja for valfrie innstillingar plasserer DNS-oppføringane inne i eit clientconfig-element. Eit minimalt utdrag ser slik ut, med ei adresse organisasjonen din faktisk køyrer.

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

Den adressa er illustrativ, ikkje ein resolver Azure leverer. Integrer oppføringane i den eksisterande konfigurasjonen i staden for å lime inn eit ekstra clientconfig-element, fordi Microsoft opplyser at dupliserte element ikkje er støtta på macOS. Genererte profilar kan også ha ein nil-plasshaldar der den ekte konfigurasjonen høyrer heime, og å leggje innstillingar ved sida av eit nil-element er inga reparasjon.

Importen er endringa

Å lagre fila endrar ingenting i seg sjølv. Opne Azure VPN Client, vel Import, vel den reviderte XML-en, fyll ut eventuelle påkravde felt og lagre tilkoplinga.

Kople deretter til på nytt via den importerte tilkoplinga. Ein profil som ligg på disken medan ei eldre tilkopling blir verande aktiv, er den vanlegaste grunnen til at ei korrekt endring ser ut til å gjere ingenting.

Suffiksgrensa avgjer den første testen

Som dokumentert 30. oktober 2026 blir ikkje ekstra DNS-suffiksverdiar i denne konfigurasjonen tekne vare på rett på macOS. Å kopiere eit Windows-suffiksdøme og love identisk åtferd er måten ein fungerande resolver blir meld som øydelagd. Skriv inn suffiksa, lagre, kople til på nytt og sjekk om dei overlevde attkoplinga. Viss ikkje, planlegg med fullt kvalifiserte namn i staden for å kjempe med klienten.

Test først med eit fullt kvalifisert privat vertsnamn. Viss FQDN-en blir løyst opp og det korte namnet ikkje, har du lært noko konkret: resolveren er nåbar, og utvidinga av korte namn manglar. Det er ein annan feil enn ein utilgjengeleg DNS-tenar, og han treng ein annan eigar.

Resolveren treng framleis ein veg

Å liste ei adresse i XML lagar ikkje ein DNS-teneste. Adressa må køyre ein autorisert resolver som kan svare på eller videresende det private namnerommet, og Macen må ha løyve til å nå han gjennom tunnelen. Viss resolveren står bak ei brannmurregel som ikkje kjenner tunellområdet, går spørjingane ut på tid utan ein nyttig feil. Då ser tidsavbrotet nøyaktig ut som ei feil adresse, og folk redigerer XML-en på nytt i ein time.

Undersøk den aktive resolver-tilstanden til den tilkopla Macen, og spør deretter tenaren direkte for å isolere svaret frå valet av resolver i programmet. Ei direkte spørjing bevisar at tenaren verkar. Det bevisar ikkje at vanlege oppslag vel han.

Overlever tre separate resultat

Hald dei frå kvarandre i overleveringa: den reviderte profilen vart importert, den tiltenkte resolveren svara på det etterspurde namnet, og programmet nådde adressa som vart returnert. Kvar har ein annan eigar og ei anna løysing.

Éi line per resultat er nok, og det hindrar neste person i å redigere ein profil som allereie var korrekt.