عميل Azure VPN على Linux: تعذّر تعيين نطاقات DNS

يرتفع النفق ويُتحقق من الشهادة، ثم تظهر نافذة تقول إنه تعذّر تعيين خادم DNS أو النطاقات. على Linux لا تتعلق هذه النافذة عادةً بالبوابة: فالعميل يسلّم إعداد الأسماء إلى systemd-resolved عبر D-Bus، ورفض التسليم يترك الواجهة قائمة مع تحليل ما يزال يشير إلى الوصلة القديمة. الحاسوب نفسه يحلّ الأسماء جيدًا قبل أن يكتسب الملف الشخصي لاحقة، وهذا هو الدليل الجدير بالمتابعة. لم يتغير شيء في النفق لحظة ظهور النافذة.

بدون لاحقة، لا يدفع العميل سوى خوادم الأسماء. أضف نطاق بحث وسينضم إليه استدعاء ثانٍ، SetLinkDomains، بفحص تصريح خاص به، ولهذا يتصرف الملف الشخصي نفسه على Windows بينما يفشل هنا. البوابة تدفع الإعدادات نفسها في كلتا الحالتين، والمكوّن الذي يرفضها محلي.

تأكيد أن systemd-resolved هو المتحكّم في التحليل

هذا العميل يتحدث إلى systemd-resolved ولا شيء غيره. توزّع Arch وتوزيعات أخرى عدة خدماتها معطّلة، و/etc/resolv.conf قد ينتمي إلى متحكّم تحليل آخر تمامًا، لذا حدّد المالك قبل أن تنظر في الأذونات.

ثلاثة أوامر تحسم الأمر:

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

أنت تبحث عن خدمة نشطة، ورابط رمزي موجّه إلى /run/systemd/resolve/stub-resolv.conf، وعن DNS لكل وصلة في resolvectl. عندما يملك NetworkManager الملكية بدلًا من ذلك، انقلها إلى resolved بدل مجاراة العميل؛ وملف الإدراج أدناه يضبط المفتاحين:

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

أعد تشغيل NetworkManager بمجرد وجود ذلك الملف. متحكّم تحليل غير نشط مع عميل يواصل استدعاء اسمه في D-Bus ينتج خطأً لا يذكر أيًّا منهما.

راقب استدعاء D-Bus الذي يفشل

هذه الخطوة تحوّل النافذة إلى إجابة محددة. راقب واجهة التحليل في طرفية وراقب السجل في أخرى، ثم أعد الاتصال:

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

ينبغي أن تظهر ثلاثة استدعاءات: SetLinkDNS، SetLinkDomains وSetLinkDefaultRoute. الذي يعود كردّ خطأ هو الذي يجب إصلاحه. ذلك الرد يذكر سببه عادةً، مثل org.freedesktop.DBus.Error.AccessDenied مقابل SetLinkDomains. دوّن أي استدعاء كان، لأن القسم التالي يتناول السماح بمرور ذلك الاستدعاء.

امنح إجراءات polkit التي يحتاجها العميل

اقرأ السياسة قبل كتابة قاعدة. العميل الذي يعمل كخدمة لا يستطيع الإجابة على مطالبة تفاعلية، لذا فإن auth_admin_keep الضمني طريق مسدود.

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

إذا كانت الإجابة auth_admin_keep، فإن العميل يحتاج قاعدة صريحة. المقتطف أدناه يسمح بإجراءات resolve1 الأربعة التي يستخدمها عميل VPN أثناء الاتصال ويترك كل شيء آخر عند 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;
});

ضعه في /etc/polkit-1/rules.d/ كملف ستعرفه لاحقًا، مثل 50-azurevpn.rules، واستبدل اسم المجموعة في المقتطف باسمك قبل تسجيل الخروج والدخول من جديد. أبقِه ضيقًا، لأن السماح بكل إجراء resolve1 لكل حساب أوسع مما يحتاجه هذا العميل وأصعب بكثير في التدقيق لاحقًا.

افحص ملف XML الشخصي قبل تعديل polkit

قد يُتجاهل ملف شخصي عُدّل يدويًا دون كلمة. توثّق Microsoft تخطيطًا مسطّحًا توضع فيه مدخلات dnsserver مباشرة داخل dnsservers واللواحق داخل dnssuffixes. عنصر تغليف إضافي حول كل عنوان ليس بهذا الشكل، ويعود العميل بصمت إلى ما تدفعه البوابة.

نفّذ اختبار الإزالة قبل لمس polkit. أزل كتلة اللاحقة، وأعد الاتصال، وراقب ما إذا كانت النافذة تتغير. إذا تغيّرت، فالاستدعاء الفاشل كان تسليم النطاق، والإصلاح تصريح لا تعديل XML آخر.

تحقق من النطاق على وصلة النفق

أعد الاتصال واقرأ resolvectl status مرة أخرى، وتأكد من أن وصلة النفق تحمل خادم الأسماء ونطاق البحث معًا. حلّ اسمًا خاصًا قصيرًا بدلًا من اسم عام. عندما يُحلّ الاسم لكن الخدمة خلفه لا تستجيب، يكون تسليم DNS قد نجح والمشكلة المتبقية هي التوجيه.

اكتب في التذكرة مالك التحليل، واستدعاء D-Bus الذي فشل، وملف القاعدة، وإصدار الملف الشخصي. تلك الأسطر الأربعة تجعل حاسوب Linux التالي إصلاحًا قصيرًا بدلًا من تحقيق متكرر.