Azure VPN Client w systemie Linux: nie udało się ustawić domen DNS

Tunel się podnosi, a potem klient Linux nie może ustawić domen DNS. Sprawdź systemd-resolved, obserwuj wywołanie D-Bus i napraw akcję polkit.

Tunel się podnosi, certyfikat zostaje zweryfikowany, a potem okno dialogowe mówi, że nie udało się ustawić serwera DNS ani domen. W Linuksie to okno zazwyczaj nie dotyczy bramy: klient przekazuje konfigurację nazw do systemd-resolved przez D-Bus, a odrzucone przekazanie pozostawia interfejs podniesiony z rozwiązywaniem nazw wciąż wskazującym na stare połączenie. Ten sam laptop poprawnie rozwiązuje nazwy, zanim profil dostanie sufiks, i to jest trop, który warto śledzić. Nic w tunelu nie zmieniło się w chwili, gdy pojawiło się okno.

Bez sufiksu klient wypycha tylko serwery nazw. Dodaj domenę wyszukiwania, a dołącza do niej drugie wywołanie, SetLinkDomains, z własną kontrolą autoryzacji, dlatego ten sam profil działa w Windows, a tutaj zawodzi. Brama w obu przypadkach wypycha te same ustawienia, a komponent, który je odrzuca, jest lokalny.

Upewnij się, że resolverem jest systemd-resolved

Ten klient rozmawia z systemd-resolved i z nikim innym. Arch i kilka innych dystrybucji dostarczają go wyłączonego, a /etc/resolv.conf może należeć do zupełnie innego resolvera, więc ustal właściciela, zanim spojrzysz na uprawnienia.

Trzy polecenia rozstrzygają sprawę:

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

Szukasz aktywnej usługi, dowiązania symbolicznego wskazującego na /run/systemd/resolve/stub-resolv.conf, oraz DNS dla każdego łącza w resolvectl. Gdy właścicielem jest NetworkManager, przenieś to na resolved zamiast walczyć z klientem; plik drop-in poniżej ustawia oba klucze:

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

Zrestartuj NetworkManager, gdy tylko ten plik istnieje. Nieaktywny resolver wraz z klientem, który nadal wywołuje jego nazwę D-Bus, daje błąd, który nie nazywa żadnego z nich.

Obserwuj wywołanie D-Bus, które zawodzi

Ten krok zamienia okno w konkretną odpowiedź. Obserwuj interfejs resolvera w jednym terminalu, a dziennik w drugim, po czym połącz się ponownie:

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

Powinny pojawić się trzy wywołania: SetLinkDNS, SetLinkDomains i SetLinkDefaultRoute. To, które wraca jako odpowiedź błędu, jest tym do naprawy. Ta odpowiedź zwykle podaje swoją przyczynę, na przykład org.freedesktop.DBus.Error.AccessDenied wobec SetLinkDomains. Zanotuj, które to było wywołanie, bo następna sekcja dotyczy właśnie przepuszczania tego wywołania.

Przyznaj klientowi potrzebne akcje polkit

Przeczytaj politykę, zanim napiszesz regułę. Klient działający jako usługa nie może odpowiedzieć na interaktywne pytanie, więc niejawne auth_admin_keep to ślepa uliczka.

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

Jeśli odpowiedź to auth_admin_keep, klient potrzebuje wyraźnej reguły. Poniższy fragment pozwala na cztery akcje resolve1, których klient VPN używa podczas połączenia, i zostawia wszystko inne 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;
});

Umieść go w /etc/polkit-1/rules.d/ jako plik, który później rozpoznasz, na przykład 50-azurevpn.rules, i przed wylogowaniem i ponownym zalogowaniem zastąp nazwę grupy we fragmencie swoją. Trzymaj go wąsko, bo zezwalanie na każdą akcję resolve1 dla każdego konta jest szersze, niż potrzebuje ten klient, i znacznie trudniejsze do późniejszego audytu.

Sprawdź XML profilu, zanim zmienisz polkit

Profil edytowany ręcznie może zostać zignorowany bez słowa. Microsoft dokumentuje płaski układ, w którym wpisy dnsserver leżą bezpośrednio w dnsservers, a sufiksy w dnssuffixes. Dodatkowy element otoczki wokół każdego adresu nie jest tą formą, a klient po cichu wraca do tego, co wypycha brama.

Przeprowadź test usuwania, zanim dotkniesz polkit. Usuń blok sufiksu, połącz się ponownie i sprawdź, czy okno się zmienia. Jeśli tak, zawodzące wywołanie było przekazaniem domeny, a poprawką jest autoryzacja, nie kolejna edycja XML.

Zweryfikuj domenę na łączu tunelu

Połącz się ponownie i przeczytaj resolvectl status jeszcze raz, sprawdzając, czy łącze tunelu niesie serwer nazw i domenę wyszukiwania razem. Rozwiąż krótką nazwę prywatną, a nie publiczną. Gdy nazwa się rozwiązuje, ale usługa za nią nie odpowiada, przekazanie DNS zadziałało, a pozostały problem to routing.

Zapisz w zgłoszeniu właściciela resolvera, zawodzące wywołanie D-Bus, plik reguły i wersję profilu. Te cztery linie zmieniają następny laptop z Linuksem w krótką poprawkę zamiast powtarzanego śledztwa.

Powiązane artykuły