Azure VPN Client op de Mac: zet de DNS-servers in het profiel

Op macOS krijgen drie verschillende vragen hetzelfde schouderophalen. Welke client is dit? Waar komen de DNS-servers vandaan? En waarom faalt een korte naam nog steeds als de instelling er eenmaal staat? Ze hebben aparte antwoorden, en alleen de eerste gaat over het profielbestand. De juiste volgorde maakt van een vaag DNS-probleem één verifieerbare stap per keer.

Controleer welke client u configureert

Dit is de Azure VPN Client van Microsoft, die OpenVPN gebruikt voor punt-naar-site-toegang. De XML is geen native macOS IKEv2-profiel en ook geen configuratiebestand voor elke OpenVPN-client van derden.

Als de Mac verbindt via de ingebouwde systeemdialoog, zit u in het verkeerde document.

DNS zit in de profiel-XML

Download het actuele profiel voor de bedoelde gateway en verificatiemethode en bewaar een ongewijzigde kopie voordat u iets aanraakt. Bewerk alleen de werkkopie, en plak het verificatiemateriaal niet in een supportticket.

De gids voor optionele instellingen plaatst de DNS-vermeldingen in een clientconfig-element. Een minimaal fragment ziet er zo uit, met een adres dat uw organisatie echt draait.

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

Dat adres is illustratief, geen resolver die Azure levert. Integreer de vermeldingen in de bestaande configuratie in plaats van een tweede clientconfig-element te plakken, omdat Microsoft stelt dat dubbele elementen op macOS niet worden ondersteund. Gegenereerde profielen kunnen ook een nil-plaatsaanduiding hebben waar de echte configuratie hoort, en instellingen naast een nil-element zetten is geen reparatie.

De import is de wijziging

Het bestand opslaan verandert op zichzelf niets. Open Azure VPN Client, kies Import, selecteer de herziene XML, vul vereiste velden in en sla de verbinding op.

Verbind daarna opnieuw via die geïmporteerde verbinding. Een profiel dat op schijf staat terwijl een oudere verbinding actief blijft, is de meest voorkomende reden dat een correcte bewerking niets lijkt te doen.

De suffixbeperking bepaalt uw eerste test

Zoals gedocumenteerd op 30 oktober 2026, blijven extra DNS-suffixwaarden in deze configuratie op macOS niet correct bewaard. Een Windows-suffixvoorbeeld kopiëren en identiek gedrag beloven is de manier waarop een werkende resolver als kapot wordt gemeld. Voer de suffixes in, sla op, verbind opnieuw en controleer of ze de herverbinding hebben overleefd. Zo niet, plan dan met volledig gekwalificeerde namen in plaats van met de client te vechten.

Test eerst met een volledig gekwalificeerde privé-hostnaam. Als de FQDN wel wordt opgelost en de korte naam niet, hebt u iets concreets geleerd: de resolver is bereikbaar en de uitbreiding van korte namen ontbreekt. Dat is een ander defect dan een onbereikbare DNS-server, en het vraagt een andere eigenaar.

De resolver heeft nog steeds een pad nodig

Een adres in de XML vermelden maakt geen DNS-dienst. Op het adres moet een geautoriseerde resolver draaien die de privé-naamruimte kan beantwoorden of doorsturen, en de Mac moet toestemming hebben om die via de tunnel te bereiken. Staat die resolver achter een firewallregel die het tunnelbereik niet kent, dan verlopen query's zonder bruikbare fout. De time-out lijkt dan precies op een verkeerd adres, en mensen bewerken de XML een uur lang opnieuw.

Inspecteer de actieve resolverstatus van de verbonden Mac en vraag die server vervolgens rechtstreeks, om het antwoord los te zien van de resolverkeuze van de applicatie. Een directe query bewijst dat de server werkt. Het bewijst niet dat gewone lookups hem kiezen.

Draag drie aparte resultaten over

Houd ze apart bij de overdracht: het herziene profiel is geïmporteerd, de bedoelde resolver beantwoordde de gevraagde naam en de applicatie bereikte het teruggegeven adres. Elk heeft een andere eigenaar en een andere oplossing.

Eén regel per resultaat volstaat, en het voorkomt dat de volgende persoon een profiel bewerkt dat al correct was.