Azure VPN Client no Linux: não foi possível definir os domínios DNS

O túnel sobe e então o cliente Linux não consegue definir os domínios DNS. Verifique o systemd-resolved, observe a chamada D-Bus e corrija a ação do polkit.

O túnel sobe, o certificado é validado e então uma caixa de diálogo diz que o servidor DNS ou os domínios não puderam ser definidos. No Linux essa caixa normalmente não é sobre o gateway: o cliente entrega a configuração de nomes ao systemd-resolved via D-Bus, e uma entrega recusada deixa a interface no ar com a resolução ainda apontando para o link antigo. O mesmo portátil resolve nomes muito bem antes de o perfil ganhar um sufixo, e essa é a pista que vale a pena seguir. Nada do túnel mudou no momento em que a caixa apareceu.

Sem sufixo o cliente só empurra servidores de nomes. Adicione um domínio de busca e uma segunda chamada se junta a ele, SetLinkDomains, com sua própria verificação de autorização, por isso o mesmo perfil funciona no Windows e falha aqui. O gateway empurra as mesmas configurações nos dois casos, e o componente que as recusa é local.

Confirme que o systemd-resolved é o resolvedor

Este cliente fala com o systemd-resolved e com mais ninguém. Arch e várias outras distribuições o entregam desativado, e /etc/resolv.conf pode pertencer a um resolvedor completamente diferente, então estabeleça o dono antes de olhar as permissões.

Três comandos esclarecem isso:

systemctl status systemd-resolved
ls -l /etc/resolv.conf
resolvectl status

Você procura um serviço ativo, um link simbólico apontado para /run/systemd/resolve/stub-resolv.conf, e DNS por link em resolvectl. Quando é o NetworkManager que detém a propriedade, passe-a para o resolved em vez de brigar com o cliente; o arquivo drop-in abaixo define as duas chaves:

[main]
dns=systemd-resolved
systemd-resolved=true

Reinicie o NetworkManager assim que esse arquivo existir. Um resolvedor inativo junto a um cliente que continua chamando seu nome D-Bus produz um erro que não nomeia nenhum dos dois.

Observe a chamada D-Bus que falha

Este passo transforma a caixa numa resposta concreta. Observe a interface do resolvedor num terminal e o journal noutro, e depois reconecte:

sudo dbus-monitor --system "interface='org.freedesktop.resolve1.Manager'"
journalctl -fu systemd-resolved

Três chamadas devem aparecer: SetLinkDNS, SetLinkDomains e SetLinkDefaultRoute. A que volta como resposta de erro é a que precisa ser corrigida. Essa resposta costuma indicar o motivo, por exemplo org.freedesktop.DBus.Error.AccessDenied contra SetLinkDomains. Anote qual foi a chamada, porque a próxima seção trata de deixar passar exatamente essa chamada.

Conceda as ações do polkit de que o cliente precisa

Leia a política antes de escrever uma regra. Um cliente que roda como serviço não consegue responder a um prompt interativo, então um auth_admin_keep implícito é um beco sem saída.

pkaction --verbose --action-id org.freedesktop.resolve1.set-domains
pkaction --action-id org.freedesktop.resolve1.set-dns-servers --verbose

Se a resposta for auth_admin_keep, o cliente precisa de uma regra explícita. O trecho abaixo permite as quatro ações resolve1 que um cliente VPN usa durante uma conexão e deixa todo o resto em polkit.Result.NOT_HANDLED:

polkit.addRule(function(action, subject) {
  var allowed = [
    "org.freedesktop.resolve1.set-dns-servers",
    "org.freedesktop.resolve1.set-domains",
    "org.freedesktop.resolve1.set-default-route",
    "org.freedesktop.resolve1.revert"
  ];
  if (allowed.indexOf(action.id) !== -1 &&
      subject.isInGroup("wheel")) {
    return polkit.Result.YES;
  }
  return polkit.Result.NOT_HANDLED;
});

Coloque-o em /etc/polkit-1/rules.d/ como um arquivo que você reconhecerá depois, por exemplo 50-azurevpn.rules, e substitua o nome do grupo no trecho pelo seu antes de sair e entrar de novo. Mantenha-o estreito, porque permitir cada ação resolve1 para cada conta é mais amplo do que este cliente precisa e muito mais difícil de auditar depois.

Verifique o XML do perfil antes de editar o polkit

Um perfil editado à mão pode ser ignorado sem uma palavra. A Microsoft documenta um layout plano em que as entradas dnsserver ficam diretamente dentro de dnsservers, e os sufixos dentro de dnssuffixes. Um elemento de envelope extra em volta de cada endereço não é esse formato, e o cliente volta em silêncio ao que o gateway empurra.

Faça o teste de remoção antes de mexer no polkit. Tire o bloco do sufixo, reconecte e veja se a caixa muda. Se mudar, a chamada que falhava era a entrega do domínio, e a correção é autorização, não outra edição de XML.

Verifique o domínio no link do túnel

Reconecte e leia resolvectl status de novo, conferindo que o link do túnel carrega o servidor de nomes e o domínio de busca juntos. Resolva um nome privado curto em vez de um público. Quando o nome resolve mas o serviço por trás não responde, a entrega DNS funcionou e o problema restante é o roteamento.

Escreva no ticket o dono do resolvedor, a chamada D-Bus que falhou, o arquivo de regra e a versão do perfil. Essas quatro linhas transformam o próximo portátil Linux numa correção curta em vez de uma investigação repetida.

Artigos relacionados