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 ल्यापटपलाई फेरि जाँचको सट्टा छोटो सुधार बनाउँछ।