VPN कंटेनर का नेटवर्क साझा करना: DNS के साथ क्या होता है

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

चरण 1: होस्ट से नहीं, ऐप से परीक्षण करें

जिस कंटेनर में समस्या है उसके अंदर लुकअप चलाएँ, होस्ट पर नहीं और ब्राउज़र में नहीं। docker exec app-container getent hosts db.internal एकमात्र महत्वपूर्ण सवाल का जवाब देता है: इस प्रक्रिया का रिज़ॉल्वर क्या लौटाता है।

अगर होस्ट नाम हल करता है और कंटेनर नहीं, तो आपको खराबी मिल गई है। इसके बाद सब कुछ इसे ठीक करने का समर्थित तरीका चुनना है।

चरण 2: रनटाइम का समर्थित मॉडल पढ़ें

Docker का नेटवर्क दस्तावेज़ उन कंटेनरों के लिए DNS फ़्लैग पर प्रतिबंध दर्ज करता है जो किसी दूसरे कंटेनर का नेटवर्क मोड साझा करते हैं। Compose में network_mode: service:vpn ऐप को VPN कंटेनर के नेमस्पेस से बाँधता है, और प्रति-सेवा dns सेटिंग्स सामान्य सेवा की तरह व्यवहार नहीं करतीं। जो समाधान आपको मिलता है वही साझा नेमस्पेस के पास है।

उपयोगकर्ता-परिभाषित ब्रिज नेटवर्क भी Docker के अंतर्निहित DNS को डिफ़ॉल्ट ब्रिज से अलग तरह से उपयोग करते हैं। इसीलिए dns काम करने वाले ब्रिज उदाहरण से कॉपी किया गया कोई खंड साझा स्टैक में कुछ भी नहीं कर सकता। खंड कॉपी करने से पहले व्यवस्था जाँचें।

लूपबैक पता हमेशा संबंधित नेटवर्क संदर्भ को दर्शाता है। साझा नेमस्पेस के अंदर, 127.0.0.1 होस्ट का रिज़ॉल्वर नहीं है।

चरण 3: क्वेरी को उसके प्राप्तकर्ता तक ले जाएँ

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

ब्राउज़र का IP-जाँच पृष्ठ आपको नहीं बता सकता कि नाम क्वेरी कहाँ गईं। यह बताता है कि एक HTTP कनेक्शन कहाँ गया।

चरण 4: दो विफलता श्रेणियों को अलग-अलग ठीक करें

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

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

चरण 5: पुनर्निर्माण के बाद फिर से परीक्षण करें

रनटाइम की समर्थित व्यवस्था से कॉन्फ़िगरेशन बदलें, फिर चल रहे कंटेनर के अंदर फ़ाइलें संपादित करने के बजाय कंटेनर फिर से बनाएँ। एक नया निजी नाम, एक नया सार्वजनिक नाम और लुकअप के बाद आने वाला एप्लिकेशन अनुरोध परीक्षण करें। /etc/resolv.conf कंटेनर के अंदर का संपादन पुनर्निर्माण पर मिट जाता है और आपको यकीन दिलाएगा कि मरम्मत काम कर गई जबकि उसने नहीं की।

साझा नेटवर्क परिभाषा के पास रिज़ॉल्वर का स्वामी और अपेक्षित नेमस्पेस दर्ज करें। अगले व्यक्ति को दोनों की ज़रूरत होगी।