Azure VPN Client på Linux: DNS-domene kunne ikkje setjast

Tunnelen kjem opp, sertifikatet blir validert, og då seier ein dialog at DNS-tenaren eller domena ikkje kunne setjast. På Linux handlar den dialogen vanlegvis ikkje om gatewayen: klienten overlet namnekonfigurasjonen til systemd-resolved over D-Bus, og ei avvist overlevering lèt grensesnittet stå oppe med namneoppslag som framleis peikar på den gamle sambandet. Den same laptoppen løyser namn fint før profilen får eit suffix, og det er sporet som er verdt å følgje. Ingenting ved tunnelen endra seg i det augneblinken dialogen dukka opp.

Utan suffix skuv klienten berre namnetenarar. Legg til eit søkjedomene, og eit andre kall sluttar seg til det, SetLinkDomains, med si eiga autorisasjonssjekk, difor verkar den same profilen på Windows og feilar her. Gatewayen skuv dei same innstillingane i begge tilfelle, og komponenten som avviser dei, er lokal.

Stadfest at systemd-resolved er oppslageren

Denne klienten snakkar med systemd-resolved og med ingen andre. Arch og fleire andre distribusjonar leverer han deaktivert, og /etc/resolv.conf kan høyre til ein heilt annan oppslager, så fastslå eigaren før du ser på løyve.

Tre kommandoar avgjer saka:

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

Du ser etter ein aktiv teneste, ei symbolsk lenkje som peikar på /run/systemd/resolve/stub-resolv.conf, og DNS per lenkje i resolvectl. Når NetworkManager i staden har eigarskapen, flytt han til resolved i staden for å kjempe med klienten; drop-in-fila nedanfor set begge nøklane:

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

Start NetworkManager på nytt når den fila finst. Ein inaktiv oppslager saman med ein klient som held fram med å kalle på D-Bus-namnet, gjev ein feil som ikkje namngjev nokon av dei.

Følg med på D-Bus-kallet som feilar

Dette trinnet gjer dialogen om til eit konkret svar. Følg med på grensesnittet til oppslageren i eitt terminalvindauge og journalen i eit anna, og kople deretter til på nytt:

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

Tre kall skal dukke opp: SetLinkDNS, SetLinkDomains og SetLinkDefaultRoute. Det som kjem tilbake som feilsvar, er det som skal rettast. Det svaret oppgjev vanlegvis årsaka, til dømes org.freedesktop.DBus.Error.AccessDenied mot SetLinkDomains. Noter kva kall det var, for neste del handlar om å sleppe nettopp det kallet gjennom.

Gje klienten polkit-handlingane han treng

Les policyen før du skriv ei regel. Ein klient som køyrer som teneste, kan ikkje svare på ei interaktiv førespurnad, så ein implisitt auth_admin_keep er ein blindveg.

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

Viss svaret er auth_admin_keep, treng klienten ei uttrykkeleg regel. Utdraget nedanfor tillèt dei fire resolve1-handlingane som ein VPN-klient brukar under ei tilkopling, og lèt alt anna stå på 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;
});

Legg han i /etc/polkit-1/rules.d/ som ei fil du kjenner att seinare, til dømes 50-azurevpn.rules, og byt ut gruppenamnet i utdraget med ditt eige før du loggar ut og inn att. Hald han smal, for å tillate kvar resolve1-handling for kvar konto er breiare enn denne klienten treng og mykje vanskelegare å revidere seinare.

Sjekk XML-en til profilen før du redigerer polkit

Ein profil som er redigert for hand, kan bli ignorert utan eit ord. Microsoft dokumenterer eit flatt oppsett der dnsserver-oppføringar ligg direkte inne i dnsservers og suffix inne i dnssuffixes. Eit ekstra innpakkingselement rundt kvar adresse er ikkje den forma, og klienten fell stille tilbake på det gatewayen skuv.

Køyr fjernetesten før du rører polkit. Fjern suffixblokka, kople til på nytt og sjå om dialogen endrar seg. Gjer han det, var det feilande kallet domeneoverleveringa, og rettinga er autorisasjon framfor nok ei XML-redigering.

Stadfest domenet på tunnelkoplinga

Kople til på nytt og les resolvectl status igjen, og kontroller at tunnelkoplinga ber namnetenaren og søkjedomenet saman. Løys eit kort privat namn i staden for eit offentleg. Når namnet blir løyst, men tenesta bak svarar ikkje, verka DNS-overleveringa, og det attverande problemet er ruting.

Skriv eigaren av oppslageren, det feilande D-Bus-kallet, regelfila og profilversjonen i saka. Dei fire linjene gjer den neste Linux-laptopen til ei kort retting i staden for ei gjenteken undersøking.