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 कंटेनरमधील संपादन पुनर्निर्माणात नाहीसे होते आणि दुरुस्ती काम करत नसतानाही ती झाली असे तुम्हाला पटवते।

सामायिक नेटवर्क व्याख्येजवळ रिझॉल्व्हरचा मालक आणि अपेक्षित नेमस्पेस नोंदवा। पुढील व्यक्तीला दोन्ही लागतील।