Cliente Azure VPN no Mac: coloque os servidores DNS no perfil

No macOS, três perguntas diferentes recebem o mesmo encolher de ombros. Que cliente é este? De onde vêm os seus servidores DNS? E, depois de a definição estar no lugar, por que um nome curto ainda falha? Têm respostas separadas, e só a primeira diz respeito ao ficheiro do perfil. A ordem certa transforma um problema de DNS vago num passo verificável de cada vez.

Confirme que cliente está a configurar

Este é o cliente Azure VPN da Microsoft, que usa OpenVPN para acesso ponto a site. O seu XML não é um perfil IKEv2 nativo do macOS nem um ficheiro de configuração para qualquer cliente OpenVPN de terceiros.

Se o Mac se liga através da caixa de diálogo integrada do sistema, está no documento errado.

O DNS vive dentro do XML do perfil

Descarregue o perfil atual para o gateway e o método de autenticação pretendidos e guarde uma cópia não modificada antes de tocar em nada. Edite apenas a cópia de trabalho e não cole o seu material de autenticação num pedido de suporte.

O guia de definições opcionais coloca as entradas DNS dentro de um elemento clientconfig. Um fragmento mínimo tem este aspeto, com um endereço que a sua organização realmente executa.

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

Esse endereço é ilustrativo, não um resolvedor fornecido pela Azure. Integre as entradas na configuração existente em vez de colar um segundo elemento clientconfig, porque a Microsoft indica que os elementos duplicados não são suportados no macOS. Os perfis gerados também podem ter um marcador de posição nil onde deveria estar a configuração real, e acrescentar definições ao lado de um elemento nil não é uma reparação.

A importação é a mudança

Guardar o ficheiro não muda nada por si só. Abra o cliente Azure VPN, escolha Import, selecione o XML revisto, preencha os campos necessários e guarde a ligação.

Depois volte a ligar através dessa ligação importada. Um perfil que fica no disco enquanto uma ligação mais antiga permanece ativa é o motivo mais comum para uma edição correta parecer não fazer nada.

A limitação do sufixo decide o primeiro teste

Como documentado a 30 de outubro de 2026, os valores adicionais de sufixo DNS nesta configuração não persistem corretamente no macOS. Copiar um exemplo de sufixo do Windows e prometer um comportamento idêntico é a forma de um resolvedor que funciona ser reportado como avariado. Introduza os sufixos, guarde, volte a ligar e verifique se sobreviveram à reconexão. Se não, planeie com nomes totalmente qualificados em vez de lutar com o cliente.

Teste primeiro com um nome de anfitrião privado totalmente qualificado. Se o FQDN for resolvido e o nome curto não, aprendeu algo concreto: o resolvedor está acessível e falta a expansão do nome curto. Esse é um defeito diferente de um servidor DNS inacessível e precisa de outro responsável.

O resolvedor continua a precisar de um caminho

Listar um endereço no XML não cria um serviço DNS. O endereço tem de executar um resolvedor autorizado que consiga responder ou reencaminhar o espaço de nomes privado, e o Mac tem de ter permissão para o alcançar através do túnel. Se esse resolvedor estiver atrás de uma regra de firewall que não conhece o intervalo do túnel, as consultas expiram sem um erro útil. Então o tempo limite parece exatamente um endereço errado, e as pessoas voltam a editar o XML durante uma hora.

Inspecione o estado ativo do resolvedor do Mac ligado e, em seguida, questione esse servidor diretamente para isolar a sua resposta da escolha de resolvedor da aplicação. Uma consulta direta prova que o servidor funciona. Não prova que as pesquisas normais o escolham.

Entregue três resultados separados

Mantenha-os separados na entrega: o perfil revisto foi importado, o resolvedor previsto respondeu ao nome pedido e a aplicação chegou ao endereço devolvido. Cada um tem outro responsável e outra correção.

Uma linha por resultado chega, e evita que a pessoa seguinte volte a editar um perfil que já estava correto.