Docker ची pool ओव्हरलॅप त्रुटी VPN मार्गाची समस्या नाही

Docker या पत्ता-जागेत pool दुसऱ्याशी ओव्हरलॅप होत असल्याच्या संदेशासह नेटवर्क तयार करण्यास नकार देते, आणि कोणीतरी ठरवते की VPN मार्ग हेच कारण असले पाहिजे. तसे होऊ शकत नाही. ती त्रुटी pool वाटला जात असताना, एकही पॅकेट नसताना उद्भवते, आणि हाताने केलेल्या कर्नेल मार्गाचा त्यावर कोणताही परिणाम नसतो. VPN एक पाऊल नंतर महत्त्वाचे ठरते, जेव्हा आधीच पत्ता असलेला कंटेनर मार्ग दिसल्यानंतर पोहोचण्यायोग्य राहत नाही. दोन समस्या, पुराव्याचे दोन संच, आणि त्या एकत्र केल्याने दोन्हीपैकी काहीही सुधारत नाही असा बदल होतो.

सारख्या दिसणाऱ्या दोन त्रुटी

वाटपाची त्रुटी अंकगणितीय आहे. Docker तुम्ही मागितलेल्या उपजाळाची तुलना तो आधीच व्यवस्थापित करत असलेल्या उपजाळांशी करतो, छेदन शोधतो आणि नकार देतो. अजून काहीही चालू नाही, त्यामुळे मार्ग नाही, कंटेनर नाही आणि तपासण्यासाठी रहदारी नाही.

रनटाइम लक्षण पोहोचण्याचा प्रश्न आहे. काल उत्तर देत असलेला कंटेनर आता उत्तर देत नाही, आणि होस्टच्या राउटिंग तक्त्यात काहीतरी बदलले आहे. कंटेनर अजूनही आपला पत्ता धरून आहे; प्रश्न हा आहे की तो पत्ता कोणता मार्ग घेतो.

दोन्ही पत्ता-योजनेच्या समस्या आहेत. त्यातील फक्त एक Docker ची समस्या आहे.

आधी वाटलेले pool वाचा

नेटवर्कची यादी करा आणि छेदू शकणारे तपासा. उपजाळ IPAM संरचनेत असते, आणि जोडलेले कंटेनर वेगळे सूचीबद्ध केले जातात:

docker network ls
docker network inspect EXISTING_NETWORK

त्या उपजाळाची तुलना नवे नेटवर्क मागणाऱ्या pool शी करा, आणि लक्षात ठेवा की Compose प्रत्येक प्रकल्पासाठी स्वतःचे डीफॉल्ट नेटवर्क तयार करते. विसरलेल्या प्रकल्पाशी संघर्ष डेमनशी संघर्षासारखाच दिसतो.

सेवेवरील स्थिर ipv4_address एका कंटेनरचा पत्ता आहे, pool ची व्याख्या नाही. तो बदलल्याने ओव्हरलॅप जात नाही, कारण ओव्हरलॅप कंटेनरांमध्ये नाही तर नेटवर्क उपजाळांमध्ये असते. Docker चे network-create संदर्भ सामान्य ब्रिज वाटपासाठी ओव्हरलॅप न होणारी उपजाळे मागते आणि एक स्पष्टपणे कशी निवडावी हे दस्तऐवजीकरण करते.

VPN टिकून राहील असा prefix निवडा

तात्कालिक संघर्ष आणि भविष्यातील मार्ग एकाच निवडीने ठरतात, म्हणून ती एकदाच करा. उमेदवार श्रेणीची तुलना LAN, होस्ट पोहोचू शकणाऱ्या प्रत्येक VPN गंतव्याशी आणि वापरात असलेल्या इतर कोणत्याही overlay शी करा.

Docker ला समाधान देणारा आणि दूरच्या नेटवर्कशी टकराव करणारा prefix तुम्हाला असा कंटेनर देतो जो स्वच्छ सुरू होतो आणि बोगदा वर आल्याक्षणी पोहोचण्यायोग्य राहत नाही. ही या लेखातील दुसरी त्रुटी आहे, आणि आता टाळण्यापेक्षा नंतर तिचे निदान करणे खूप कठीण आहे.

निवडलेल्या श्रेणी पुढील प्रकल्प वाचू शकतो अशा ठिकाणी लिहा. वाटलेल्या prefix चा एका ओळीचा नोंदवही स्पष्टीकरण नसलेल्या आठवडाभराच्या टाइमआउटपेक्षा स्वस्त आहे.

नेटवर्क जाणीवपूर्वक सेवानिवृत्त करा किंवा बदला

नव्या Compose नेटवर्कसाठी, नेटवर्कच्या IPAM संरचनेत न वापरलेला prefix सेट करा. विद्यमान प्रकल्पासाठी, पुनर्क्रमांकनाची योजना करा: स्थिर पत्ते, अवलंबून असलेल्या सेवा आणि नेटवर्क पुन्हा तयार करण्याची पायरी—सर्व विचारात घ्यावी लागेल, कारण YAML संपादित केल्याने चालू नेटवर्कचे पुनर्क्रमांकन होत नाही.

जुने नेटवर्क संघर्षकारक वाटपाचे मालक असेल, तर ते काढण्यापूर्वी कोण जोडलेले आहे ते तपासा. docker network rm सक्रिय endpoint असल्यास नकार देते, आणि docker stop नेटवर्कच्या नावाऐवजी कंटेनरची नावे किंवा ID घेते. कंटेनर थांबवल्याने pool धरून ठेवणारी नेटवर्क व्याख्या देखील जात नाही.

व्यापक prune हे निदानाचे साधन नाही. ते असंबंधित प्रकल्पांपर्यंत पोहोचते आणि तुम्ही गोळा करणार असलेला पुरावा नष्ट करते.

डीफॉल्ट pool फक्त पुढील वाटपास मदत करतात

डेमनचे डीफॉल्ट पत्ता pool सेटिंग भविष्यातील स्वयंचलित वाटपे तुम्ही राखीव ठेवलेल्या श्रेणींबाहेर ठेवून सुधारते. ते आधीच अस्तित्वात असलेल्या नेटवर्कना मागे जाऊन नवीन पत्ते देत नाही, आणि दुसऱ्या स्पष्ट उपजाळाशी ओव्हरलॅप होणाऱ्या स्पष्ट उपजाळाचे निराकरण करत नाही.

त्या सेटिंगला स्वतःच्या रीस्टार्टसह वेगळा, नियोजित बदल माना, एका प्रकल्पाच्या दुरुस्तीचा भाग नाही. दोन्ही एकत्र केल्याचा अर्थ डेमनचा रीस्टार्ट असंबंधित तपासणीच्या मध्यात पडतो. ते स्वतःच्या विंडोमध्ये नियोजित करा. नंतर नवीन स्वयंचलित वाटप प्रत्यक्षात तुम्ही राखीव ठेवलेल्या श्रेणींबाहेर पडते याची खात्री करा.

निर्मिती यशस्वी झाल्यानंतर, प्रत्यक्षात चालू असलेले उपजाळ तपासा आणि नंतर VPN त्याच्या इच्छित स्थितीत ठेवून एक वास्तविक अनुप्रयोग विनंती करा. जर pool वैध असेल आणि प्रवेश अजूनही अयशस्वी होत असेल, तर उर्वरित काम मार्ग निवड, फिल्टरिंग आणि परतीचा मार्ग आहे. ती रनटाइम तपासणी आहे, आणि ती वाटपाच्या त्रुटीला मागे जाऊन अर्थहीन करत नाही.

कामाचा क्रम: वाटलेले pool वाचा, Docker आणि VPN गंतव्ये दोन्ही टाळणारा prefix निवडा, नेटवर्क जाणीवपूर्वक पुन्हा तयार करा, नंतर बोगदा वर असताना एक विनंती तपासा.