Azure VPN Client pe Linux: domeniile DNS nu au putut fi setate

Tunelul se ridică, iar apoi clientul Linux nu poate seta domeniile DNS. Verificați systemd-resolved, urmăriți apelul D-Bus și corectați acțiunea polkit.

Tunelul se ridică, certificatul este validat și apoi o casetă de dialog spune că serverul DNS sau domeniile nu au putut fi setate. Pe Linux acea casetă de obicei nu este despre gateway: clientul predă configurația numelor către systemd-resolved prin D-Bus, iar o predare refuzată lasă interfața ridicată cu rezolvarea încă îndreptată spre legătura veche. Același laptop rezolvă numele bine înainte ca profilul să primească un sufix, iar acesta este indiciul care merită urmărit. Nimic la tunel nu s-a schimbat în momentul în care a apărut caseta.

Fără sufix clientul împinge doar servere de nume. Adăugați un domeniu de căutare și un al doilea apel i se alătură, SetLinkDomains, cu propria verificare de autorizare, de aceea același profil funcționează pe Windows și eșuează aici. Gateway-ul împinge aceleași setări în ambele cazuri, iar componenta care le refuză este locală.

Confirmați că rezolvatorul este systemd-resolved

Acest client vorbește cu systemd-resolved și cu nimeni altcineva. Arch și alte câteva distribuții îl livrează dezactivat, iar /etc/resolv.conf poate aparține unui cu totul alt rezolvator, așa că stabiliți proprietarul înainte de a privi permisiunile.

Trei comenzi lămuresc asta:

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

Căutați un serviciu activ, o legătură simbolică îndreptată spre /run/systemd/resolve/stub-resolv.conf, și DNS pe fiecare legătură în resolvectl. Când NetworkManager deține proprietatea, mutați-o la resolved în loc să vă luptați cu clientul; fișierul drop-in de mai jos setează ambele chei:

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

Reporniți NetworkManager imediat ce acel fișier există. Un rezolvator inactiv împreună cu un client care continuă să îi strige numele D-Bus produc o eroare care nu numește niciunul dintre ei.

Urmăriți apelul D-Bus care eșuează

Acest pas transformă caseta într-un răspuns concret. Urmăriți interfața rezolvatorului într-un terminal și jurnalul în altul, apoi reconectați-vă:

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

Ar trebui să apară trei apeluri: SetLinkDNS, SetLinkDomains și SetLinkDefaultRoute. Cel care se întoarce ca răspuns de eroare este cel de corectat. Acel răspuns de obicei își spune motivul, de exemplu org.freedesktop.DBus.Error.AccessDenied față de SetLinkDomains. Notați care apel a fost, fiindcă secțiunea următoare trata exact despre lăsarea acelui apel să treacă.

Acordați clientului acțiunile polkit de care are nevoie

Citiți politica înainte de a scrie o regulă. Un client care rulează ca serviciu nu poate răspunde la o solicitare interactivă, așa că un auth_admin_keep implicit este o fundătură.

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

Dacă răspunsul este auth_admin_keep, clientul are nevoie de o regulă explicită. Fragmentul de mai jos permite cele patru acțiuni resolve1 pe care un client VPN le folosește în timpul unei conexiuni și lasă tot restul la 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;
});

Puneți-l în /etc/polkit-1/rules.d/ ca un fișier pe care îl veți recunoaște mai târziu, de exemplu 50-azurevpn.rules, și înlocuiți numele grupului din fragment cu al dumneavoastră înainte de a vă deconecta și reconecta. Țineți-l îngust, fiindcă a permite fiecare acțiune resolve1 pentru fiecare cont este mai larg decât are nevoie acest client și mult mai greu de auditat ulterior.

Verificați XML-ul profilului înainte de a edita polkit

Un profil editat manual poate fi ignorat fără un cuvânt. Microsoft documentează un aspect plat în care intrările dnsserver stau direct în dnsservers, iar sufixele în dnssuffixes. Un element de înfășurare suplimentar în jurul fiecărei adrese nu este acea formă, iar clientul revine în tăcere la ce împinge gateway-ul.

Faceți testul de eliminare înainte de a atinge polkit. Scoateți blocul de sufix, reconectați-vă și vedeți dacă se schimbă caseta. Dacă se schimbă, apelul care eșua era predarea domeniului, iar corectarea este autorizarea, nu o altă editare XML.

Verificați domeniul pe legătura tunelului

Reconectați-vă și citiți din nou resolvectl status, verificând că legătura tunelului poartă serverul de nume și domeniul de căutare împreună. Rezolvați un nume privat scurt, nu unul public. Când numele se rezolvă, dar serviciul din spate nu răspunde, predarea DNS a funcționat, iar problema rămasă este rutarea.

Scrieți în tichet proprietarul rezolvatorului, apelul D-Bus care a eșuat, fișierul de regulă și versiunea profilului. Acele patru rânduri transformă următorul laptop Linux într-o corectare scurtă în loc de o investigație repetată.

Articole similare