Azure VPN Client v Linuxu: DNS domény nelze nastavit

Tunel naskočí a linuxový klient pak nemůže nastavit DNS domény. Zkontrolujte systemd-resolved, sledujte volání D-Bus a opravte akci polkit.

Tunel naskočí, certifikát se ověří a pak dialog oznámí, že DNS server nebo domény nelze nastavit. V Linuxu ten dialog obvykle není o bráně: klient předává konfiguraci jmen systemd-resolvedu přes D-Bus a odmítnuté předání nechá rozhraní nahoru s rozlišením, které stále ukazuje na staré spojení. Stejný notebook překládá jména správně, dokud profil nezíská sufix, a to je stopa, kterou stojí za to sledovat. Na tunelu se v okamžiku, kdy se dialog objevil, nic nezměnilo.

Bez sufixu klient posílá jen servery jmen. Přidejte vyhledávací doménu a přidá se k ní druhé volání, SetLinkDomains, s vlastní kontrolou autorizace, proto stejný profil funguje ve Windows a tady selhává. Brána posílá v obou případech stejná nastavení a komponenta, která je odmítá, je místní.

Ověřte, že překladačem je systemd-resolved

Tento klient mluví se systemd-resolved a s nikým jiným. Arch a několik dalších distribucí ho dodává vypnutý a /etc/resolv.conf může patřit úplně jinému překladači, takže nejdřív zjistěte vlastníka a teprve pak se dívejte na oprávnění.

Rozhodnou to tři příkazy:

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

Hledáte aktivní službu, symbolický odkaz mířící na /run/systemd/resolve/stub-resolv.conf, a DNS pro každé spojení v resolvectl. Pokud vlastnictví drží NetworkManager, převeďte ho na resolved, místo abyste se s klientem přetahovali; drop-in níže nastaví oba klíče:

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

Jakmile ten soubor existuje, restartujte NetworkManager. Neaktivní překladač spolu s klientem, který pořád volá jeho jméno v D-Bus, dává chybu, která nejmenuje ani jednoho z nich.

Sledujte volání D-Bus, které selhává

Tento krok promění dialog v konkrétní odpověď. Sledujte rozhraní překladače v jednom terminálu a journal v druhém, pak se znovu připojte:

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

Měla by se objevit tři volání: SetLinkDNS, SetLinkDomains a SetLinkDefaultRoute. To, které se vrátí jako chybová odpověď, je to, které je třeba opravit. Ta odpověď obvykle uvádí důvod, například org.freedesktop.DBus.Error.AccessDenied proti SetLinkDomains. Poznamenejte si, které volání to bylo, protože další část je právě o tom, jak ho pustit dál.

Udělte klientovi potřebné akce polkit

Přečtěte si politiku, než napíšete pravidlo. Klient běžící jako služba nemůže odpovědět na interaktivní výzvu, takže implicitní auth_admin_keep je slepá ulička.

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

Pokud je odpověď auth_admin_keep, klient potřebuje výslovné pravidlo. Úryvek níže povoluje čtyři akce resolve1, které VPN klient při připojení používá, a všechno ostatní nechává na 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;
});

Vložte ho do /etc/polkit-1/rules.d/ jako soubor, který později poznáte, například 50-azurevpn.rules, a než se odhlásíte a znovu přihlásíte, nahraďte název skupiny v úryvku svým. Držte ho úzký, protože povolit každou akci resolve1 každému účtu je širší, než tento klient potřebuje, a mnohem těžší na pozdější audit.

Zkontrolujte XML profilu, než začnete editovat polkit

Ručně upravený profil může být bez slova ignorován. Microsoft dokumentuje ploché uspořádání, ve kterém položky dnsserver stojí přímo uvnitř dnsservers, a sufixy uvnitř dnssuffixes. Další obalový prvek kolem každé adresy není tento tvar a klient se tiše vrátí k tomu, co pošle brána.

Než se dotknete polkit, proveďte test odstranění. Vyjměte blok se sufixem, připojte se znovu a sledujte, jestli se dialog změní. Pokud ano, selhávající volání bylo předání domény a opravou je autorizace, ne další úprava XML.

Ověřte doménu na tunelovém spojení

Připojte se znovu a přečtěte resolvectl status znovu, a zkontrolujte, že tunelové spojení nese server jmen i vyhledávací doménu společně. Přeložte krátké privátní jméno místo veřejného. Když se jméno přeloží, ale služba za ním neodpovídá, předání DNS fungovalo a zbývajícím problémem je směrování.

Do tiketu napište vlastníka překladače, volání D-Bus, které selhalo, soubor pravidla a verzi profilu. Ty čtyři řádky promění další linuxový notebook v krátkou opravu místo opakovaného vyšetřování.

Související články