Docker की पूल ओवरलैप त्रुटि VPN रूट की समस्या नहीं है

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

दो त्रुटियाँ जो एक जैसी दिखती हैं

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

रनटाइम लक्षण पहुँच का प्रश्न है। कल जवाब देने वाला कंटेनर अब जवाब नहीं देता, और होस्ट की रूटिंग तालिका में कुछ बदल गया है। कंटेनर अब भी अपना पता रखता है; प्रश्न यह है कि वह पता कौन-सा रास्ता लेता है।

दोनों पता-योजना की समस्याएँ हैं। उनमें से केवल एक Docker की समस्या है।

पहले आवंटित पूल पढ़ें

नेटवर्क सूचीबद्ध करें और उन्हें जाँचें जो प्रतिच्छेद कर सकते हैं। सबनेट IPAM कॉन्फ़िगरेशन में रहता है, और जुड़े कंटेनर अलग से सूचीबद्ध होते हैं:

docker network ls
docker network inspect EXISTING_NETWORK

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

किसी सेवा पर स्थिर ipv4_address एक कंटेनर का पता है, पूल की परिभाषा नहीं। उसे बदलने से ओवरलैप नहीं हटता, क्योंकि ओवरलैप नेटवर्क सबनेट के बीच है, कंटेनरों के बीच नहीं। network-create संदर्भ Docker सामान्य ब्रिज आवंटन के लिए गैर-ओवरलैपिंग सबनेट माँगता है और दस्तावेज़ करता है कि एक को स्पष्ट रूप से कैसे चुनें।

VPN से बचने वाला प्रीफ़िक्स चुनें

तात्कालिक टकराव और भविष्य का रूट एक ही चुनाव से तय होते हैं, इसलिए इसे एक बार करें। उम्मीदवार श्रेणी की तुलना LAN से, होस्ट जिस भी VPN गंतव्य तक पहुँच सकता है उससे, और उपयोग में किसी भी अन्य overlay से करें।

ऐसा प्रीफ़िक्स जो Docker को संतुष्ट करता है और दूरस्थ नेटवर्क से टकराता है, आपको ऐसा कंटेनर देता है जो साफ़ शुरू होता है और टनल उठते ही पहुँच से बाहर हो जाता है। यह इस लेख की दूसरी त्रुटि है, और अब से बचने की तुलना में बाद में इसका निदान करना कहीं अधिक कठिन है।

चुनी गई श्रेणियाँ कहीं लिखें जहाँ से अगला प्रोजेक्ट उन्हें पढ़ सके। आवंटित प्रीफ़िक्स का एक-पंक्ति रजिस्टर बिना व्याख्या वाले एक सप्ताह के टाइमआउट से सस्ता है।

नेटवर्क को जानबूझकर हटाएँ या बदलें

नए Compose नेटवर्क के लिए, नेटवर्क के IPAM कॉन्फ़िगरेशन में अप्रयुक्त प्रीफ़िक्स सेट करें। मौजूदा प्रोजेक्ट के लिए, पुनःक्रमांकन की योजना बनाएँ: स्थिर पते, निर्भर सेवाएँ और नेटवर्क को फिर से बनाने का चरण सभी को ध्यान में रखना होगा, क्योंकि YAML संपादित करने से चल रहा नेटवर्क पुनःक्रमांकित नहीं होता।

यदि कोई पुराना नेटवर्क टकराव वाला आवंटन रखता है, तो उसे हटाने से पहले जाँचें कि कौन जुड़ा है। docker network rm तब तक मना करता है जब तक सक्रिय endpoint मौजूद हैं, और docker stop नेटवर्क नाम के बजाय कंटेनर नाम या ID लेता है। कंटेनर रोकने से पूल रखने वाली नेटवर्क परिभाषा भी नहीं हटती।

व्यापक prune निदान का उपकरण नहीं है। यह असंबंधित प्रोजेक्ट तक पहुँचता है और उस साक्ष्य को नष्ट कर देता है जिसे आप एकत्र करने वाले थे।

डिफ़ॉल्ट पूल केवल अगले आवंटन में मदद करते हैं

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

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

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

कार्य का क्रम: आवंटित पूल पढ़ें, ऐसा प्रीफ़िक्स चुनें जो Docker और VPN गंतव्यों दोनों से बचे, नेटवर्क को जानबूझकर फिर से बनाएँ, फिर टनल के ऊपर होने पर एक अनुरोध जाँचें।