Azure VPN Client sous Linux : les domaines DNS n'ont pas pu être définis

Le tunnel monte, puis le client Linux ne peut pas définir les domaines DNS. Vérifiez systemd-resolved, observez l'appel D-Bus et corrigez l'action polkit.

Le tunnel monte, le certificat se valide, puis une boîte de dialogue indique que le serveur DNS ou les domaines n'ont pas pu être définis. Sous Linux, cette boîte ne concerne généralement pas la passerelle : le client remet la configuration des noms à systemd-resolved via D-Bus, et une remise refusée laisse l'interface montée avec une résolution qui pointe encore vers l'ancienne liaison. Le même portable résout correctement les noms avant que le profil n'obtienne un suffixe, et c'est l'indice qu'il vaut la peine de suivre. Rien du tunnel n'a changé à l'instant où la boîte est apparue.

Sans suffixe, le client ne pousse que des serveurs de noms. Ajoutez un domaine de recherche et un second appel s'y joint, SetLinkDomains, avec sa propre vérification d'autorisation, ce qui explique pourquoi le même profil fonctionne sous Windows et échoue ici. La passerelle pousse les mêmes réglages dans les deux cas, et le composant qui les refuse est local.

Confirmez que systemd-resolved est le résolveur en charge

Ce client parle à systemd-resolved et à personne d'autre. Arch et plusieurs autres distributions le livrent désactivé, et /etc/resolv.conf peut appartenir à un tout autre résolveur, donc établissez le propriétaire avant de regarder les permissions.

Trois commandes tranchent la question :

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

Vous cherchez un service actif, un lien symbolique pointant vers /run/systemd/resolve/stub-resolv.conf, et le DNS par liaison dans resolvectl. Quand c'est NetworkManager qui détient la propriété, transférez-la à resolved plutôt que de vous battre avec le client ; le fichier drop-in ci-dessous définit les deux clés :

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

Redémarrez NetworkManager une fois ce fichier présent. Un résolveur inactif associé à un client qui continue d'appeler son nom D-Bus produit une erreur qui ne nomme ni l'un ni l'autre.

Observez l'appel D-Bus qui échoue

Cette étape transforme la boîte en réponse précise. Observez l'interface du résolveur dans un terminal et le journal dans un autre, puis reconnectez-vous :

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

Trois appels devraient apparaître : SetLinkDNS, SetLinkDomains et SetLinkDefaultRoute. Celui qui revient en réponse d'erreur est celui à corriger. Cette réponse indique généralement sa raison, par exemple org.freedesktop.DBus.Error.AccessDenied face à SetLinkDomains. Notez de quel appel il s'agissait, car la section suivante explique comment laisser passer cet appel.

Accordez les actions polkit dont le client a besoin

Lisez la politique avant d'écrire une règle. Un client exécuté comme service ne peut pas répondre à une invite interactive, donc un auth_admin_keep implicite est une impasse.

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

Si la réponse est auth_admin_keep, le client a besoin d'une règle explicite. L'extrait ci-dessous autorise les quatre actions resolve1 qu'un client VPN utilise pendant une connexion et laisse tout le reste à 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;
});

Placez-le dans /etc/polkit-1/rules.d/ comme un fichier que vous reconnaîtrez plus tard, par exemple 50-azurevpn.rules, et remplacez le nom de groupe de l'extrait par le vôtre avant de vous déconnecter et de vous reconnecter. Gardez-le étroit, car autoriser chaque action resolve1 pour chaque compte est plus large que ce dont ce client a besoin et bien plus difficile à auditer ensuite.

Vérifiez le XML du profil avant de modifier polkit

Un profil modifié à la main peut être ignoré sans un mot. Microsoft documente une disposition plate dans laquelle les entrées dnsserver se trouvent directement dans dnsservers, et les suffixes dans dnssuffixes. Un élément d'enveloppe supplémentaire autour de chaque adresse n'est pas cette forme, et le client retombe silencieusement sur ce que pousse la passerelle.

Faites le test de suppression avant de toucher à polkit. Retirez le bloc de suffixe, reconnectez-vous et regardez si la boîte change. Si oui, l'appel qui échouait était la remise du domaine, et le correctif est une autorisation, pas une nouvelle modification XML.

Vérifiez le domaine sur la liaison du tunnel

Reconnectez-vous et relisez resolvectl status, en vérifiant que la liaison du tunnel porte le serveur de noms et le domaine de recherche ensemble. Résolvez un nom privé court plutôt qu'un nom public. Quand le nom se résout mais que le service derrière ne répond pas, la remise DNS a fonctionné et le problème restant est le routage.

Inscrivez dans le ticket le propriétaire du résolveur, l'appel D-Bus qui a échoué, le fichier de règle et la version du profil. Ces quatre lignes font du prochain portable Linux une correction courte plutôt qu'une enquête répétée.

Articles similaires