Docker कन्टेनरहरूले VPN को DNS रिजोल्भरलाई किन बेवास्ता गर्छन्

VPN सक्रिय छ, ब्राउजर आन्तरिक साइटहरूमा पुग्छ, तर कन्टेनरले अझै ती नै नामहरू समाधान गर्न सक्दैन। प्याकेज स्थापना EAI_AGAIN जस्तो नाम-समाधान त्रुटिले मर्छ, वा कुनै एप्लिकेसनले होस्ट मेसिनले कुनै गुनासो बिना समाधान गर्ने डाटाबेस होस्ट भेट्टाउँदैन। कन्टेनरले VPN ले स्थापना गरेको रिजोल्भर प्रयोग गर्दैन। कन्टेनर बनाइँदा Docker ले होस्टको रिजोल्भर कन्फिगरेसन प्रतिलिपि गर्‍यो, र त्यसपछि कसैले यसलाई फेरि प्रतिलिपि गरेन।

एउटै मेसिनमा रिजोल्भरका दुई दृश्य

Linux मा, Docker ले बनाउँदा प्रत्येक कन्टेनरलाई होस्टको रिजोल्भर कन्फिगरेसन को प्रतिलिपि दिन्छ, लुपब्याक ठेगानाहरू फिल्टर गर्छ, र 127.0.0.11 मा एम्बेडेड DNS सर्भर चलाउँछ जसले क्वेरीहरू बाहिर पठाउँछ। कन्टेनर सुरु भएपछि /etc/resolv.conf पुनःलेखन गर्ने VPN क्लाइन्टले यसको भित्र केही पनि बदल्दैन। त्यो क्षणमा होस्ट रिजोल्भर संयोगवश सही भएमा मात्र कन्टेनर पुनःसुरु गर्नाले मद्दत गर्छ।

macOS वा Windows मा Docker Desktop ले एउटा तह थप्छ, किनकि डेमन भर्चुअल मेसिनमा बस्छ। होस्टको VPN रिजोल्भर त्यो VM का लागि कहिल्यै नदेखिन सक्छ, त्यसैले पुनःसुरु गर्नाले केही पनि बदल्दैन। उपाय छान्नुअघि दुई दृश्यको तुलना गर्नुहोस्: होस्टको रिजोल्भर सूचीको छेउमा docker exec mycontainer cat /etc/resolv.conf।

होस्टले आन्तरिक रिजोल्भर सूचीबद्ध गर्दा कन्टेनरले सार्वजनिक रिजोल्भर सूचीबद्ध गर्छ भने त्यसले सार्वजनिक नामहरू समाधान गर्छ र आन्तरिक नामहरूमा असफल हुन्छ। यही विभाजन यो समस्याको हस्ताक्षर हो।

विकल्प A: प्रत्येक कन्टेनरका लागि टनेल रिजोल्भर पठाउने

Docker ले प्रति-कन्टेनर DNS सेटिङ स्वीकार्छ, र यो काम गर्ने सबैभन्दा सानो परिवर्तन हो। पहिले VPN को रिजोल्भर ठेगानाहरू पढ्नुहोस्: macOS मा scutil --dns, Linux मा resolvectl status वा क्लाइन्टको आफ्नै स्थिति आउटपुट। त्यसपछि तिनीहरूसँग कन्टेनर सुरु गर्नुहोस्, उदाहरणका लागि docker run --dns 192.168.2.1 --dns 192.168.123.1 myimage। Compose मा त्यही सेटिङ सेवाअन्तर्गतको सूची हो, जहाँ यो कसैको शेल इतिहासको सट्टा संस्करण नियन्त्रणमा रहन्छ।

/etc/docker/daemon.json मा dns एरे हरेक नयाँ कन्टेनरमा लागू हुन्छ, जुन बढी मिलेको सुनिन्छ तर होइन। टनेल बन्द हुँदा पनि यो लागू हुन्छ, र त्यतिबेला केवल VPN बाट पुग्न सकिने रिजोल्भरले सामान्य इमेज तान्ने काम बिगार्छ। प्रति-कन्टेनर सेटिङ व्याख्या गर्न पनि सजिलो र फिर्ता लिन पनि सजिलो हुन्छ।

विकल्प B: कन्टेनरले होस्ट नेटवर्क साझा गरोस्

होस्ट नेटवर्किङले प्रतिलिपिलाई पूर्ण रूपमा बाइपास गर्छ, किनकि कन्टेनरले होस्टको रिजोल्भर र होस्टको टनेल प्रयोग गर्छ। यसले तपाईंले चाहेको नेटवर्क अलगाव पनि हटाउँछ, र Docker Desktop अन्तर्गत यो उस्तै व्यवहार गर्दैन। Linux मा आन्तरिक नामहरू समाधान गर्नुपर्ने एक-पटकको औजारका लागि यो व्यावहारिक छनोट हो।

बिल्डका लागि दुवैमध्ये कुनै विकल्प लागू हुँदैन, किनकि बिल्ड चरणहरूले रनटाइम फ्ल्याग उत्तराधिकारमा पाउँदैनन्। प्लेटफर्मले अनुमति दिने ठाउँमा होस्ट नेटवर्किङसँग बिल्ड गर्नुहोस्, वा निर्भरता स्थापनालाई टनेल आवश्यक नपर्ने चरणमा राख्नुहोस्।

दुवै विकल्पले नसुधार्ने कुरा

कन्टेनरसँग त्यहाँसम्म मार्ग नभए DNS ठेगाना बेकार हुन्छ। VPN रिजोल्भर सामान्यतया टनेलको ठेगाना क्षेत्रभित्र बस्छ, त्यसैले कन्टेनरलाई त्यो प्रिफिक्ससम्म बाटो चाहिन्छ। Docker को पूर्वनिर्धारित ब्रिज सामान्यतया होस्टमार्फत बाहिर रुट गर्छ, र होस्टसँग टनेल मार्ग भए र फर्वार्डिङ सक्रिय भए त्यो पर्याप्त हुन्छ। आफ्नै ठेगाना पूल भएका अनुकूलन ब्रिज नेटवर्कहरू VPN सबनेटसँग ठोक्किन सक्छन्, र त्यतिबेला क्वेरीहरू पूर्ण रूपमा अर्कै ठाउँमा जान्छन्।

रिजोल्भर आफैलाई डिबग गर्नुअघि Docker नेटवर्कको सबनेटलाई VPN सबनेटसँग जाँच्नुहोस्। ओभरल्यापले ठ्याक्कै बिग्रेको DNS सर्भरजस्तै देखिने असफलता उत्पन्न गर्छ।

कन्टेनरभित्र प्रमाणित गर्नुहोस्

ब्राउजर वा भाषा रनटाइमको सट्टा कन्टेनरभित्र getent hosts db.internal प्रयोग गरी परीक्षण गर्नुहोस्, किनकि तिनले आफ्नै DNS नीति र आफ्नै क्यासिङ लागू गर्छन्। यदि getent ले नाम समाधान गर्छ र एप्लिकेसन अझै असफल हुन्छ भने रिजोल्भर अब सही छ र बाँकी समस्या एप्लिकेसन तहको हो। यदि यसले समाधान गर्दैन भने DNS चरण सकिएको छैन।

DNS सेटिङ बदलेपछि कन्टेनर पुनः बनाउनुहोस्। चलिरहेको कन्टेनरभित्र /etc/resolv.conf सम्पादन गर्नु त्यसैसँग हराउँछ र कन्फिगरेसन समस्यालाई कसैले यसलाई पुनःसुरु गर्न लाग्ने ठ्याक्कै त्यति समय लुकाउँछ।