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 सह्य हुने प्रिफिक्स छान्नुहोस्

तत्कालको द्वन्द्व र भविष्यको मार्ग एउटै छनोटले निर्धारण गर्छ, त्यसैले यो एक पटक गर्नुहोस्। उम्मेदवार दायरालाई LAN, होस्टले पुग्न सक्ने प्रत्येक VPN गन्तव्य, र प्रयोगमा रहेको अन्य कुनै पनि overlay सँग तुलना गर्नुहोस्।

Docker लाई सन्तुष्ट पार्ने तर टाढाको जालसँग ठोक्किने प्रिफिक्सले तपाईंलाई सफा सुरु हुने र सुरुङ माथि उठ्ने क्षणमै पुग्न नसकिने कन्टेनर दिन्छ। यो यस लेखको दोस्रो त्रुटि हो, र अहिले बच्नुभन्दा पछि निदान गर्न धेरै गाह्रो छ।

छानिएका दायराहरू अर्को परियोजनाले पढ्न सक्ने ठाउँमा लेख्नुहोस्। बाँडिएका प्रिफिक्सहरूको एक-लाइन दर्ता व्याख्या नभएको हप्ताभरको टाइमआउटभन्दा सस्तो हुन्छ।

जाललाई जानाजानी हटाउनुहोस् वा बदल्नुहोस्

नयाँ Compose जालका लागि, जालको IPAM कन्फिगरेसनमा नप्रयोग गरिएको प्रिफिक्स सेट गर्नुहोस्। विद्यमान परियोजनाका लागि, पुनःक्रमाङ्कन योजना गर्नुहोस्: स्थिर ठेगाना, निर्भर सेवा र जाल पुनः सिर्जना गर्ने चरण सबैलाई ध्यानमा राख्नुपर्छ, किनकि YAML सम्पादन गर्दा चलिरहेको जाल पुनःक्रमाङ्कन हुँदैन।

यदि पुरानो जालसँग द्वन्द्वकारी बाँडफाँट छ भने, हटाउनु अघि को जोडिएको छ जाँच्नुहोस्। docker network rm सक्रिय endpoint हुँदासम्म अस्वीकार गर्छ, र docker stop ले जालको नामको सट्टा कन्टेनरका नाम वा ID लिन्छ। कन्टेनर रोक्दा pool राख्ने जाल परिभाषा पनि हट्दैन।

व्यापक prune निदानको उपकरण होइन। यो असम्बन्धित परियोजनासम्म पुग्छ र तपाईंले सङ्कलन गर्न लागेको प्रमाण नष्ट गर्छ।

पूर्वनिर्धारित pool ले अर्को बाँडफाँटलाई मात्र मद्दत गर्छ

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

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

सिर्जना सफल भएपछि, वास्तवमा चलिरहेको उपजाल प्रमाणित गर्नुहोस् र त्यसपछि VPN लाई यसको इच्छित अवस्थामा राखेर एउटा वास्तविक अनुप्रयोग अनुरोध गर्नुहोस्। यदि pool मान्य छ र पहुँच अझै असफल हुन्छ भने, बाँकी काम मार्ग छनोट, फिल्टरिङ र फर्कने बाटो हो। त्यो रनटाइम अनुसन्धान हो, र यसले बाँडफाँट त्रुटिलाई पछाडि गएर अर्थहीन बनाउँदैन।

कामको क्रम: बाँडिएका pool पढ्नुहोस्, Docker र VPN गन्तव्य दुवैलाई छल्ने प्रिफिक्स छान्नुहोस्, जाल जानाजानी पुनः सिर्जना गर्नुहोस्, त्यसपछि सुरुङ माथि हुँदा एउटा अनुरोध परीक्षण गर्नुहोस्।