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 लैपटॉप को दोबारा जाँच के बजाय छोटा सुधार बना देती हैं।