कौन-सा लिंक जवाब देता है: स्प्लिट-टनल VPN DNS के लिए रूटिंग डोमेन

सामान्य ब्राउज़िंग स्थानीय लिंक पर रखें, जबकि कंपनी के नाम उस DNS सर्वर से हल हों जो टनल देता है। VPN का डिफ़ॉल्ट रूट बंद करने से पहला आधा मिलता है और दूसरा आधा अनबना रह जाता है। आगे वह छूटी सेटिंग, वह विरामचिह्न जो उसका अर्थ बदलता है, और वह अकेला कमांड है जो दिखाता है कि किस लिंक ने वास्तव में जवाब दिया। पूरे पाठ में NetworkManager और systemd-resolved माने गए हैं, क्योंकि उलझन आमतौर पर इसी जोड़ी से शुरू होती है।

पहला चरण: रूट को रिज़ॉल्वर से अलग करें

ipv4.never-default रूटिंग के सवाल का जवाब देता है और NetworkManager को इस कनेक्शन को सभी IPv4 ट्रैफ़िक का रास्ता बनाने से रोकता है। DNS रूटिंग डोमेन दूसरे सवाल का जवाब देता है: किस लिंक के नेम सर्वर को मिलते-जुलते सफ़िक्स के लिए क्वेरी मिलती है। कोई भी दूसरे को अनिवार्य नहीं करता, और प्रोफ़ाइल सालों तक एक रख सकती है जबकि दूसरा गायब हो। केवल-रूट का मतलब है कि टनल कंपनी के सबनेट ले जाता है और उसका रिज़ॉल्वर कंपनी के नामों का जवाब देता है, जबकि बाकी सब अछूता रहता है।

सिर्फ़ रूट प्रॉपर्टी सेट करें तो अंदरूनी नाम विफल होते हैं, आमतौर पर ऐसे टाइमआउट के साथ जो टूटी टनल जैसा लगता है। सिर्फ़ डोमेन सेट करें तो आपने चुपचाप मशीन के हर छोटे नाम में सर्च सफ़िक्स जोड़ दिया है। दोनों गलतियाँ टिकट को VPN सर्वर पर भेजती हैं, जो शायद ही कभी गलत हिस्सा होता है।

दूसरा चरण: प्रोफ़ाइल में केवल-रूटिंग डोमेन जोड़ें

मानें कि कनेक्शन का नाम corp-vpn है, कंपनी का सफ़िक्स internal.example है, और टनल का रिज़ॉल्वर पहले से पहुँच योग्य है। पहले मौजूदा मान पढ़ें, क्योंकि नीचे के कमांड ऐसी प्रॉपर्टी बदलते हैं जिनमें पहले से प्रविष्टियाँ हो सकती हैं।

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

अपना कनेक्शन नाम और सफ़िक्स डालें, क्योंकि ऊपर के मान उदाहरण हैं। प्लस चिह्न दिखने से ज़्यादा महत्वपूर्ण है: इसके साथ मान मौजूदा सूची में जुड़ता है, जबकि इसके बिना प्रॉपर्टी बदल जाती है और कल तक चलने वाली प्रोफ़ाइल से असंबंधित डोमेन गायब हो जाते हैं। टिल्ड व्यवहार बदलती है, शैली नहीं, और नीचे का पैराग्राफ़ बताता है कि वह क्या चुनती है। लिखने से पहले पढ़ना रखें, ताकि बदलाव का रूप आपको कभी चौंकाए नहीं।

शुरू में टिल्ड केवल-रूटिंग डोमेन चिह्नित करती है, इसलिए मिलती-जुलती क्वेरी इस लिंक के सर्वरों पर जाती हैं और सफ़िक्स छोटे नामों में नहीं जुड़ता। टिल्ड हटाएँ तो वही स्ट्रिंग सर्च सफ़िक्स भी बन जाती है, जो अलग परिणाम है और लोग शायद ही उसका इरादा करते हैं। ऊपर की दोनों सेटिंग IPv4 हैं, इसलिए दोहरे-स्टैक प्रोफ़ाइल को ipv6.never-default और ipv6.dns-search में वही रूटिंग डोमेन चाहिए, नहीं तो IPv6 पक्ष डिफ़ॉल्ट रूट इस्तेमाल करता रहता है और वहाँ अंदरूनी नाम विफल होते हैं।

तीसरा चरण: resolvectl से पूछें कि किस लिंक ने जवाब दिया

resolvectl status चलाएँ और हर लिंक के DNS सर्वर और डोमेन पढ़ें, फिर एक वास्तविक अंदरूनी नाम पर resolvectl query host.internal.example चलाएँ जिसे पूछने की आपको अनुमति है। दूसरा कमांड ही एकमात्र सीधा प्रमाण है कि रूटिंग डोमेन अपना काम कर रहा है, क्योंकि यह उस लिंक का नाम लेता है जिसने जवाब दिया। अकेली स्थिति-सूची कॉन्फ़िगरेशन साबित करती है; क्वेरी रिज़ॉल्यूशन साबित करती है।

systemd-resolved सबसे अच्छी तरह मेल खाने वाला रूटिंग डोमेन चुनता है, इसलिए दूसरे लिंक का ज़्यादा विशिष्ट डोमेन अब भी दौड़ जीत सकता है। अगर क्वेरी ऐसे लिंक से लौटे जिसकी आपको उम्मीद नहीं थी, तो VPN के DNS सर्वर को छूने से पहले डोमेन सूचियाँ पढ़ें। ~. रूट डोमेन सबसे मेल खाता है, और अगर वह पहले से मौजूद है तो आपका विशिष्ट डोमेन अपने नामों के लिए फिर भी जीतता है जबकि लिंक आपकी माँग से कहीं ज़्यादा का जवाब देता है। जब इरादा सिर्फ़ कंपनी के नाम था तो उस रूट प्रविष्टि को हटाएँ या सँकरा करें।

अगर VPN लिंक कोई DNS सर्वर ही नहीं गिनाता, तो क्लाइंट ने कभी कोई दर्ज नहीं किया। पीछे सर्वर के बिना रूटिंग डोमेन गायब डोमेन से अलग तरह से विफल होता है, इसलिए पहले पंजीकरण ठीक करें।

चौथा चरण: जब नाम हल हो पर सेवा नहीं

सही जवाब सिर्फ़ यह साबित करता है कि रिज़ॉल्यूशन चला, और ऐप्लिकेशन को अब भी मिले पते तक रूट चाहिए। उस रूट को अभी सेट किए गए विभाजित डिफ़ॉल्ट से बचना है, इसलिए DNS को फिर दोष देने से पहले उसे जाँचें। फिर सेवा के पोर्ट पर पहुँच जाँचें, क्योंकि फ़ाइल शेयर या डायरेक्टरी सेवा रिज़ॉल्यूशन, रूटिंग या प्रमाणीकरण पर विफल होती है और हर मामले में लगभग एक जैसे संदेश देती है। परिणाम बताते समय इन तीन परतों को अलग रखें, नहीं तो अगला व्यक्ति उस DNS को फिर जाँचता है जो पहले से सही था।

इस सवाल के साथ घूमने वाला Samba बदलाव पहुँच परत से जुड़ा है, DNS चुनाव से नहीं। नाम-रिज़ॉल्यूशन की खराबी पर उसे लगाना ही छोटी समस्या के दूसरी पाने का तरीका है।

पाँचवाँ चरण: गायब डोमेन ठीक करने के लिए रिज़ॉल्वर न बदलें

रिज़ॉल्वर फ़ाइल पर लिख देने या दूसरा रिज़ॉल्वर मैनेजर स्थापित करने की सलाह किसी और समस्या को हल करती है। ये सिस्टम-इंटीग्रेशन बदलाव हैं जिनके अपने विफलता तरीके हैं, और इनमें से कोई भी ऐसा रूटिंग डोमेन नहीं जोड़ता जो कभी सेट ही नहीं हुआ। बदलने से पहले तय करें कि मशीन पर नाम-रिज़ॉल्यूशन किस घटक का है, क्योंकि systemd-resolved वाले NetworkManager डेस्कटॉप पर वह स्वामित्व पहले से परिभाषित है। उससे लड़ना ही चलती हुई सेटअप को ऐसा बनाता है जिसे कोई दोबारा नहीं बना सकता।

काम का क्रम: पुष्टि करें कि टनल रिज़ॉल्वर देती है, केवल-रूटिंग डोमेन जोड़ें, प्रोफ़ाइल नियंत्रणों से दोबारा कनेक्ट करें, जवाब देने वाले लिंक को सत्यापित करें, और फिर सेवा को उसके पोर्ट पर जाँचें। यह क्रम ऐसा परिणाम छोड़ता है जिसे बिना दूसरे साक्षात्कार के अगले व्यक्ति को सौंपा जा सके।