Azure VPN Client unter Linux: DNS-Domänen konnten nicht gesetzt werden

Der Tunnel kommt hoch, das Zertifikat wird validiert, und dann meldet ein Dialog, dass der DNS-Server oder die Domänen nicht gesetzt werden konnten. Unter Linux geht es in diesem Dialog meist nicht um das Gateway: Der Client übergibt die Namenskonfiguration über D-Bus an systemd-resolved, und eine abgelehnte Übergabe lässt die Schnittstelle oben, während die Namensauflösung weiterhin auf die alte Verbindung zeigt. Derselbe Laptop löst Namen problemlos auf, bevor das Profil ein Suffix erhält, und das ist der Hinweis, dem es sich zu folgen lohnt. Am Tunnel änderte sich in dem Moment, in dem der Dialog erschien, nichts.

Ohne Suffix schiebt der Client nur Namensserver. Fügen Sie eine Suchdomäne hinzu, und ein zweiter Aufruf gesellt sich dazu, SetLinkDomains, mit einer eigenen Autorisierungsprüfung, weshalb dasselbe Profil unter Windows funktioniert und hier scheitert. Das Gateway schiebt in beiden Fällen dieselben Einstellungen, und die Komponente, die sie ablehnt, ist lokal.

Bestätigen Sie, dass systemd-resolved der zuständige Resolver ist

Dieser Client spricht mit systemd-resolved und mit niemandem sonst. Arch und mehrere andere Distributionen liefern ihn deaktiviert aus, und /etc/resolv.conf kann vollständig zu einem anderen Resolver gehören, also klären Sie den Eigentümer, bevor Sie auf Berechtigungen schauen.

Drei Befehle klären das:

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

Sie suchen einen aktiven Dienst, einen symbolischen Link auf /run/systemd/resolve/stub-resolv.conf, und DNS pro Verbindung in resolvectl. Wenn stattdessen NetworkManager die Eigentümerschaft hält, übergeben Sie sie an resolved, statt mit dem Client zu kämpfen; die Drop-in-Datei unten setzt beide Schlüssel:

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

Starten Sie NetworkManager neu, sobald diese Datei existiert. Ein inaktiver Resolver zusammen mit einem Client, der weiterhin seinen D-Bus-Namen aufruft, erzeugt einen Fehler, der keinen von beiden benennt.

Beobachten Sie den D-Bus-Aufruf, der scheitert

Dieser Schritt verwandelt den Dialog in eine konkrete Antwort. Beobachten Sie die Resolver-Schnittstelle in einem Terminal und das Journal in einem anderen, und verbinden Sie sich dann neu:

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

Drei Aufrufe sollten erscheinen: SetLinkDNS, SetLinkDomains und SetLinkDefaultRoute. Derjenige, der als Fehlerantwort zurückkommt, ist der zu behebende. Diese Antwort nennt meist ihren Grund, zum Beispiel org.freedesktop.DBus.Error.AccessDenied gegen SetLinkDomains. Notieren Sie, welcher Aufruf es war, denn der nächste Abschnitt handelt davon, genau diesen Aufruf durchzulassen.

Gewähren Sie dem Client die nötigen polkit-Aktionen

Lesen Sie die Policy, bevor Sie eine Regel schreiben. Ein Client, der als Dienst läuft, kann keine interaktive Abfrage beantworten, also ist ein implizites auth_admin_keep eine Sackgasse.

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

Lautet die Antwort auth_admin_keep, braucht der Client eine ausdrückliche Regel. Der Ausschnitt unten erlaubt die vier resolve1-Aktionen, die ein VPN-Client während einer Verbindung nutzt, und lässt alles andere bei 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;
});

Legen Sie ihn in /etc/polkit-1/rules.d/ als eine Datei ab, die Sie später wiedererkennen, etwa 50-azurevpn.rules, und ersetzen Sie den Gruppennamen im Ausschnitt durch Ihren eigenen, bevor Sie sich ab- und wieder anmelden. Halten Sie ihn eng, denn jede resolve1-Aktion für jedes Konto zu erlauben ist breiter, als dieser Client braucht, und später viel schwerer zu auditieren.

Prüfen Sie das Profil-XML, bevor Sie polkit bearbeiten

Ein von Hand bearbeitetes Profil kann wortlos ignoriert werden. Microsoft dokumentiert ein flaches Layout, in dem dnsserver Einträge direkt in dnsservers liegen und Suffixe in dnssuffixes. Ein zusätzliches Wrapper-Element um jede Adresse ist nicht diese Form, und der Client fällt stillschweigend auf das zurück, was das Gateway schiebt.

Führen Sie den Entfernungstest durch, bevor Sie polkit anfassen. Entfernen Sie den Suffix-Block, verbinden Sie sich neu und beobachten Sie, ob sich der Dialog ändert. Wenn ja, war der scheiternde Aufruf die Domänenübergabe, und die Korrektur ist Autorisierung statt einer weiteren XML-Bearbeitung.

Verifizieren Sie die Domäne auf der Tunnelverbindung

Verbinden Sie sich neu und lesen Sie resolvectl status erneut, und prüfen Sie, ob die Tunnelverbindung den Namensserver und die Suchdomäne zusammen trägt. Lösen Sie einen kurzen privaten Namen auf statt eines öffentlichen. Wenn der Name aufgelöst wird, der Dienst dahinter aber nicht antwortet, hat die DNS-Übergabe funktioniert und das verbleibende Problem ist das Routing.

Schreiben Sie den Resolver-Eigentümer, den gescheiterten D-Bus-Aufruf, die Regeldatei und die Profilversion ins Ticket. Diese vier Zeilen machen den nächsten Linux-Laptop zu einer kurzen Korrektur statt zu einer wiederholten Untersuchung.