Azure VPN Client en Linux: ne eblis agordi DNS-domajnojn

La tunelo ekfunkcias, kaj tiam la Linux-kliento ne povas agordi DNS-domajnojn. Kontrolu systemd-resolved, observu la D-Bus-vokon kaj riparu la polkit-agon.

La tunelo ekfunkcias, la atestilo validiĝas, kaj tiam dialogo diras, ke la DNS-servilo aŭ la domajnoj ne povis esti agorditaj. En Linux tiu dialogo kutime ne temas pri la enirejo: la kliento transdonas la nomkonfiguron al systemd-resolved per D-Bus, kaj rifuzita transdono lasas la interfacon supre kun solvado ankoraŭ montranta al la malnova ligo. La sama tekkomputilo solvas nomojn bone antaŭ ol la profilo ricevas sufikson, kaj tio estas la spuro inda je sekvado. Nenio pri la tunelo ŝanĝiĝis en la momento, kiam la dialogo aperis.

Sen sufikso la kliento nur puŝas nomservilojn. Aldonu serĉdomajnon kaj dua voko aliĝas al ĝi, SetLinkDomains, kun propra rajtigokontrolo, pro kio la sama profilo funkcias en Windows kaj malsukcesas ĉi tie. La enirejo puŝas la samajn agordojn en ambaŭ kazoj, kaj la komponanto, kiu rifuzas ilin, estas loka.

Konfirmu, ke systemd-resolved estas la solvilo

Ĉi tiu kliento parolas kun systemd-resolved kaj kun neniu alia. Arch kaj pluraj aliaj distribuaĵoj liveras ĝin malŝaltita, kaj /etc/resolv.conf povas aparteni al tute alia solvilo, do establu la posedanton antaŭ ol rigardi permesojn.

Tri komandoj klarigas tion:

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

Vi serĉas aktivan servon, simbolligilon direktitan al /run/systemd/resolve/stub-resolv.conf, kaj DNS-po-ligo en resolvectl. Kiam NetworkManager tenas la posedrajton anstataŭe, transigu ĝin al resolved anstataŭ batali kun la kliento; la drop-in sube agordas ambaŭ ŝlosilojn:

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

Restartigu NetworkManager post kiam tiu dosiero ekzistas. Neaktiva solvilo kune kun kliento, kiu daŭre vokas ĝian D-Bus-nomon, produktas eraron, kiu nomas nek unu nek la alian.

Observu la D-Bus-vokon, kiu malsukcesas

Ĉi tiu paŝo transformas la dialogon en konkretan respondon. Observu la solvilan interfacon en unu terminalo kaj la ĵurnalon en alia, poste rekonektu:

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

Tri vokoj devus aperi: SetLinkDNS, SetLinkDomains kaj SetLinkDefaultRoute. Tiu, kiu revenas kiel erarrespondeco, estas la riparinda. Tiu respondo kutime nomas sian kialon, ekzemple org.freedesktop.DBus.Error.AccessDenied kontraŭ SetLinkDomains. Notu, kiu voko estis, ĉar la sekva sekcio temas pri tralaso de ĝuste tiu voko.

Donu al la kliento la bezonatajn polkit-agojn

Legu la politikon antaŭ ol skribi regulon. Kliento funkcianta kiel servo ne povas respondi interagan demandon, do implica auth_admin_keep estas sakstrato.

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

Se la respondo estas auth_admin_keep, la kliento bezonas eksplicitan regulon. La fragmento sube permesas la kvar resolve1-agojn, kiujn VPN-kliento uzas dum konekto, kaj lasas ĉion alian ĉe 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;
});

Metu ĝin en /etc/polkit-1/rules.d/ kiel dosieron, kiun vi rekonscios poste, ekzemple 50-azurevpn.rules, kaj anstataŭigu la grupnomon en la fragmento per via propra antaŭ ol elsaluti kaj resaluti. Tenu ĝin mallarĝa, ĉar permesi ĉiun resolve1-agon por ĉiu konto estas pli larĝa ol tiu kliento bezonas kaj multe pli malfacila por posta revizio.

Kontrolu la profilan XML antaŭ ol redakti polkit

Permane redaktita profilo povas esti ignorita sen vorto. Microsoft dokumentas ebenan aranĝon en kiu dnsserver eroj sidas rekte ene de dnsservers kaj sufiksoj ene de dnssuffixes. Plia ĉirkaŭvolva elemento ĉirkaŭ ĉiu adreso ne estas tiu formo, kaj la kliento silente falas reen al tio, kion puŝas la enirejo.

Faru la forigteston antaŭ ol tuŝi polkit. Forigu la sufiksan blokon, rekonektu kaj observu, ĉu la dialogo ŝanĝiĝas. Se ĝi ŝanĝiĝas, la malsukcesinta voko estis la domajna transdono, kaj la solvo estas rajtigo, ne plia XML-redakto.

Kontrolu la domajnon sur la tunela ligo

Rekonektu kaj legu resolvectl status denove, kontrolante, ke la tunela ligo portas la nomservilon kaj la serĉdomajnon kune. Solvu mallongan privatan nomon anstataŭ publikan. Kiam la nomo solviĝas sed la servo malantaŭ ĝi ne respondas, la DNS-transdono funkciis kaj la restanta problemo estas enkursigo.

Skribu en la bileton la posedanton de la solvilo, la malsukcesintan D-Bus-vokon, la regulan dosieron kaj la profilan version. Tiuj kvar linioj transformas la sekvan Linux-tekkomputilon en mallongan riparon anstataŭ ripetan esploradon.

Rilataj artikoloj