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 कन्टेनरभित्रको सम्पादन पुनर्निर्माणमा हराउँछ र मर्मत नभए पनि भएजस्तो तपाईंलाई विश्वास दिलाउँछ।

साझा नेटवर्क परिभाषाको छेउमा रिजोल्भरको मालिक र अपेक्षित नेमस्पेस लेख्नुहोस्। अर्को व्यक्तिलाई दुवै चाहिन्छ।