Azure VPN Client på Mac: lägg DNS-servrarna i profilen

DNS för Azure VPN Client på macOS finns i den importerade profilens XML. Redigera, importera och återanslut, och testa sedan resolvervägen separat.

På macOS besvaras tre olika frågor med samma axelryckning. Vilken klient är det här? Varifrån kommer dess DNS-servrar? Och när inställningen väl är på plats, varför misslyckas ett kort namn fortfarande? De har separata svar, och bara det första handlar om profilfilen. Rätt ordning gör ett vagt DNS-problem till ett verifierbart steg i taget.

Bekräfta vilken klient du konfigurerar

Det här är Microsofts Azure VPN Client som använder OpenVPN för punkt-till-plats-åtkomst. Dess XML är inte en inbyggd macOS IKEv2-profil och inte heller en konfigurationsfil för varje tredjeparts OpenVPN-klient.

Om Macen ansluter via den inbyggda systemdialogen är du i fel dokument.

DNS bor inne i profilens XML

Ladda ned den aktuella profilen för den avsedda gatewayen och autentiseringsmetoden och spara en oförändrad kopia innan du rör något. Redigera bara arbetskopian, och klistra inte in dess autentiseringsmaterial i ett supportärende.

Guiden för valfria inställningar placerar DNS-posterna i ett clientconfig-element. Ett minimalt utdrag ser ut så här, med en adress som din organisation faktiskt kör.

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

Den adressen är illustrativ, inte en resolver som Azure tillhandahåller. Integrera posterna i den befintliga konfigurationen i stället för att klistra in ett extra clientconfig-element, eftersom Microsoft anger att dubblerade element inte stöds på macOS. Genererade profiler kan också ha en nil-platshållare där den riktiga konfigurationen hör hemma, och att lägga inställningar bredvid ett nil-element är ingen reparation.

Importen är ändringen

Att spara filen ändrar ingenting i sig. Öppna Azure VPN Client, välj Import, välj den reviderade XML-filen, fyll i eventuella obligatoriska fält och spara anslutningen.

Återanslut sedan via den importerade anslutningen. En profil som ligger på disken medan en äldre anslutning är kvar aktiv är den vanligaste orsaken till att en korrekt ändring verkar göra ingenting.

Suffixbegränsningen avgör ditt första test

Som dokumenterat den 30 oktober 2026 bevaras inte ytterligare DNS-suffixvärden i den här konfigurationen korrekt på macOS. Att kopiera ett Windows-suffixexempel och lova identiskt beteende är hur en fungerande resolver rapporteras som trasig. Ange suffixen, spara, återanslut och kontrollera om de överlevde återanslutningen. Om inte, planera med fullt kvalificerade namn i stället för att kämpa med klienten.

Testa först med ett fullt kvalificerat privat värdnamn. Om FQDN löses upp men det korta namnet inte, har du lärt dig något konkret: resolvern är nåbar och utökningen av korta namn saknas. Det är en annan defekt än en onåbar DNS-server, och den kräver en annan ägare.

Resolvern behöver fortfarande en väg

Att lista en adress i XML skapar ingen DNS-tjänst. Adressen måste köra en auktoriserad resolver som kan svara på eller vidarebefordra det privata namnutrymmet, och Macen måste tillåtas nå den genom tunneln. Om resolvern står bakom en brandväggsregel som inte känner till tunnelns intervall går frågorna ut i timeout utan ett användbart fel. Då ser timeouten exakt ut som en felaktig adress, och folk redigerar XML-filen igen i en timme.

Inspektera den anslutna Macens aktiva resolverläge och fråga sedan den servern direkt för att isolera dess svar från programmets val av resolver. En direkt fråga bevisar att servern fungerar. Det bevisar inte att vanliga sökningar väljer den.

Lämna över tre separata resultat

Håll dem åtskilda i överlämningen: den reviderade profilen importerades, den avsedda resolvern svarade på det efterfrågade namnet och programmet nådde den returnerade adressen. Var och en har en annan ägare och en annan åtgärd.

En rad per resultat räcker, och det hindrar nästa person från att redigera en profil som redan var korrekt.

Relaterade artiklar