Azure VPN Client su Linux: impossibile impostare i domini DNS

Il tunnel si alza e poi il client Linux non riesce a impostare i domini DNS. Controlla systemd-resolved, osserva la chiamata D-Bus e correggi l'azione polkit.

Il tunnel si alza, il certificato viene convalidato e poi una finestra dice che non è stato possibile impostare il server DNS o i domini. Su Linux quella finestra di solito non riguarda il gateway: il client consegna la configurazione dei nomi a systemd-resolved via D-Bus, e una consegna rifiutata lascia l'interfaccia attiva con la risoluzione ancora puntata al vecchio collegamento. Lo stesso portatile risolve i nomi correttamente prima che il profilo ottenga un suffisso, ed è l'indizio che vale la pena seguire. Nulla del tunnel è cambiato nel momento in cui è apparsa la finestra.

Senza suffisso il client spinge solo server di nomi. Aggiungi un dominio di ricerca e una seconda chiamata vi si unisce, SetLinkDomains, con la propria verifica di autorizzazione, per questo lo stesso profilo funziona su Windows e fallisce qui. Il gateway spinge le stesse impostazioni in entrambi i casi, e il componente che le rifiuta è locale.

Conferma che systemd-resolved è il resolver

Questo client parla con systemd-resolved e con nessun altro. Arch e diverse altre distribuzioni lo forniscono disattivato, e /etc/resolv.conf può appartenere a un resolver del tutto diverso, quindi stabilisci il proprietario prima di guardare i permessi.

Tre comandi lo chiariscono:

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

Cerchi un servizio attivo, un collegamento simbolico puntato a /run/systemd/resolve/stub-resolv.conf, e il DNS per collegamento in resolvectl. Quando è NetworkManager a detenere la proprietà, passala a resolved invece di combattere con il client; il file drop-in qui sotto imposta entrambe le chiavi:

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

Riavvia NetworkManager appena quel file esiste. Un resolver inattivo insieme a un client che continua a chiamare il suo nome D-Bus produce un errore che non nomina nessuno dei due.

Osserva la chiamata D-Bus che fallisce

Questo passaggio trasforma la finestra in una risposta precisa. Osserva l'interfaccia del resolver in un terminale e il journal in un altro, poi riconnettiti:

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

Dovrebbero apparire tre chiamate: SetLinkDNS, SetLinkDomains e SetLinkDefaultRoute. Quella che torna come risposta di errore è quella da correggere. Quella risposta di solito ne indica il motivo, per esempio org.freedesktop.DBus.Error.AccessDenied contro SetLinkDomains. Annota quale chiamata era, perché la sezione successiva spiega come lasciar passare proprio quella chiamata.

Concedi le azioni polkit che servono al client

Leggi la policy prima di scrivere una regola. Un client che gira come servizio non può rispondere a un prompt interattivo, quindi un auth_admin_keep implicito è un vicolo cieco.

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

Se la risposta è auth_admin_keep, il client ha bisogno di una regola esplicita. Il frammento qui sotto consente le quattro azioni resolve1 che un client VPN usa durante una connessione e lascia tutto il resto a 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;
});

Mettilo in /etc/polkit-1/rules.d/ come un file che riconoscerai più avanti, per esempio 50-azurevpn.rules, e sostituisci il nome del gruppo nel frammento con il tuo prima di disconnetterti e riconnetterti. Tienilo stretto, perché consentire ogni azione resolve1 per ogni account è più ampio di quanto serva a questo client e molto più difficile da verificare dopo.

Controlla l'XML del profilo prima di modificare polkit

Un profilo modificato a mano può essere ignorato senza una parola. Microsoft documenta una disposizione piatta in cui le voci dnsserver stanno direttamente dentro dnsservers, e i suffissi dentro dnssuffixes. Un elemento di involucro extra attorno a ogni indirizzo non è quella forma, e il client ricade in silenzio su ciò che spinge il gateway.

Esegui il test di rimozione prima di toccare polkit. Togli il blocco del suffisso, riconnettiti e guarda se la finestra cambia. Se cambia, la chiamata che falliva era la consegna del dominio, e la correzione è l'autorizzazione, non un'altra modifica XML.

Verifica il dominio sul collegamento del tunnel

Riconnettiti e rileggi resolvectl status, controllando che il collegamento del tunnel porti insieme il server di nomi e il dominio di ricerca. Risolvi un nome privato breve invece di uno pubblico. Quando il nome si risolve ma il servizio dietro non risponde, la consegna DNS ha funzionato e il problema rimasto è l'instradamento.

Scrivi nel ticket il proprietario del resolver, la chiamata D-Bus fallita, il file di regola e la versione del profilo. Quelle quattro righe trasformano il prossimo portatile Linux in una correzione breve invece che in un'indagine ripetuta.

Articoli correlati