Azure VPN Client en Linux: non se puideron establecer os dominios DNS

O túnel levanta e logo o cliente de Linux non pode establecer os dominios DNS. Comproba systemd-resolved, observa a chamada D-Bus e corrixe a acción de polkit.

O túnel levanta, o certificado valídase e entón un diálogo di que non se puido establecer o servidor DNS nin os dominios. En Linux ese diálogo normalmente non trata da pasarela: o cliente entrega a configuración de nomes a systemd-resolved por D-Bus, e unha entrega rexeitada deixa a interface levantada con a resolución aínda apuntando á ligazón antiga. O mesmo portátil resolve nomes sen problema antes de que o perfil gañe un sufixo, e esa é a pista que paga a pena seguir. Nada do túnel cambiou no momento en que apareceu o diálogo.

Sen sufixo o cliente só empurra servidores de nomes. Engade un dominio de busca e unha segunda chamada únese a el, SetLinkDomains, coa súa propia comprobación de autorización, por iso o mesmo perfil funciona en Windows e falla aquí. A pasarela empurra os mesmos axustes en ambos os casos, e o compoñente que os rexeita é local.

Confirma que systemd-resolved é o resolutor

Este cliente fala con systemd-resolved e con ninguén máis. Arch e varias outras distribucións sérveno desactivado, e /etc/resolv.conf pode pertencer a un resolutor completamente distinto, así que establece o propietario antes de mirar os permisos.

Tres comandos aclárano:

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

Buscas un servizo activo, unha ligazón simbólica dirixida a /run/systemd/resolve/stub-resolv.conf, e DNS por ligazón en resolvectl. Cando é NetworkManager quen ten a propiedade, pásaa a resolved en vez de pelexar co cliente; o ficheiro drop-in de abaixo establece as dúas claves:

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

Reinicia NetworkManager unha vez que exista ese ficheiro. Un resolutor inactivo xunto a un cliente que segue chamando polo seu nome D-Bus produce un erro que non nomea ningún dos dous.

Observa a chamada D-Bus que falla

Este paso converte o diálogo nunha resposta concreta. Observa a interface do resolutor nun terminal e o rexistro noutro, e despois reconecta:

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

Deberían aparecer tres chamadas: SetLinkDNS, SetLinkDomains e SetLinkDefaultRoute. A que volve como resposta de erro é a que hai que corrixir. Esa resposta adoita indicar o motivo, por exemplo org.freedesktop.DBus.Error.AccessDenied fronte a SetLinkDomains. Anota cal foi a chamada, porque a sección seguinte trata de deixar pasar esa chamada.

Concede as accións de polkit que o cliente necesita

Le a política antes de escribir unha regra. Un cliente que se executa como servizo non pode responder a unha solicitude interactiva, así que un auth_admin_keep implícito é un camiño sen saída.

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

Se a resposta é auth_admin_keep, o cliente necesita unha regra explícita. O fragmento de abaixo permite as catro accións resolve1 que un cliente VPN usa durante unha conexión e deixa todo o demais en 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;
});

Colócao en /etc/polkit-1/rules.d/ como un ficheiro que recoñecerás despois, por exemplo 50-azurevpn.rules, e substitúe o nome de grupo do fragmento polo teu antes de pechar a sesión e volver entrar. Mantelo estreito, porque permitir cada acción resolve1 para cada conta é máis amplo do que este cliente necesita e moito máis difícil de auditar despois.

Comproba o XML do perfil antes de editar polkit

Un perfil editado a man pode ignorarse sen unha palabra. Microsoft documenta unha disposición plana na que as entradas dnsserver están directamente dentro de dnsservers, e os sufixos dentro de dnssuffixes. Un elemento envoltorio extra arredor de cada enderezo non é esa forma, e o cliente cae en silencio no que empurre a pasarela.

Fai a proba de eliminación antes de tocar polkit. Quita o bloque do sufixo, reconecta e mira se o diálogo cambia. Se cambia, a chamada que fallaba era a entrega do dominio, e a solución é autorización e non outra edición de XML.

Verifica o dominio na ligazón do túnel

Reconecta e le resolvectl status outra vez, comprobando que a ligazón do túnel leva o servidor de nomes e o dominio de busca xuntos. Resolve un nome privado curto en vez dun público. Cando o nome se resolve pero o servizo detrás non responde, a entrega DNS funcionou e o problema restante é o encamiñamento.

Escribe no tícket o propietario do resolutor, a chamada D-Bus que fallou, o ficheiro de regra e a versión do perfil. Esas catro liñas converten o seguinte portátil Linux nunha corrección curta en lugar dunha investigación repetida.

Artigos relacionados