Azure VPN Client en Linux: no se pudieron establecer los dominios DNS

El túnel se levanta y luego el cliente de Linux no puede establecer los dominios DNS. Comprueba systemd-resolved, observa la llamada D-Bus y corrige la acción de polkit.

El túnel se levanta, el certificado se valida y entonces un diálogo dice que no se pudo establecer el servidor DNS ni los dominios. En Linux ese diálogo normalmente no trata de la puerta de enlace: el cliente entrega la configuración de nombres a systemd-resolved por D-Bus, y una entrega rechazada deja la interfaz levantada con la resolución todavía apuntando al enlace antiguo. El mismo portátil resuelve nombres sin problema antes de que el perfil gane un sufijo, y esa es la pista que vale la pena seguir. Nada del túnel cambió en el momento en que apareció el diálogo.

Sin sufijo el cliente solo empuja servidores de nombres. Añade un dominio de búsqueda y una segunda llamada se suma a él, SetLinkDomains, con su propia comprobación de autorización, por eso el mismo perfil funciona en Windows y falla aquí. La puerta de enlace empuja los mismos ajustes en ambos casos, y el componente que los rechaza es local.

Confirma que systemd-resolved es el resolutor

Este cliente habla con systemd-resolved y con nadie más. Arch y varias otras distribuciones lo sirven desactivado, y /etc/resolv.conf puede pertenecer a un resolutor completamente distinto, así que establece el propietario antes de mirar los permisos.

Tres comandos lo aclaran:

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

Buscas un servicio activo, un enlace simbólico apuntado a /run/systemd/resolve/stub-resolv.conf, y DNS por enlace en resolvectl. Cuando es NetworkManager quien tiene la propiedad, pásala a resolved en lugar de pelearte con el cliente; el archivo drop-in de abajo establece ambas claves:

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

Reinicia NetworkManager en cuanto exista ese archivo. Un resolutor inactivo junto a un cliente que sigue llamando a su nombre D-Bus produce un error que no nombra a ninguno de los dos.

Observa la llamada D-Bus que falla

Este paso convierte el diálogo en una respuesta concreta. Observa la interfaz del resolutor en un terminal y el registro en otro, y luego reconecta:

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

Deberían aparecer tres llamadas: SetLinkDNS, SetLinkDomains y SetLinkDefaultRoute. La que vuelve como respuesta de error es la que hay que corregir. Esa respuesta suele indicar su motivo, por ejemplo org.freedesktop.DBus.Error.AccessDenied frente a SetLinkDomains. Anota cuál fue la llamada, porque la sección siguiente trata de dejar pasar esa llamada.

Concede las acciones de polkit que el cliente necesita

Lee la política antes de escribir una regla. Un cliente que se ejecuta como servicio no puede responder a un aviso interactivo, así que un auth_admin_keep implícito es un callejón sin salida.

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

Si la respuesta es auth_admin_keep, el cliente necesita una regla explícita. El fragmento de abajo permite las cuatro acciones resolve1 que un cliente VPN usa durante una conexión y deja todo lo demás 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ócalo en /etc/polkit-1/rules.d/ como un archivo que reconozcas después, por ejemplo 50-azurevpn.rules, y sustituye el nombre de grupo del fragmento por el tuyo antes de cerrar sesión y volver a entrar. Mantenlo estrecho, porque permitir cada acción resolve1 para cada cuenta es más amplio de lo que este cliente necesita y mucho más difícil de auditar después.

Comprueba el XML del perfil antes de editar polkit

Un perfil editado a mano puede ignorarse sin una palabra. Microsoft documenta una disposición plana en la que las entradas dnsserver se sitúan directamente dentro de dnsservers, y los sufijos dentro de dnssuffixes. Un elemento contenedor extra alrededor de cada dirección no es esa forma, y el cliente vuelve en silencio a lo que empuje la puerta de enlace.

Haz la prueba de eliminación antes de tocar polkit. Quita el bloque del sufijo, reconecta y observa si el diálogo cambia. Si cambia, la llamada que fallaba era la entrega del dominio, y la solución es autorización y no otra edición de XML.

Verifica el dominio en el enlace del túnel

Reconecta y lee resolvectl status otra vez, comprobando que el enlace del túnel lleva el servidor de nombres y el dominio de búsqueda juntos. Resuelve un nombre privado corto en lugar de uno público. Cuando el nombre se resuelve pero el servicio detrás no responde, la entrega DNS funcionó y el problema restante es el enrutamiento.

Escribe en el ticket el propietario del resolutor, la llamada D-Bus que falló, el archivo de regla y la versión del perfil. Esas cuatro líneas convierten el siguiente portátil Linux en una corrección corta en lugar de una investigación repetida.

Artículos relacionados