Azure VPN Client pada Linux: domain DNS tidak dapat ditetapkan

Terowong naik, sijil disahkan, dan kemudian dialog berkata pelayan DNS atau domain tidak dapat ditetapkan. Pada Linux dialog itu biasanya bukan tentang gateway: klien menyerahkan konfigurasi nama kepada systemd-resolved melalui D-Bus, dan penyerahan yang ditolak membiarkan antara muka kekal naik dengan resolusi masih menunjuk ke pautan lama. Komputer riba yang sama menyelesaikan nama dengan baik sebelum profil mendapat akhiran, dan itulah petunjuk yang wajar diikuti. Tiada apa-apa pada terowong berubah pada saat dialog muncul.

Tanpa akhiran klien hanya menolak pelayan nama. Tambah domain carian dan panggilan kedua menyertainya, SetLinkDomains, dengan pemeriksaan kebenarannya sendiri, sebab itu profil yang sama berfungsi pada Windows dan gagal di sini. Gateway menolak tetapan yang sama dalam kedua-dua kes, dan komponen yang menolaknya adalah setempat.

Pastikan systemd-resolved ialah penyelesai

Klien ini bercakap dengan systemd-resolved sahaja dan dengan tiada yang lain. Arch dan beberapa edaran lain menghantarnya dalam keadaan dilumpuhkan, dan /etc/resolv.conf mungkin milik penyelesai lain sepenuhnya, jadi tetapkan pemiliknya sebelum melihat kebenaran.

Tiga arahan menyelesaikannya:

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

Anda mencari perkhidmatan aktif, pautan simbolik yang menunjuk ke /run/systemd/resolve/stub-resolv.conf, dan DNS setiap pautan dalam resolvectl. Apabila NetworkManager memegang pemilikan, pindahkannya ke resolved daripada bergaduh dengan klien; fail drop-in di bawah menetapkan kedua-dua kunci:

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

Mulakan semula NetworkManager sebaik sahaja fail itu wujud. Penyelesai tidak aktif bersama klien yang terus memanggil nama D-Busnya menghasilkan ralat yang tidak menamakan mana-mana satu daripadanya.

Perhatikan panggilan D-Bus yang gagal

Langkah ini menukar dialog kepada jawapan yang khusus. Perhatikan antara muka penyelesai dalam satu terminal dan jurnal dalam yang lain, kemudian sambung semula:

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

Tiga panggilan sepatutnya muncul: SetLinkDNS, SetLinkDomains dan SetLinkDefaultRoute. Yang kembali sebagai balasan ralat itulah yang perlu dibetulkan. Balasan itu biasanya menyebut sebabnya, contohnya org.freedesktop.DBus.Error.AccessDenied berbanding SetLinkDomains. Catat panggilan mana yang berlaku, kerana bahagian seterusnya ialah tentang membenarkan panggilan itu melalui.

Berikan tindakan polkit yang diperlukan klien

Baca dasar sebelum menulis peraturan. Klien yang berjalan sebagai perkhidmatan tidak boleh menjawab gesaan interaktif, jadi auth_admin_keep tersirat ialah jalan buntu.

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

Jika jawapannya auth_admin_keep, klien memerlukan peraturan eksplisit. Coretan di bawah membenarkan empat tindakan resolve1 yang digunakan klien VPN semasa sambungan dan membiarkan segala-galanya pada 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;
});

Letakkan di /etc/polkit-1/rules.d/ sebagai fail yang akan anda kenal kemudian, contohnya 50-azurevpn.rules, dan gantikan nama kumpulan dalam coretan dengan nama anda sebelum log keluar dan masuk semula. Kekalkan ia sempit, kerana membenarkan setiap tindakan resolve1 untuk setiap akaun lebih luas daripada yang diperlukan klien ini dan jauh lebih sukar untuk diaudit kemudian.

Semak XML profil sebelum mengedit polkit

Profil yang diedit dengan tangan boleh diabaikan tanpa sepatah kata. Microsoft mendokumenkan susun atur rata yang di dalamnya entri dnsserver terletak terus dalam dnsservers, dan akhiran dalam dnssuffixes. Elemen pembalut tambahan di sekeliling setiap alamat bukan bentuk itu, dan klien senyap kembali kepada apa sahaja yang ditolak gateway.

Lakukan ujian penyingkiran sebelum menyentuh polkit. Tanggalkan blok akhiran, sambung semula dan lihat sama ada dialog berubah. Jika berubah, panggilan yang gagal itu ialah penyerahan domain, dan pembetulannya ialah kebenaran, bukan suntingan XML yang lain.

Sahkan domain pada pautan terowong

Sambung semula dan baca resolvectl status sekali lagi, memeriksa bahawa pautan terowong membawa pelayan nama dan domain carian bersama-sama. Selesaikan nama peribadi yang pendek dan bukan nama awam. Apabila nama diselesaikan tetapi perkhidmatan di belakangnya tidak menjawab, penyerahan DNS berjaya dan masalah yang tinggal ialah penghalaan.

Tulis pemilik penyelesai, panggilan D-Bus yang gagal, fail peraturan dan versi profil ke dalam tiket. Empat baris itu menjadikan komputer riba Linux seterusnya pembetulan pendek dan bukan penyiasatan berulang.