Azure VPN Client sistemoje Linux: DNS domenų nustatyti nepavyko

Tunelis pakyla, o tada Linux klientas negali nustatyti DNS domenų. Patikrinkite systemd-resolved, stebėkite D-Bus iškvietimą ir pataisykite polkit veiksmą.

Tunelis pakyla, sertifikatas patikrinamas, ir tada dialogas praneša, kad DNS serverio ar domenų nustatyti nepavyko. Linux sistemoje šis dialogas paprastai ne apie tinklų sietuvą: klientas perduoda vardų konfigūraciją systemd-resolved per D-Bus, o atmestas perdavimas palieka sąsają pakeltą, kai vardų skyrimas vis dar rodo į seną jungtį. Tas pats nešiojamas kompiuteris vardus skiria tinkamai, kol profilis gauna priesagą, ir tai yra pėdsakas, kuriuo verta sekti. Tunelyje niekas nepasikeitė tą akimirką, kai pasirodė dialogas.

Be priesagos klientas stumia tik vardų serverius. Pridėkite paieškos domeną, ir prie jo prisijungia antras iškvietimas, SetLinkDomains, su savo autorizacijos patikra, todėl tas pats profilis veikia Windows ir nepavyksta čia. Tinklų sietuvas abiem atvejais stumia tuos pačius nustatymus, o juos atmetantis komponentas yra vietinis.

Įsitikinkite, kad sprendėjas yra systemd-resolved

Šis klientas kalba tik su systemd-resolved ir su niekuo kitu. Arch ir kelios kitos distribucijos pateikia jį išjungtą, o /etc/resolv.conf gali priklausyti visai kitam sprendėjui, todėl nustatykite savininką prieš žiūrėdami į leidimus.

Trys komandos tai išsprendžia:

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

Ieškote aktyvios paslaugos, simbolinės nuorodos, nukreiptos į /run/systemd/resolve/stub-resolv.conf, ir DNS kiekvienai jungčiai komandoje resolvectl. Kai savininkas yra NetworkManager, perkelkite jį į resolved, o ne kovokite su klientu; žemiau esantis drop-in nustato abu raktus:

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

Paleiskite NetworkManager iš naujo, kai tik tas failas atsiras. Neaktyvus sprendėjas kartu su klientu, kuris toliau šaukia jo D-Bus vardą, sukuria klaidą, kuri neįvardija nė vieno jų.

Stebėkite D-Bus iškvietimą, kuris nepavyksta

Šis žingsnis paverčia dialogą konkrečiu atsakymu. Stebėkite sprendėjo sąsają viename terminale, o žurnalą kitame, tada prisijunkite iš naujo:

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

Turėtų pasirodyti trys iškvietimai: SetLinkDNS, SetLinkDomains ir SetLinkDefaultRoute. Tas, kuris grįžta kaip klaidos atsakymas, yra taisytinas. Tas atsakymas paprastai nurodo priežastį, pavyzdžiui org.freedesktop.DBus.Error.AccessDenied prieš SetLinkDomains. Užsirašykite, kuris tai buvo iškvietimas, nes kitas skyrius kaip tik apie to iškvietimo praleidimą.

Suteikite klientui reikiamus polkit veiksmus

Perskaitykite politiką prieš rašydami taisyklę. Klientas, veikiantis kaip paslauga, negali atsakyti į interaktyvų raginimą, todėl implicitinis auth_admin_keep yra aklavietė.

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

Jei atsakymas yra auth_admin_keep, klientui reikia aiškios taisyklės. Žemiau esantis fragmentas leidžia keturis resolve1 veiksmus, kuriuos VPN klientas naudoja jungdamasis, ir palieka visa kita ties 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;
});

Įdėkite jį į /etc/polkit-1/rules.d/ kaip failą, kurį vėliau atpažinsite, pavyzdžiui 50-azurevpn.rules, ir prieš atsijungdami bei vėl prisijungdami pakeiskite fragmente esantį grupės pavadinimą savuoju. Laikykite jį siaurą, nes leisti kiekvieną resolve1 veiksmą kiekvienai paskyrai yra plačiau, nei šiam klientui reikia, ir daug sunkiau vėliau audituoti.

Patikrinkite profilio XML prieš redaguodami polkit

Rankiniu būdu redaguotas profilis gali būti tyliai ignoruojamas. Microsoft dokumentuoja plokščią išdėstymą, kuriame dnsserver įrašai yra tiesiogiai dnsservers viduje, o priesagos dnssuffixes viduje. Papildomas apvalkalo elementas aplink kiekvieną adresą nėra ta forma, ir klientas tyliai grįžta prie to, ką stumia tinklų sietuvas.

Atlikite pašalinimo testą prieš liesdami polkit. Pašalinkite priesagos bloką, prisijunkite iš naujo ir pažiūrėkite, ar dialogas keičiasi. Jei keičiasi, nepavykęs iškvietimas buvo domeno perdavimas, o pataisa yra autorizacija, o ne dar vienas XML redagavimas.

Patikrinkite domeną tunelio jungtyje

Prisijunkite iš naujo ir dar kartą perskaitykite resolvectl status, patikrindami, kad tunelio jungtis kartu neša vardų serverį ir paieškos domeną. Išspręskite trumpą privatų vardą, o ne viešą. Kai vardas išsprendžiamas, bet už jo esanti paslauga neatsako, DNS perdavimas suveikė, o likusi problema yra maršrutizavimas.

Į bilietą įrašykite sprendėjo savininką, nepavykusį D-Bus iškvietimą, taisyklės failą ir profilio versiją. Tos keturios eilutės paverčia kitą Linux nešiojamąjį kompiuterį trumpa pataisa, o ne pasikartojančiu tyrimu.

Susiję straipsniai