Linux پر Azure VPN Client: DNS ڈومینز سیٹ نہیں ہو سکے

ٹنل اوپر آتا ہے، سرٹیفکیٹ کی توثیق ہوتی ہے اور پھر ایک ڈائیلاگ کہتا ہے کہ DNS سرور یا ڈومینز سیٹ نہیں ہو سکے۔ Linux پر یہ ڈائیلاگ عام طور پر گیٹ وے کے بارے میں نہیں ہوتا: کلائنٹ نام کی کنفیگریشن D-Bus کے ذریعے systemd-resolved کو سونپتا ہے، اور مسترد شدہ حوالگی انٹرفیس کو اوپر ہی رہنے دیتی ہے، حل اب بھی پرانے لنک کی طرف اشارہ کر رہا ہے. وہی لیپ ٹاپ پروفائل کو سافکس ملنے سے پہلے ناموں کو ٹھیک طرح حل کرتا ہے، اور یہی وہ سراغ ہے جس کی پیروی کرنی چاہیے۔ ڈائیلاگ نمودار ہونے کے لمحے ٹنل میں کچھ نہیں بدلا تھا۔

سافکس کے بغیر کلائنٹ صرف نام سرورز بھیجتا ہے۔ تلاش کا ڈومین شامل کریں اور دوسری کال اس میں شامل ہو جاتی ہے، 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 کی طرف اشارہ کرنے والا سمبولک لنک، اور resolvectl میں فی لنک DNS تلاش کر رہے ہیں۔ جب ملکیت 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 ہے، تو کلائنٹ کو واضح قاعدہ درکار ہے۔ نیچے دیا گیا اسنیپٹ VPN کلائنٹ کے کنکشن کے دوران استعمال ہونے والی چار resolve1 کارروائیوں کی اجازت دیتا ہے اور باقی سب کچھ 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 چیک کریں

ہاتھ سے ترمیم شدہ پروفائل ایک لفظ کہے بغیر نظر انداز کیا جا سکتا ہے۔ Microsoft ہموار ترتیب کی دستاویز کرتا ہے جس میں dnsserver اندراج براہ راست dnsservers کے اندر ہوتے ہیں اور سافکس dnssuffixes کے اندر۔ ہر پتے کے گرد اضافی ریپر عنصر وہ شکل نہیں ہے، اور کلائنٹ خاموشی سے اسی طرف لوٹ جاتا ہے جو گیٹ وے بھیجتا ہے۔

polkit کو چھونے سے پہلے ہٹانے کا امتحان کریں۔ سافکس بلاک ہٹائیں، دوبارہ منسلک ہوں اور دیکھیں کہ ڈائیلاگ بدلتا ہے یا نہیں۔ اگر بدلتا ہے، تو ناکام کال ڈومین کی حوالگی تھی، اور حل اجازت ہے، کوئی اور XML ترمیم نہیں۔

ٹنل لنک پر ڈومین کی تصدیق کریں

دوبارہ منسلک ہوں اور resolvectl status دوبارہ پڑھیں، جانچیں کہ ٹنل لنک نام سرور اور تلاش کا ڈومین ایک ساتھ رکھتا ہے۔ عوامی نام کے بجائے چھوٹا نجی نام حل کریں۔ جب نام حل ہو جائے مگر اس کے پیچھے کی سروس جواب نہ دے، تو DNS حوالگی کام کر گئی اور باقی مسئلہ روٹنگ ہے۔

ٹکٹ میں حل کنندہ کا مالک، ناکام D-Bus کال، قاعدے کی فائل اور پروفائل کا ورژن لکھیں۔ وہ چار سطریں اگلے Linux لیپ ٹاپ کو دوبارہ تفتیش کے بجائے چھوٹی درستی بنا دیتی ہیں۔