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, আর প্রতি-লিংক 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 হয়, তাহলে ক্লায়েন্টের স্পষ্ট নিয়ম দরকার। নিচের স্নিপেটটি 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 ল্যাপটপটিকে পুনরায় তদন্তের বদলে একটি ছোট সমাধানে পরিণত করে।