Azure VPN Client sa Linux: hindi maitakda ang mga domain ng DNS
Bumangon ang tunnel at pagkatapos ay hindi maitakda ng Linux client ang mga domain ng DNS. Suriin ang systemd-resolved, bantayan ang tawag sa D-Bus at ayusin ang aksyon ng polkit.
Bumangon ang tunnel, naberipika ang sertipiko, at pagkatapos ay may dialog na nagsasabing hindi maitakda ang DNS server o mga domain. Sa Linux, ang dialog na iyon ay karaniwang hindi tungkol sa gateway: ipinapasa ng client ang configuration ng pangalan sa systemd-resolved sa pamamagitan ng D-Bus, at ang tinanggihang pagpasa ay nag-iiwan sa interface na nakataas na may resolution na nakaturo pa rin sa lumang link. Ang parehong laptop ay maayos na nagre-resolve ng mga pangalan bago magkaroon ng suffix ang profile, at iyon ang bakas na dapat sundan. Walang nagbago sa tunnel sa sandaling lumitaw ang dialog.
Kung walang suffix, ang client ay nagtutulak lamang ng mga name server. Magdagdag ng search domain at may pangalawang tawag na sasama rito, SetLinkDomains, na may sariling pagsusuri ng awtorisasyon, kaya gumagana ang parehong profile sa Windows at nabigo rito. Itinutulak ng gateway ang parehong mga setting sa dalawang pagkakataon, at ang bahaging tumatanggi ay lokal.
Kumpirmahin na ang systemd-resolved ang resolver
Ang client na ito ay nakikipag-usap lamang sa systemd-resolved at wala nang iba. Inihatid ito ng Arch at ilang iba pang distribusyon na naka-disable, at /etc/resolv.conf ay maaaring pag-aari ng ganap na ibang resolver, kaya tukuyin ang may-ari bago tingnan ang mga pahintulot.
Tatlong utos ang naglilinaw nito:
systemctl status systemd-resolved
ls -l /etc/resolv.conf
resolvectl status
Naghahanap ka ng aktibong serbisyo, symbolic link na nakaturo sa /run/systemd/resolve/stub-resolv.conf, at DNS bawat link sa resolvectl. Kapag ang NetworkManager ang may pagmamay-ari, ilipat ito sa resolved sa halip na makipag-away sa client; ang drop-in sa ibaba ay nagtatakda ng parehong susi:
[main]
dns=systemd-resolved
systemd-resolved=true
I-restart ang NetworkManager kapag umiiral ang file na iyon. Ang hindi aktibong resolver kasama ng client na patuloy na tumatawag sa pangalan nitong D-Bus ay gumagawa ng error na hindi pinangalanan ang alinman sa kanila.
Bantayan ang tawag sa D-Bus na nabibigo
Binabago ng hakbang na ito ang dialog tungo sa tiyak na sagot. Bantayan ang interface ng resolver sa isang terminal at ang journal sa isa pa, pagkatapos ay kumonekta muli:
sudo dbus-monitor --system "interface='org.freedesktop.resolve1.Manager'"
journalctl -fu systemd-resolved
Dapat lumitaw ang tatlong tawag: SetLinkDNS, SetLinkDomains at SetLinkDefaultRoute. Ang bumabalik bilang sagot na error ang dapat ayusin. Karaniwang sinasabi ng sagot na iyon ang dahilan, halimbawa org.freedesktop.DBus.Error.AccessDenied laban sa SetLinkDomains. Itala kung aling tawag iyon, dahil ang susunod na bahagi ay tungkol sa pagpapadaan sa tawag na iyon.
Ibigay sa client ang mga aksyon ng polkit na kailangan nito
Basahin ang patakaran bago magsulat ng panuntunan. Ang client na tumatakbo bilang serbisyo ay hindi makasagot sa interactive na prompt, kaya ang auth_admin_keep na implicit ay isang dead end.
pkaction --verbose --action-id org.freedesktop.resolve1.set-domains
pkaction --action-id org.freedesktop.resolve1.set-dns-servers --verbose
Kung ang sagot ay auth_admin_keep, kailangan ng client ang malinaw na panuntunan. Pinapayagan ng snippet sa ibaba ang apat na aksyon ng resolve1 na ginagamit ng VPN client habang nakakonekta at iniiwan ang lahat ng iba pa sa 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;
});
Ilagay ito sa /etc/polkit-1/rules.d/ bilang file na makikilala mo mamaya, halimbawa 50-azurevpn.rules, at palitan ang pangalan ng grupo sa snippet ng sa iyo bago mag-log out at mag-log in muli. Panatilihin itong makitid, dahil ang pagpayag sa bawat aksyon ng resolve1 para sa bawat account ay mas malawak kaysa kailangan ng client na ito at mas mahirap i-audit mamaya.
Suriin ang XML ng profile bago i-edit ang polkit
Ang profile na inedit sa kamay ay maaaring balewalain nang walang salita. Ang Microsoft ay nagdodokumento ng flat na layout kung saan ang mga entry na dnsserver ay direktang nasa loob ng dnsservers, at ang mga suffix sa loob ng dnssuffixes. Ang dagdag na wrapper element sa paligid ng bawat address ay hindi ang hugis na iyon, at tahimik na bumabalik ang client sa kung ano ang itinutulak ng gateway.
Gawin ang pagsubok sa pag-alis bago hawakan ang polkit. Alisin ang bloke ng suffix, kumonekta muli at tingnan kung nagbabago ang dialog. Kung nagbabago, ang nabigong tawag ay ang pagpasa ng domain, at ang pagwawasto ay awtorisasyon hindi isa pang pag-edit ng XML.
Beripikahin ang domain sa link ng tunnel
Kumonekta muli at basahin resolvectl status muli, tinitingnan na dinadala ng link ng tunnel ang name server at ang search domain nang magkasama. I-resolve ang maikling pribadong pangalan sa halip na pampubliko. Kapag nag-resolve ang pangalan ngunit hindi sumasagot ang serbisyo sa likod nito, gumana ang pagpasa ng DNS at ang natitirang problema ay routing.
Isulat sa ticket ang may-ari ng resolver, ang nabigong tawag sa D-Bus, ang file ng panuntunan at ang bersyon ng profile. Ang apat na linyang iyon ay ginagawang maikling pagwawasto ang susunod na Linux laptop sa halip na paulit-ulit na imbestigasyon.