Cliente Azure VPN no Mac: poña os servidores DNS no perfil

En macOS, tres preguntas diferentes reciben o mesmo encollemento de ombros. Que cliente é este? De onde veñen os seus servidores DNS? E, unha vez aplicado o axuste, por que segue fallando un nome curto? Teñen respostas separadas, e só a primeira trata do ficheiro do perfil. Acertar a orde converte un problema de DNS vago nun paso verificable á vez.

Confirme que cliente está a configurar

Este é o cliente Azure VPN de Microsoft, que usa OpenVPN para o acceso de punto a sitio. O seu XML non é un perfil IKEv2 nativo de macOS nin tampouco un ficheiro de configuración para calquera cliente OpenVPN de terceiros.

Se o Mac se conecta mediante o diálogo integrado do sistema, está no documento equivocado.

O DNS vive dentro do XML do perfil

Descargue o perfil actual para a pasarela e o método de autenticación previstos e garde unha copia sen modificar antes de tocar nada. Edite só a copia de traballo e non pegue o seu material de autenticación nun tícket de soporte.

A guía de axustes opcionais coloca as entradas DNS dentro dun elemento clientconfig. Un fragmento mínimo ten este aspecto, cun enderezo que a súa organización execute de verdade.

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

Ese enderezo é ilustrativo, non un resolutor proporcionado por Azure. Integre as entradas na configuración existente en lugar de pegar un segundo elemento clientconfig, porque Microsoft indica que os elementos duplicados non son compatibles con macOS. Os perfís xerados tamén poden levar un marcador de posición nil onde vai a configuración real, e engadir axustes xunto a un elemento nil non é unha reparación.

A importación é o cambio

Gardar o ficheiro non cambia nada por si só. Abra o cliente Azure VPN, escolla Import, seleccione o XML revisado, complete os campos necesarios e garde a conexión.

Despois volva conectar mediante esa conexión importada. Un perfil no disco mentres unha conexión máis antiga segue activa é o motivo máis habitual de que unha edición correcta pareza non facer nada.

A limitación do sufixo decide a súa primeira proba

Como se documenta o 30 de outubro de 2026, os valores adicionais de sufixo DNS desta configuración non se conservan correctamente en macOS. Copiar un exemplo de sufixo de Windows e prometer un comportamento idéntico é a forma de que un resolutor que funciona se reporte como roto. Introduza os sufixos, garde, volva conectar e comprobe se sobreviviron á reconexión. Se non o fixeron, planifique con nomes totalmente cualificados en lugar de pelexarse co cliente.

Probe primeiro cun nome de host privado totalmente cualificado. Se o FQDN se resolve e o nome curto non, aprendeu algo concreto: o resolutor é accesible e falta a expansión do nome curto. Ese é un defecto distinto dun servidor DNS inaccesible e necesita outro responsable.

O resolutor segue necesitando unha ruta

Listar un enderezo no XML non crea un servizo DNS. O enderezo debe executar un resolutor autorizado que poida responder ou reenviar o espazo de nomes privado, e o Mac debe ter permiso para chegar a el a través do túnel. Se ese resolutor está detrás dunha regra de devasas que non coñece o rango do túnel, as consultas caducan sen un erro útil. Entón o tempo de espera parécese exactamente a un enderezo equivocado, e a xente volve editar o XML durante unha hora.

Inspeccione o estado activo do resolutor do Mac conectado e despois consulte ese servidor directamente para illar a súa resposta da elección de resolutor da aplicación. Unha consulta directa demostra que o servidor funciona. Non demostra que as consultas habituais o seleccionen.

Entregue tres resultados separados

Manteñaos separados no traspaso: o perfil revisado importouse, o resolutor previsto respondeu ao nome solicitado e a aplicación chegou ao enderezo devolto. Cada un ten un responsable e unha solución distintos.

Unha liña por resultado abonda, e evita que a seguinte persoa volva editar un perfil que xa era correcto.