Linux'ta Azure VPN Client: DNS alan adları ayarlanamadı

Tünel açılıyor ve ardından Linux istemcisi DNS alan adlarını ayarlayamıyor. systemd-resolved'ı kontrol edin, D-Bus çağrısını izleyin ve polkit eylemini düzeltin.

Tünel açılıyor, sertifika doğrulanıyor ve ardından bir iletişim kutusu DNS sunucusunun veya alan adlarının ayarlanamadığını söylüyor. Linux'ta bu kutu genellikle ağ geçidiyle ilgili değildir: istemci ad yapılandırmasını D-Bus üzerinden systemd-resolved'a devreder ve reddedilen devir, arayüzü çözümleme hâlâ eski bağlantıyı gösterirken ayakta bırakır. Aynı dizüstü bilgisayar, profil bir sonek almadan önce adları sorunsuz çözer ve bu, izlenmeye değer ipucudur. İletişim kutusu göründüğü anda tünelde hiçbir şey değişmedi.

Sonek olmadan istemci yalnızca ad sunucularını iter. Bir arama alan adı ekleyin ve ona ikinci bir çağrı katılır, SetLinkDomains, kendi yetkilendirme denetimiyle, bu yüzden aynı profil Windows'ta çalışıp burada başarısız olur. Ağ geçidi her iki durumda da aynı ayarları iter ve bunları reddeden bileşen yereldir.

systemd-resolved'ın çözümleyici olduğunu doğrulayın

Bu istemci yalnızca systemd-resolved ile konuşur, başka kimseyle değil. Arch ve birkaç başka dağıtım onu devre dışı olarak gönderir ve /etc/resolv.conf tamamen başka bir çözümleyiciye ait olabilir, bu yüzden izinlere bakmadan önce sahibi belirleyin.

Üç komut bunu netleştirir:

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

Etkin bir hizmet, /run/systemd/resolve/stub-resolv.conf adresini gösteren sembolik bağlantı ve resolvectl içinde bağlantı başına DNS arıyorsunuz. Sahiplik bunun yerine NetworkManager'daysa, istemciyle kavga etmek yerine resolved'a taşıyın; aşağıdaki drop-in iki anahtarı da ayarlar:

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

O dosya var olduğunda NetworkManager'ı bir kez yeniden başlatın. Etkin olmayan bir çözümleyici ile D-Bus adını çağırmaya devam eden bir istemci birlikte, ikisinin de adını anmayan bir hata üretir.

Başarısız olan D-Bus çağrısını izleyin

Bu adım iletişim kutusunu somut bir yanıta dönüştürür. Bir terminalde çözümleyici arayüzünü, diğerinde günlüğü izleyin ve ardından yeniden bağlanın:

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

Üç çağrı görünmelidir: SetLinkDNS, SetLinkDomains ve SetLinkDefaultRoute. Hata yanıtı olarak dönen çağrı düzeltilmesi gerekendir. O yanıt genellikle nedenini söyler, örneğin org.freedesktop.DBus.Error.AccessDenied karşısında SetLinkDomains. Hangi çağrı olduğunu not edin, çünkü sonraki bölüm tam olarak o çağrının geçirilmesiyle ilgilidir.

İstemcinin ihtiyaç duyduğu polkit eylemlerini verin

Kural yazmadan önce ilkeyi okuyun. Hizmet olarak çalışan bir istemci etkileşimli bir istemi yanıtlayamaz, bu yüzden örtük bir auth_admin_keep çıkmaz sokaktır.

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

Yanıt auth_admin_keep ise, istemcinin açık bir kurala ihtiyacı vardır. Aşağıdaki parça bir VPN istemcisinin bağlantı sırasında kullandığı dört resolve1 eylemine izin verir ve diğer her şeyi polkit.Result.NOT_HANDLED düzeyinde bırakır:

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;
});

Onu /etc/polkit-1/rules.d/ içine daha sonra tanıyacağınız bir dosya olarak koyun, örneğin 50-azurevpn.rules, ve çıkıp yeniden giriş yapmadan önce parçadaki grup adını kendi adınızla değiştirin. Dar tutun, çünkü her hesap için her resolve1 eylemine izin vermek bu istemcinin ihtiyacından daha geniştir ve sonradan denetlemesi çok daha zordur.

polkit'i düzenlemeden önce profil XML'ini kontrol edin

Elle düzenlenmiş bir profil tek kelime edilmeden yok sayılabilir. Microsoft düz bir yerleşim belgeler, burada dnsserver girdileri doğrudan dnsservers içinde durur ve sonekler dnssuffixes içinde. Her adresin çevresinde ek bir sarmalayıcı öğe o biçim değildir ve istemci sessizce ağ geçidinin ittiği şeye geri döner.

polkit'e dokunmadan önce kaldırma testini yapın. Sonek bloğunu çıkarın, yeniden bağlanın ve iletişim kutusunun değişip değişmediğine bakın. Değişiyorsa, başarısız çağrı alan adı devriydi ve düzeltme başka bir XML düzenlemesi değil yetkilendirmedir.

Alan adını tünel bağlantısında doğrulayın

Yeniden bağlanın ve resolvectl status çıktısını tekrar okuyun, tünel bağlantısının ad sunucusunu ve arama alan adını birlikte taşıdığını kontrol edin. Genel bir ad yerine kısa bir özel ad çözün. Ad çözülüyor ama arkasındaki hizmet yanıt vermiyorsa DNS devri çalıştı ve kalan sorun yönlendirmedir.

Bilete çözümleyicinin sahibini, başarısız D-Bus çağrısını, kural dosyasını ve profil sürümünü yazın. O dört satır bir sonraki Linux dizüstü bilgisayarını tekrarlanan bir soruşturma yerine kısa bir düzeltmeye çevirir.

İlgili makaleler