Azure VPN Client op Linux: DNS-domeinen koene net ynsteld wurde

De tunnel komt op en dan kin de Linux-klant gjin DNS-domeinen ynstelle. Kontrolearje systemd-resolved, besjoch de D-Bus-oprop en reparearje de polkit-aksje.

De tunnel komt op, it sertifikaat wurdt falidearre, en dan seit in dialooch dat de DNS-tsjinner of de domeinen net ynsteld wurde koene. Op Linux giet dy dialooch meastentiids net oer de gateway: de klant jout de namme-konfiguraasje oer D-Bus oan systemd-resolved, en in wegere oerjefte lit de interface omheech stean mei resolúsje dy't noch altyd nei de âlde ferbining wiist. Deselde laptop lost nammen goed op foardat it profyl in efterheaksel krijt, en dat is it oanwizing dêr't it wurdich is om te folgjen. Oan de tunnel feroare neat op it stuit dat de dialooch ferskynde.

Sûnder efterheaksel triuwt de klant allinnich namme-tsjinners. Foegje in sykdomein ta en in twadde oprop slút dêrby oan, SetLinkDomains, mei syn eigen autorisaasjekontrôle, dêrom wurket itselde profyl op Windows en mislearret hjir. De gateway triuwt yn beide gefallen deselde ynstellingen, en it komponint dat se wegeret is lokaal.

Befêstigje dat systemd-resolved de resolver is

Dizze klant praat mei systemd-resolved en mei nimmen oars. Arch en ferskate oare distribúsjes leverje it útskeakele, en /etc/resolv.conf kin hielendal by in oare resolver hearre, dus stel de eigner fêst foardat jo nei rjochten sjogge.

Trije opdrachten meitsje dat dúdlik:

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

Jo sykje in aktive tsjinst, in symboalyske keppeling dy't nei /run/systemd/resolve/stub-resolv.conf wiist, en DNS per keppeling yn resolvectl. As NetworkManager ynstee de eignerskip hat, ferpleats it dan nei resolved ynstee fan mei de klant te fjochtsjen; de drop-in hjirûnder set beide kaai:

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

Start NetworkManager opnij sa gau as dat bestân bestiet. In ynaktive resolver tegearre mei in klant dy't syn D-Bus-namme bliuwt oanroppen, jout in flater dy't gjin fan beide neamt.

Besjoch de D-Bus-oprop dy't mislearret

Dizze stap makket fan de dialooch in konkreet antwurd. Besjoch de resolver-interface yn ien terminal en it sjoernaal yn in oare, en ferbyn dan opnij:

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

Trije oproppen soene ferskine moatte: SetLinkDNS, SetLinkDomains en SetLinkDefaultRoute. De iene dy't as flaterantwurd weromkomt, is de iene om te reparearjen. Dat antwurd neamt meast syn reden, bygelyks org.freedesktop.DBus.Error.AccessDenied tsjin SetLinkDomains. Skriuw op hokker oprop it wie, want de folgjende seksje giet oer it trochlitten fan dy oprop.

Jou de klant de polkit-aksjes dy't er nedich hat

Lês it belied foardat jo in regel skriuwe. In klant dy't as tsjinst draait, kin gjin ynteraktive fraach beantwurdzje, dus in ymplisite auth_admin_keep is in dea ein.

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

As it antwurd auth_admin_keep is, hat de klant in eksplisite regel nedich. It fragmint hjirûnder lit de fjouwer resolve1-aksjes troch dy't in VPN-klant by in ferbining brûkt, en lit al it oare 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;
});

Set it yn /etc/polkit-1/rules.d/ as in bestân dat jo letter wer weromkenne, bygelyks 50-azurevpn.rules, en ferfang de groepsnamme yn it fragmint troch jo eigen foardat jo út- en wer ynlogge. Hâld it smel, want elke resolve1-aksje foar elk akkount tastean is breder as dizze klant nedich hat en folle dreger om letter te auditsjen.

Kontrolearje de profyl-XML foardat jo polkit bewurkje

In mei de hân bewurke profyl kin sûnder in wurd negearre wurde. Microsoft dokumintearret in flakke yndieling wêryn dnsserver-ynfieringen direkt yn dnsservers steane en efterheaksels yn dnssuffixes. In ekstra wrapper-elemint om elk adres is net dy foarm, en de klant falt stil werom op wat de gateway triuwt.

Doch de fuortheltest foardat jo polkit oanreitsje. Helje it efterheakselblok fuort, ferbyn opnij en sjoch oft de dialooch feroaret. Docht er dat, dan wie de mislearre oprop de domein-oerjefte, en de oplossing is autorisaasje en net noch in XML-bewurking.

Ferifiearje it domein op 'e tunnelkeppeling

Ferbyn opnij en lês resolvectl status wer, en kontrolearje dat de tunnelkeppeling de namme-tsjinner en it sykdomein tegearre draacht. Los in koarte priveenamme op ynstee fan in iepenbiere. As de namme oplost mar de tsjinst derachter antwurdet net, dan hat de DNS-oerjefte wurke en is it oerbleaune probleem routing.

Skriuw de resolver-eigner, de mislearre D-Bus-oprop, it regelbestân en de profylferzje yn 'e ticket. Dy fjouwer rigels meitsje de folgjende Linux-laptop in koarte oplossing ynstee fan in werhelle ûndersyk.

Relatearre artikelen