होस्ट 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 बैकएंड अलग तरह से एकीकृत होता है, इसलिए केवल इसलिए DOCKER-USER चेन न बनाएँ कि किसी iptables उदाहरण ने उसे यह नाम दिया; देखें आपका daemon वास्तव में कौन-सा बैकएंड उपयोग करता है।

फिर स्रोत अनुवाद जाँचें। व्यापक MASQUERADE नियम उस पैकेट को, जो पहले IPsec सेलेक्टर से मेल खाता था, ऐसे पैकेट में बदल सकता है जो अब नहीं खाता, और विफलता बिल्कुल रूटिंग समस्या जैसी दिखती है। strongSwan फ़ॉरवर्डिंग गाइड उस NAT छूट का दस्तावेज़ीकरण करता है जो पहले से नीति से मेल खाते ट्रैफ़िक के लिए ऐसे अनुवाद से पहले आवश्यक है।

वह छूट सुरंग में बिना कवरेज वाला कंटेनर स्रोत जोड़ने का तरीका नहीं है। यह केवल उस ट्रैफ़िक की रक्षा करती है जो पहले से डिज़ाइन में फ़िट बैठता है, इसलिए पहले सेलेक्टर और वापसी पथ के सवाल तय करें, फिर NAT और फ़िल्टरिंग को उत्तर के अनुरूप करें। यदि आप छूट को ही चौड़ा करने लगें, तो बदलने वाली चीज़ सेलेक्टर है, NAT नियम नहीं।

फिर तय करें रूटेड या अनूदित

रूटेड कंटेनर सबनेट के लिए ज़रूरी है कि दोनों सहकर्मी उस सबनेट को स्वीकारें और उस तक दूरस्थ वापसी पथ हो, जिसका आम मतलब है दोनों सिरों पर सेलेक्टर बदलना और दूर वाले पक्ष के मालिक से बात करना। जानबूझकर अनूदित डिज़ाइन को इसके बजाय संबंधित लुकअप चरण पर नीति से ढका पता प्रस्तुत करना होता है, जिसका आम मतलब है डिफ़ॉल्ट MASQUERADE के बजाय संकीर्ण, प्रलेखित नियम।

इन दोनों में से कोई भी व्यवस्था होस्ट की काम करती सुरंग से अपने आप नहीं निकलती, और इनके बीच चुनाव मालिक वाला डिज़ाइन निर्णय है। लिखें कि आपने कौन-सा चुना, वरना अगला इंजीनियर इसे फ़ायरवॉल काउंटरों से फिर निकालेगा।

मिश्रित विफलता पर भी ध्यान दें: नियम-समुच्चय का आधा अनूदित और आधा नहीं, जो रुक-रुककर सफलता देता है जो गंतव्य पोर्ट पर निर्भर है, नेटवर्क की किसी चीज़ पर नहीं।

नए कनेक्शन से सत्यापित करें, पुनःआरंभ से नहीं

नए ऐप्लिकेशन कनेक्शन का उपयोग करें और साथ ही संकीर्ण फ़ायरवॉल काउंटर तथा दूरस्थ प्राप्तकर्ता देखें, ताकि हर अवलोकन का स्रोत हो। Docker का पुनःआरंभ नियमों की स्थिति बदल सकता है और कार्यभार भी बाधित करेगा, जिससे वह साफ़ संकेत छिन जाता है जो आप पाना चाहते थे।

टिकाऊ परिणाम चार कथन हैं जो आप दिखा सकते हैं: कंटेनर का स्रोत, मेल खाता संरक्षित पथ, अनुमत फ़ॉरवर्डिंग, और लौटता उत्तर। जब चारों लागू हों, कंटेनर उसी कारण साथी तक पहुँचता है जिस कारण होस्ट पहुँचता है।