Docker: VPN सत्रको क्रममा कुनै पूर्वनिर्धारित ठेगाना पूल बाँकी छैन
पूर्वनिर्धारित-पूल त्रुटि स्वचालित बाँडफाँटसँग सम्बन्धित हो, सार्वजनिक ठेगानासँग होइन। बाँडफाँट गन्नुहोस्, अन-लिङ्क मार्गहरू तुलना गर्नुहोस् र VPN नीति अक्षुण्ण राख्नुहोस्।
विफलता विशिष्ट छ: Docker ले नयाँ ब्रिज नेटवर्कका लागि स्वीकार्य स्वचालित सबनेट भेट्टाउन सक्दैन। यसको अर्थ मेसिनका ठेगाना सकिए भन्ने होइन, र VPN बिग्रियो भन्ने पनि होइन। निदान दुई प्रश्नले निर्धारण गर्छ: डेमनले कुन उम्मेदवार ब्लक देख्न सक्छ, र यो वातावरणमा यसको बाँडफाँटकर्ताले तीमध्ये कुन बाहिर राख्छ। तिनलाई यही क्रममा सक्नुहोस्, किनकि पहिलो प्रश्नको उत्तर नपाउँदासम्म दोस्रो प्रश्नको अर्थ हुँदैन।
केही परिवर्तन गर्नु अघि के असफल भयो त्यो पुष्टि गर्नुहोस्
तलका चरणहरू डेमन चलाउने होस्टबाट चलाउनुहोस्। टाढाको सन्दर्भसँग बोल्ने शेल अर्कै मेसिनको वर्णन गर्दै छ, र त्यो एउटा गल्तीले एक घण्टा बर्बाद गर्न सक्छ।
एकै समयमा टिकटमा Engine संस्करण लेख्नुहोस्। यो रनबुकको बाँकी भागको प्रत्येक ह्युरिस्टिक संस्करण-सीमित छ, र संस्करण बिनाको दाबी हल्ला हो।
तपाईंसँग पहिले नै भएका बाँडफाँट गन्नुहोस्
नेटवर्कहरू सूचीबद्ध गर्नुहोस्, त्यसपछि महत्त्वपूर्णहरू जाँच्नुहोस्: docker network ls, त्यसपछि docker network inspect NETWORK_NAME। तिनका IPAM सबनेट र प्रत्येकसँग जोडिएका कन्टेनर पढ्नुहोस्। धेरै Compose परियोजनाहरूले कन्टेनर संख्याले संकेत गरेभन्दा बढी ब्लक खपत गर्छन्, किनकि हरेक परियोजना आफ्नै पूर्वनिर्धारित नेटवर्क बनाउन प्रवृत्त हुन्छ। रोकिएको कन्टेनरले आफ्नो नेटवर्कको बाँडफाँट जारी गर्दैन।
पूल कन्फिगरेसन पनि जाँच्नुहोस्, किनकि पूर्वनिर्धारित पूलमा आधार दायरा र प्रति-नेटवर्क प्रिफिक्स आकार हुन्छ। प्रति नेटवर्क ठूला बाँडफाँटले उपलब्ध ब्लक छिटो सक्छ, र त्यो क्षमताको तथ्य हो, राउटिङ समस्या होइन।
गणना लेख्नुहोस्। अर्को परिवर्तनले मद्दत गर्यो कि गरेन भन्ने आधाररेखा त्यही हो।
डेमनले मार्गहरूलाई कसरी देख्छ त्यो तुलना गर्नुहोस्
VPN ले उम्मेदवार छनोटलाई प्रभाव पार्न सक्छ, तर कसरी भन्ने ठ्याक्कै कार्यान्वयनले निर्धारण गर्छ। Linux मा Moby 28.2.2 मा, InferReservedNetworks ले नेमसर्भर ठेगाना र केही अन-लिङ्क IPv4 मार्ग सङ्कलन गर्छ, र यसले हरेक तालिकाको हरेक मार्ग सजिलै आरक्षित गर्दैन। सङ्कलित लिङ्क मार्गहरूले अनिर्दिष्ट गन्तव्य ठेगाना पनि बाहिर राख्छन्, त्यसैले एउटै 0.0.0.0/1 मार्गले सबै ठेगाना आरक्षित गर्दैन। अर्को फराकिलो अन-लिङ्क प्रिफिक्स, जस्तै 128.0.0.0/1, परिचित 172 र 192 उम्मेदवार दायराहरूलाई काट्न सक्छ।
VPN जडान हुनुअघि र पछि ip -4 route show table all को डेमनको होस्टमा तुलना गर्नुहोस्। भिन्नता नै प्रमाण हो, र संस्करण नै दाबीको दायरा हो।
एउटा संस्करणको ह्युरिस्टिकलाई सबै संस्करणमा सामान्यीकरण नगर्नुहोस्। यसरी नै फोरमको उत्तर नीति परिवर्तन बन्छ।
काम गर्ने सबैभन्दा सानो सुधार छान्नुहोस्
यदि पुष्टि भएको अप्रयुक्त नेटवर्कले तपाईंलाई आवश्यक ब्लक राख्छ भने, फराकिलो छाँट्ने होइन, मालिकसँगै त्यसको लक्षित अवकाश योजना बनाउनुहोस्। नयाँ नेटवर्कका लागि, स्पष्ट रूपमा समीक्षा गरिएको अप्रयुक्त सबनेटले स्वचालित छनोटमा निर्भरता पूर्ण रूपमा टार्छ। त्यो सबनेटले अझै पनि वास्तविक Docker, LAN र आवश्यक VPN गन्तव्यहरूबाट बच्नुपर्छ, किनकि निजी भन्नाले सुरक्षित भन्ने होइन। वास्तविक टाढाको प्रिफिक्स राउट गर्नाले बाँडफाँटको त्रुटिलाई टुटेको पहुँचसँग साट्ने थियो।
default-address-pools परिवर्तन गर्नु भविष्यका बाँडफाँटबारे फराकिलो नीति हो। द्वन्द्वरहित आधार र उपयुक्त बाँडिएको आकार छान्नुहोस्, यसलाई विद्यमान डेमन सेटिङसँग मिलाउनुहोस्, र कागजात गरिएको पुनःसुरु प्रभाव योजना बनाउनुहोस्। विद्यमान नेटवर्कहरू चुपचाप पुनःक्रमाङ्कित हुँदैनन्।
बाँडफाँट सफल होस् भनेर कम्पनीको मार्ग पुश बन्द नगर्नुहोस्। स्पष्ट ठेगाना योजनाले सामान्यतया अनिवार्य नीति कमजोर नपारी स्थानीय समस्या समाधान गर्छ।
बाँडफाँट र राउटिङ अलग-अलग स्वीकार्नुहोस्
परिवर्तनपछि, Docker ले वास्तवमै बनाएको सबनेट जाँच्नुहोस् र अनुप्रयोगको VPN र स्थानीय निर्भरताहरू परीक्षण गर्नुहोस्। सफल बाँडफाँट र रनटाइममा सही राउटिङ दुई फरक स्वीकृति जाँच हुन्, र पहिलो उत्तीर्ण हुनु दोस्रोको प्रमाण होइन। यदि अनुप्रयोगले सुरुङपछाडिको स्रोतमा पुग्न सक्दैन भने, पूल त्रुटिले लुकाएको राउटिङ समस्या तपाईंसँग छ। दुवै नतिजा टिकटमा लेख्नुहोस्।
मार्गको भिन्नता र पूलको गणना परिवर्तन अभिलेखसँगै राख्नुहोस्, किनकि अर्को VPN क्लाइन्ट अद्यावधिकले Docker नछोई पहिलोलाई बदल्न सक्छ।
अरू कसैले यी दुई जाँच दोहोर्याएर त्यही उत्तर पाउन सक्दा रनबुक पूर्ण हुन्छ।