Azure VPN Client در لینوکس: دامنه‌های DNS تنظیم نشد

تونل بالا می‌آید، گواهی اعتبارسنجی می‌شود و سپس پنجره‌ای می‌گوید کارساز DNS یا دامنه‌ها تنظیم نشدند. در لینوکس این پنجره معمولاً درباره دروازه نیست: کلاینت پیکربندی نام را از طریق D-Bus به systemd-resolved می‌سپارد و سپردن ردشده رابط را بالا نگه می‌دارد، در حالی که تفکیک نام هنوز به پیوند قدیمی اشاره می‌کند. همان لپ‌تاپ پیش از آنکه نمایه پسوند بگیرد نام‌ها را درست تفکیک می‌کند و این سرنخی است که ارزش پیگیری دارد. در لحظه ظاهر شدن پنجره هیچ چیز در تونل تغییر نکرده بود.

بدون پسوند کلاینت فقط کارسازهای نام را می‌فرستد. یک دامنه جست‌وجو اضافه کنید و فراخوانی دومی به آن می‌پیوندد، SetLinkDomains، با بررسی مجوز خودش، به همین دلیل همان نمایه در ویندوز کار می‌کند و اینجا شکست می‌خورد. دروازه در هر دو حالت همان تنظیمات را می‌فرستد و مؤلفه‌ای که آن‌ها را رد می‌کند محلی است.

تأیید کنید که 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 منتقل کنید نه اینکه با کلاینت بجنگید؛ فایل drop-in زیر هر دو کلید را تنظیم می‌کند:

[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 برای هر حساب گسترده‌تر از نیاز این کلاینت است و بعداً بازرسی آن بسیار سخت‌تر.

پیش از ویرایش polkit، XML نمایه را بررسی کنید

نمایه‌ای که با دست ویرایش شده ممکن است بی هیچ سخنی نادیده گرفته شود. مایکروسافت چیدمان تخت را مستند می‌کند که در آن ورودی‌های dnsserver مستقیماً درون dnsservers قرار می‌گیرند و پسوندها درون dnssuffixes. یک عنصر پوشش اضافی گرد هر نشانی آن شکل نیست و کلاینت بی‌صدا به آنچه دروازه می‌فرستد بازمی‌گردد.

پیش از دست زدن به polkit آزمون حذف را انجام دهید. بلوک پسوند را بردارید، دوباره وصل شوید و ببینید پنجره تغییر می‌کند یا نه. اگر تغییر کرد، فراخوانی شکست‌خورده همان سپردن دامنه بود و اصلاح، مجوز است نه ویرایش دیگری از XML.

دامنه را روی پیوند تونل بررسی کنید

دوباره وصل شوید و resolvectl status را باز بخوانید و بررسی کنید که پیوند تونل کارساز نام و دامنه جست‌وجو را با هم دارد. یک نام خصوصی کوتاه تفکیک کنید نه یک نام عمومی. وقتی نام تفکیک می‌شود اما سرویس پشت آن پاسخ نمی‌دهد، سپردن DNS کار کرده و مشکل باقی‌مانده مسیریابی است.

در تیکت مالک تفکیک‌کننده، فراخوانی D-Bus که شکست خورد، فایل قاعده و نسخه نمایه را بنویسید. آن چهار خط لپ‌تاپ لینوکس بعدی را از یک بررسی تکراری به اصلاحی کوتاه تبدیل می‌کند.