Tunnelen kommer op, certifikatet valideres, og så siger en dialog, at DNS-serveren eller domænerne ikke kunne sættes. På Linux handler den dialog normalt ikke om gatewayen: klienten overlader navnekonfigurationen til systemd-resolved over D-Bus, og en afvist overdragelse lader interfacet stå oppe med opløsning, der stadig peger på det gamle link. Den samme laptop opløser navne fint, før profilen får et suffix, og det er sporet, der er værd at følge. Intet ved tunnelen ændrede sig i det øjeblik, dialogen dukkede op.

Uden suffix skubber klienten kun navneservere. Tilføj et søgedomæne, og et andet kald slutter sig til det, SetLinkDomains, med sin egen autorisationskontrol, og derfor virker den identiske profil på Windows og fejler her. Gatewayen skubber de samme indstillinger i begge tilfælde, og komponenten, der afviser dem, er lokal.

Bekræft, at systemd-resolved er den resolver, der styrer

Denne klient taler med systemd-resolved og med ingen andre. Arch og flere andre distributioner leverer den deaktiveret, og /etc/resolv.conf kan tilhøre en helt anden resolver, så fastslå ejeren, før du ser på tilladelser.

Tre kommandoer afgør det:

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

Du leder efter en aktiv tjeneste, et symbolsk link, der peger på /run/systemd/resolve/stub-resolv.conf, og DNS pr. link i resolvectl. Når NetworkManager i stedet har ejerskabet, flyt det til resolved i stedet for at kæmpe med klienten; drop-in-filen nedenfor sætter begge nøgler:

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

Genstart NetworkManager, når den fil findes. En inaktiv resolver sammen med en klient, der bliver ved med at kalde dens D-Bus-navn, giver en fejl, der ikke navngiver nogen af dem.

Overvåg det D-Bus-kald, der fejler

Dette trin gør dialogen til et konkret svar. Overvåg resolver-interfacet i en terminal og journalen i en anden, og genopret så forbindelsen:

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

Tre kald bør dukke op: SetLinkDNS, SetLinkDomains og SetLinkDefaultRoute. Det, der kommer tilbage som fejlsvar, er det, der skal rettes. Det svar angiver normalt årsagen, for eksempel org.freedesktop.DBus.Error.AccessDenied mod SetLinkDomains. Noter hvilket kald det var, for det næste afsnit handler om at lukke netop det kald igennem.

Giv klienten de nødvendige polkit-handlinger

Læs politikken, før du skriver en regel. En klient, der kører som tjeneste, kan ikke svare på en interaktiv forespørgsel, så en implicit auth_admin_keep er en blindgyde.

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

Er svaret auth_admin_keep, har klienten brug for en udtrykkelig regel. Uddraget nedenfor tillader de fire resolve1-handlinger, som en VPN-klient bruger under en forbindelse, og lader alt andet blive ved 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;
});

Læg det i /etc/polkit-1/rules.d/ som en fil, du kan genkende senere, for eksempel 50-azurevpn.rules, og erstat gruppenavnet i uddraget med dit eget, før du logger ud og ind igen. Hold det snævert, for at tillade hver resolve1-handling for hver konto er bredere, end denne klient har brug for, og meget sværere at revidere bagefter.

Tjek profilens XML, før du redigerer polkit

En profil, der er redigeret i hånden, kan blive ignoreret uden et ord. Microsoft dokumenterer et fladt layout, hvor dnsserver-poster ligger direkte inde i dnsservers og suffixer inde i dnssuffixes. Et ekstra wrapper-element omkring hver adresse er ikke den form, og klienten falder stille tilbage til det, gatewayen skubber.

Kør fjernelsestesten, før du rører polkit. Fjern suffix-blokken, genopret forbindelsen, og se, om dialogen ændrer sig. Gør den det, var det fejlende kald domæneoverdragelsen, og rettelsen er autorisation frem for endnu en XML-redigering.

Bekræft domænet på tunnel-linket

Genopret forbindelsen, og læs resolvectl status igen, og tjek, at tunnel-linket bærer navneserveren og søgedomænet sammen. Opløs et kort privat navn i stedet for et offentligt. Når navnet opløses, men tjenesten bag det ikke svarer, virkede DNS-overdragelsen, og det resterende problem er routing.

Skriv resolver-ejeren, det fejlende D-Bus-kald, regelfilen og profilversionen i ticketen. De fire linjer gør den næste Linux-laptop til en kort rettelse i stedet for en gentagen undersøgelse.

Relaterede artikler