Azure VPN Client di Linux: domain DNS tidak dapat disetel

Tunel tersambung lalu klien Linux tidak dapat menyetel domain DNS. Periksa systemd-resolved, amati panggilan D-Bus, dan perbaiki aksi polkit.

Tunel tersambung, sertifikat tervalidasi, lalu sebuah dialog menyatakan server atau domain DNS tidak dapat disetel. Di Linux dialog itu biasanya bukan soal gateway: klien menyerahkan konfigurasi nama ke systemd-resolved lewat D-Bus, dan penyerahan yang ditolak membiarkan antarmuka tetap naik dengan resolusi yang masih menunjuk ke tautan lama. Laptop yang sama me-resolve nama dengan baik sebelum profil mendapat sufiks, dan itulah petunjuk yang layak diikuti. Tidak ada yang berubah pada tunel saat dialog muncul.

Tanpa sufiks klien hanya mendorong server nama. Tambahkan domain pencarian dan panggilan kedua bergabung dengannya, SetLinkDomains, dengan pemeriksaan otorisasinya sendiri, karena itu profil yang sama berfungsi di Windows dan gagal di sini. Gateway mendorong setelan yang sama dalam kedua kasus, dan komponen yang menolaknya bersifat lokal.

Pastikan systemd-resolved adalah resolvernya

Klien ini hanya berbicara dengan systemd-resolved dan tidak dengan yang lain. Arch dan beberapa distro lain mengirimkannya dalam keadaan nonaktif, dan /etc/resolv.conf bisa sepenuhnya milik resolver lain, jadi pastikan pemiliknya sebelum melihat izin.

Tiga perintah menjawabnya:

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

Anda mencari layanan aktif, tautan simbolik yang mengarah ke /run/systemd/resolve/stub-resolv.conf, dan DNS per tautan di resolvectl. Ketika NetworkManager yang memegang kepemilikan, pindahkan ke resolved alih-alih bertengkar dengan klien; drop-in di bawah menyetel kedua kunci:

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

Mulai ulang NetworkManager begitu berkas itu ada. Resolver yang nonaktif bersama klien yang terus memanggil nama D-Bus-nya menghasilkan galat yang tidak menyebut keduanya.

Amati panggilan D-Bus yang gagal

Langkah ini mengubah dialog menjadi jawaban yang spesifik. Amati antarmuka resolver di satu terminal dan jurnal di terminal lain, lalu sambungkan ulang:

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

Tiga panggilan seharusnya muncul: SetLinkDNS, SetLinkDomains dan SetLinkDefaultRoute. Panggilan yang kembali sebagai balasan galat itulah yang harus diperbaiki. Balasan itu biasanya menyebut alasannya, misalnya org.freedesktop.DBus.Error.AccessDenied terhadap SetLinkDomains. Catat panggilan mana yang terjadi, karena bagian berikutnya membahas cara meloloskannya.

Berikan aksi polkit yang dibutuhkan klien

Baca kebijakannya sebelum menulis aturan. Klien yang berjalan sebagai layanan tidak dapat menjawab permintaan interaktif, jadi auth_admin_keep implisit adalah jalan buntu.

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

Jika jawabannya auth_admin_keep, klien memerlukan aturan eksplisit. Cuplikan di bawah mengizinkan empat aksi resolve1 yang dipakai klien VPN selama koneksi dan membiarkan semua yang lain 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 berkas yang akan Anda kenali nanti, misalnya 50-azurevpn.rules, dan ganti nama grup dalam cuplikan dengan nama Anda sebelum keluar dan masuk lagi. Jaga agar tetap sempit, karena mengizinkan setiap aksi resolve1 untuk setiap akun lebih luas daripada kebutuhan klien ini dan jauh lebih sulit diaudit nanti.

Periksa XML profil sebelum menyunting polkit

Profil yang disunting dengan tangan bisa diabaikan tanpa sepatah kata. Microsoft mendokumentasikan tata letak datar yang di dalamnya entri dnsserver berada langsung di dalam dnsservers, dan sufiks di dalam dnssuffixes. Elemen pembungkus tambahan di sekitar setiap alamat bukan bentuk itu, dan klien diam-diam kembali ke apa pun yang didorong gateway.

Lakukan uji penghapusan sebelum menyentuh polkit. Lepaskan blok sufiks, sambungkan ulang, dan lihat apakah dialog berubah. Jika berubah, panggilan yang gagal adalah penyerahan domain, dan perbaikannya otorisasi, bukan suntingan XML lain.

Verifikasi domain pada tautan tunel

Sambungkan ulang dan baca resolvectl status lagi, pastikan tautan tunel membawa server nama dan domain pencarian bersamaan. Resolve nama privat yang pendek, bukan nama publik. Ketika nama ter-resolve tetapi layanan di belakangnya tidak menjawab, penyerahan DNS berhasil dan masalah yang tersisa adalah perutean.

Tulis pemilik resolver, panggilan D-Bus yang gagal, berkas aturan, dan versi profil ke tiket. Empat baris itu membuat laptop Linux berikutnya menjadi perbaikan singkat alih-alih penyelidikan berulang.

Artikel terkait