Tunel se dvigne, potrdilo se preveri in nato pogovorno okno sporoči, da strežnika DNS ali domen ni bilo mogoče nastaviti. V Linuxu to okno običajno ne govori o prehodu: odjemalec preda konfiguracijo imen systemd-resolvedu prek D-Busa, zavrnjena predaja pa pusti vmesnik dvignjen s razreševanjem, ki še vedno kaže na staro povezavo. Isti prenosnik imena pravilno razrešuje, dokler profil ne dobi pripone, in to je sled, ki se je vredno držati. Na tunelu se v trenutku, ko se je okno pojavilo, ni nič spremenilo.

Brez pripone odjemalec potiska samo strežnike imen. Dodajte iskalno domeno in k njej se pridruži drugi klic, SetLinkDomains, z lastnim preverjanjem avtorizacije, zato isti profil deluje v Windowsu in tu ne uspe. Prehod v obeh primerih potiska iste nastavitve, komponenta, ki jih zavrača, pa je lokalna.

Potrdite, da je razreševalnik systemd-resolved

Ta odjemalec govori samo s systemd-resolvedom in z nikomer drugim. Arch in več drugih distribucij ga dobavlja izklopljenega, /etc/resolv.conf pa lahko pripada povsem drugemu razreševalniku, zato ugotovite lastnika, preden pogledate dovoljenja.

Trije ukazi to razjasnijo:

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

Iščete aktivno storitev, simbolno povezavo, ki kaže na /run/systemd/resolve/stub-resolv.conf, in DNS za posamezno povezavo v resolvectl. Ko ima lastništvo NetworkManager, ga prestavite na resolved, namesto da bi se prepirali z odjemalcem; spodnja datoteka drop-in nastavi oba ključa:

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

Znova zaženite NetworkManager, ko ta datoteka obstaja. Nedejaven razreševalnik skupaj z odjemalcem, ki še naprej kliče njegovo ime D-Bus, ustvari napako, ki ne imenuje nobenega od njiju.

Opazujte klic D-Bus, ki ne uspe

Ta korak spremeni okno v konkreten odgovor. Opazujte vmesnik razreševalnika v enem terminalu in dnevnik v drugem, nato se znova povežite:

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

Pojaviti bi se morali trije klici: SetLinkDNS, SetLinkDomains in SetLinkDefaultRoute. Tisti, ki se vrne kot odgovor z napako, je tisti, ki ga je treba popraviti. Ta odgovor običajno navede svoj razlog, na primer org.freedesktop.DBus.Error.AccessDenied proti SetLinkDomains. Zapišite, kateri klic je bil, ker naslednji razdelek govori prav o spuščanju tega klica skozi.

Odjemalcu podelite potrebna dejanja polkit

Preberite pravilnik, preden napišete pravilo. Odjemalec, ki teče kot storitev, ne more odgovoriti na interaktivno zahtevo, zato je implicitni auth_admin_keep slepa ulica.

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

Če je odgovor auth_admin_keep, odjemalec potrebuje izrecno pravilo. Spodnji odlomek dovoljuje štiri dejanja resolve1, ki jih odjemalec VPN uporablja med povezavo, vse drugo pa pusti 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;
});

Postavite ga v /etc/polkit-1/rules.d/ kot datoteko, ki jo boste pozneje prepoznali, na primer 50-azurevpn.rules, in pred odjavo in ponovno prijavo zamenjajte ime skupine v odlomku s svojim. Držite ga ozko, ker je dovoljenje vsakega dejanja resolve1 za vsak račun širše, kot ga ta odjemalec potrebuje, in veliko težje za poznejšo revizijo.

Preverite XML profila, preden urejate polkit

Ročno urejen profil je lahko brez besede prezrt. Microsoft dokumentira ravno postavitev, v kateri vnosi dnsserver stojijo neposredno v dnsservers, pripone pa v dnssuffixes. Dodaten ovojni element okoli vsakega naslova ni ta oblika, in odjemalec se tiho vrne k temu, kar potisne prehod.

Preden se dotaknete polkita, izvedite preskus odstranitve. Odstranite blok s pripono, se znova povežite in poglejte, ali se okno spremeni. Če se spremeni, je bil neuspešni klic predaja domene, popravek pa je avtorizacija, ne še eno urejanje XML.

Preverite domeno na tunelski povezavi

Znova se povežite in znova preberite resolvectl status, pri čemer preverite, da tunelska povezava nosi strežnik imen in iskalno domeno skupaj. Razrešite kratko zasebno ime namesto javnega. Ko se ime razreši, storitev za njim pa ne odgovori, je predaja DNS delovala in preostala težava je usmerjanje.

V zahtevek zapišite lastnika razreševalnika, neuspešni klic D-Bus, datoteko pravila in različico profila. Te štiri vrstice spremenijo naslednji prenosnik Linux v kratek popravek namesto ponovne preiskave.

Sorodni članki