Azure VPN Client op Linux: DNS-domeine kon nie gestel word nie

Die tonnel kom op en dan kan die Linux-kliënt nie DNS-domeine stel nie. Kontroleer systemd-resolved, kyk na die D-Bus-oproep en maak die polkit-aksie reg.

Die tonnel kom op, die sertifikaat valideer, en dan sê ’n dialoog dat die DNS-bediener of domeine nie gestel kon word nie. Op Linux gaan daardie dialoog gewoonlik nie oor die gateway nie: die kliënt gee naamkonfigurasie oor D-Bus aan systemd-resolved, en ’n geweierde oorhandiging laat die koppelvlak op met resolusie wat steeds na die ou skakel wys. Dieselfde skootrekenaar los name fyn op voordat die profiel ’n agtervoegsel kry, en dit is die leidraad wat die moeite werd is om te volg. Niks aan die tonnel het verander op die oomblik toe die dialoog verskyn het nie.

Sonder ’n agtervoegsel stoot die kliënt net naambedieners. Voeg ’n soekdomein by en ’n tweede oproep sluit daarby aan, SetLinkDomains, met sy eie magtigingskontrole, en daarom werk dieselfde profiel op Windows maar faal hier. Die gateway stoot in elk geval dieselfde instellings, en die komponent wat dit weier, is plaaslik.

Bevestig dat systemd-resolved die resolusie-beheerder is

Hierdie kliënt praat met systemd-resolved en met niks anders nie. Arch en verskeie ander verspreidings lewer dit gedeaktiveer, en /etc/resolv.conf kan heeltemal aan ’n ander resolusie-beheerder behoort, so stel die eienaar vas voordat jy na regte kyk.

Drie opdragte maak dit duidelik:

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

Jy soek ’n aktiewe diens, ’n sagte skakel wat na /run/systemd/resolve/stub-resolv.conf wys, en per-skakel DNS in resolvectl. Wanneer NetworkManager eerder die eienaarskap hou, skuif dit na resolved eerder as om met die kliënt te stry; die drop-in hieronder stel albei sleutels:

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

Herbegin NetworkManager sodra daardie lêer bestaan. ’n Onaktiewe resolusie-beheerder saam met ’n kliënt wat aanhou om sy D-Bus-naam te roep, lewer ’n fout wat nie een van hulle noem nie.

Kyk na die D-Bus-oproep wat misluk

Hierdie stap verander die dialoog in ’n spesifieke antwoord. Kyk in een terminaal na die resolusie-koppelvlak en in ’n ander na die joernaal, en herverbind dan:

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

Drie oproepe behoort te verskyn: SetLinkDNS, SetLinkDomains en SetLinkDefaultRoute. Die een wat as ’n foutantwoord terugkom, is die een om reg te maak. Daardie antwoord noem gewoonlik sy rede, byvoorbeeld org.freedesktop.DBus.Error.AccessDenied teen SetLinkDomains. Let op watter oproep dit was, want die volgende afdeling handel oor hoe om daardie oproep deur te laat.

Verleen die polkit-aksies wat die kliënt nodig het

Lees die beleid voordat jy ’n reël skryf. ’n Kliënt wat as ’n diens loop, kan nie ’n interaktiewe opdrag beantwoord nie, so ’n implisiete auth_admin_keep is ’n doodloopstraat.

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

As die antwoord auth_admin_keep is, het die kliënt ’n eksplisiete reël nodig. Die brokkie hieronder laat die vier resolve1-aksies deur wat ’n VPN-kliënt tydens ’n verbinding gebruik, en laat alles anders by 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;
});

Plaas dit in /etc/polkit-1/rules.d/ as ’n lêer wat jy later sal herken, soos 50-azurevpn.rules, en vervang die groepsnaam in die brokkie met jou eie voordat jy uit- en weer aanmeld. Hou dit eng, want om elke resolve1-aksie vir elke rekening toe te laat, is wyer as wat hierdie kliënt nodig het en baie moeiliker om later te oudit.

Kontroleer die profiel-XML voordat jy polkit wysig

’n Profiel wat met die hand gewysig is, kan sonder ’n woord geïgnoreer word. Microsoft dokumenteer ’n plat uitleg waarin dnsserver-inskrywings direk binne dnsservers sit en agtervoegsels binne dnssuffixes. ’n Ekstra omhulsel-element rondom elke adres is nie daardie vorm nie, en die kliënt val stilweg terug op wat die gateway ook al stoot.

Doen die verwyderingstoets voordat jy aan polkit raak. Stroop die agtervoegselblok, herverbind en kyk of die dialoog verander. As dit verander, was die mislukte oproep die domein-oorhandiging, en die regstelling is magtiging eerder as nog ’n XML-wysiging.

Verifieer die domein op die tonnel-skakel

Herverbind en lees resolvectl status weer, en kontroleer dat die tonnel-skakel die naambediener en die soekdomein saam dra. Los ’n kort privaat naam op eerder as ’n publieke een. Wanneer die naam opgelos word maar die diens agter dit nie antwoord nie, het die DNS-oorhandiging gewerk en die oorblywende probleem is roetering.

Skryf die resolusie-eienaar, die D-Bus-oproep wat misluk het, die reëllêer en die profielweergawe in die kaartjie. Daardie vier reëls maak die volgende Linux-skootrekenaar ’n kort regstelling eerder as ’n herhaling van die ondersoek.

Verwante artikels