होस्ट IPsec सहकाऱ्यापर्यंत पोहोचतो, 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 पुन्हा सुरू केल्याने नियमांची स्थिती बदलू शकते आणि कामाचा भारही विस्कळीत होईल, ज्यामुळे तुम्हाला हवा असलेला स्वच्छ संकेत गमावला जातो.

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