होस्ट IPsec साथीसम्म पुग्छ, Docker कन्टेनर पुग्दैन
ब्रिज कन्टेनर अर्को स्रोत प्रयोग गर्छ र फर्वार्डिङबाट भित्र पस्छ, त्यसैले होस्टको सुरुङले धेरै प्रमाणित गर्दैन। Docker पुनः सुरु गर्नु अघि सिलेक्टरहरू जाँच्नुहोस्।
तपाईं Linux मेसिनबाट टाढाको होस्टलाई ping गर्नुहुन्छ र त्यसले जवाफ दिन्छ, अर्थात् सुरुङ काम गरिरहेको छ। तपाईंको छेउको कन्टेनर अझै समय सकिएर रोकिन्छ, र अर्को स्वाभाविक कदम Docker पुनः सुरु गर्नु हो। ब्रिज नेटवर्कको कन्टेनर सामान्यतया अर्को स्रोत ठेगानाबाट सुरु हुन्छ र होस्टमा एप्लिकेसनको आफ्नै निकास मार्गको सट्टा फर्वार्डिङबाट प्रवेश गर्छ, त्यसैले सफल परीक्षणले अर्को प्याकेट नाप्यो। नीति-आधारित strongSwan सुरुङका लागि टाढाको सबनेटतर्फ साधारण मार्ग पर्याप्त हुँदैन जब फर्वार्ड गरिएको प्याकेट स्थापित IPsec नीतिसँग मेल खाँदैन।
तलको मार्गदर्शनले एउटा गन्तव्यलाई दुई स्रोतमार्फत पछ्याउँछ र केही परिवर्तन गर्नु अघि अवस्था पढ्छ।
एउटा गन्तव्य र दुई स्रोतबाट सुरु गर्नुहोस्
पहिले IP अनुसार चिनिएको सेवा छान्नुहोस्, ताकि एकै समयमा DNS पनि टुंग्याउनु नपरोस्। तीन तथ्य लेख्नुहोस्: कन्टेनरको ब्रिज प्रिफिक्स, सफल होस्ट अनुरोधको स्रोत ठेगाना, र सुरुङका लागि सहमत स्थानीय तथा टाढाका ट्राफिक सिलेक्टर। ती तीन संख्याले यो लक्षणको लगभग हरेक अवस्था व्याख्या गर्छन्।
त्यसपछि असफल अनुरोध कन्टेनरभित्रबाट दोहोर्याउनुहोस् र यसले वास्तवमा प्रयोग गर्ने स्रोत समात्नुहोस्। यदि त्यो ठेगाना स्थानीय सिलेक्टरमा समेटिएको छैन भने नतिजा तपाईंलाई पहिले नै थाहा छ, र कन्टेनर पुनः बनाउँदा त्यो बदलिँदैन।
Docker छुनु अघि नीतिहरू पढ्नुहोस्
पढ्ने-मात्र होस्ट जाँचले राउटिङ निर्णय, नीति डेटाबेस र तिनीहरूबीच छनोट गर्ने नियमहरू समेट्छ:
ip rule show
ip route show table all
ip xfrm policyनीति सूचीले सिलेक्टर र दिशा देखाउँछ, कुञ्जी सामग्रीले भरिएको IPsec अवस्था डम्पको आवश्यकता बिना, त्यसैले यसलाई टिकटमा टाँस्नु सुरक्षित छ। होस्ट ठेगाना समेट्ने तर ब्रिज प्रिफिक्स नसमेट्ने स्थानीय सिलेक्टर खोज्नुहोस्। ओभरल्याप पनि जाँच्नुहोस्: टाढाको गन्तव्यलाई स्थानीय ठान्ने कन्टेनर मार्गले कहिल्यै अपेक्षित फर्वार्ड गरिएको प्याकेट उत्पादन गर्दैन, र दोष सुरुङमाथि लगाइन्छ। त्यो सूची कन्टेनरको स्रोत ठेगाना नजिक राख्नुहोस्, किनकि दुवै मिलेर पूरा तुलना हो।
यदि कन्टेनर प्रिफिक्स छैन भने रोक्नुहोस् र अरू केही सम्पादन गर्नु अघि संरचना तय गर्नुहोस्। बाँकी मार्गदर्शनले तपाईंले कुन स्रोत ठेगाना नेटवर्कमा देखिनुपर्ने तय गर्नुभएको मान्छ।
फिल्टरिङ र अनुवाद क्रममा जाँच्नुहोस्
Docker को Linux ब्रिज फायरवालले फर्वार्डिङलाई IPsec बाट स्वतन्त्र रूपमा रोक्न सक्छ। iptables ब्याकएन्डसँग FORWARD मार्ग र DOCKER-USER निर्णय हेर्नुहोस्, पहिलेको निर्णयपछि थपिएको नियम कहिल्यै नचल्न सक्ने कुरा सम्झनुहोस्। nftables ब्याकएन्ड फरक तरिकाले एकीकृत हुन्छ, त्यसैले कुनै iptables उदाहरणले त्यसलाई यो नाम दियो भनेर मात्र DOCKER-USER शृंखला नबनाउनुहोस्; तपाईंको daemon वास्तवमा कुन ब्याकएन्ड प्रयोग गर्छ जाँच्नुहोस्।
त्यसपछि स्रोत अनुवाद जाँच्नुहोस्। फराकिलो MASQUERADE नियमले पहिले IPsec सिलेक्टरसँग मिल्ने प्याकेटलाई अब नमिल्ने प्याकेटमा बदल्न सक्छ, र असफलता ठ्याक्कै राउटिङ समस्याजस्तै देखिन्छ। strongSwan फर्वार्डिङ गाइड ले पहिले नै नीतिसँग मिल्ने ट्राफिकका लागि त्यस्तो अनुवाद अघि आवश्यक NAT छुटको दस्तावेजीकरण गर्छ।
त्यो छुट सुरुङमा नसमेटिएको कन्टेनर स्रोत थप्ने तरिका होइन। यसले पहिले नै डिजाइनमा फिट हुने ट्राफिकको मात्र रक्षा गर्छ, त्यसैले पहिले सिलेक्टर र फर्किने मार्गका प्रश्न टुंग्याउनुहोस्, अनि NAT र फिल्टरिङलाई उत्तरसँग मिलाउनुहोस्। यदि छुटलाई नै फराकिलो बनाउन थाल्नुभयो भने बदल्नुपर्ने कुरा सिलेक्टर हो, NAT नियम होइन।
त्यसपछि राउटेड वा अनुवादित भनी निर्णय गर्नुहोस्
राउटेड कन्टेनर सबनेटका लागि दुवै साथीले त्यो सबनेट स्वीकार्नुपर्छ र त्यहाँसम्म टाढाको फर्किने मार्ग हुनुपर्छ, जसको सामान्य अर्थ दुवै छेउमा सिलेक्टर परिवर्तन र टाढाको पक्षको मालिकसँग कुराकानी हो। जानाजान अनुवादित डिजाइनले भने सम्बन्धित लुकअप चरणमा नीतिले समेटेको ठेगाना प्रस्तुत गर्नुपर्छ, जसको सामान्य अर्थ पूर्वनिर्धारित MASQUERADE सट्टा साँघुरो, दस्तावेजीकृत नियम हो।
यी दुई व्यवस्थामध्ये कुनै पनि होस्टको काम गर्ने सुरुङबाट आफैँ आउँदैन, र तिनीहरूबीचको छनोट मालिक भएको डिजाइन निर्णय हो। तपाईंले कुन छान्नुभयो लेख्नुहोस्, नत्र अर्को इन्जिनियरले यसलाई फेरि फायरवाल काउन्टरबाट निकाल्नेछ।
मिश्रित असफलतामा पनि ध्यान दिनुहोस्: नियमसमूहको आधा अनुवादित र आधा होइन, जसले गन्तव्य पोर्टमा निर्भर र नेटवर्कको कुनै कुरामा निर्भर नहुने रोकिँदै चल्ने सफलता दिन्छ।
नयाँ जडानले प्रमाणित गर्नुहोस्, पुनः सुरुले होइन
नयाँ एप्लिकेसन जडान प्रयोग गर्नुहोस् र सँगै साँघुरो फायरवाल काउन्टर तथा टाढाको प्राप्तकर्ता हेर्नुहोस्, ताकि हरेक अवलोकनको स्रोत होस्। Docker पुनः सुरु गर्दा नियमको अवस्था बदलिन सक्छ र कामको भार पनि बिथोलिन्छ, जसले तपाईंलाई चाहिएको सफा सङ्केत खोस्छ।
टिकाउ नतिजा चार भनाइ हुन् जो तपाईं देखाउन सक्नुहुन्छ: कन्टेनरको स्रोत, मिल्ने संरक्षित मार्ग, अनुमति दिइएको फर्वार्डिङ, र फर्केर आउने जवाफ। चारै लागू हुँदा, कन्टेनर जुन कारणले होस्ट पुग्छ त्यही कारणले साथीसम्म पुग्छ।