Docker पोर्ट प्रकाशन विरुद्ध VPN: प्रतिसाद कुठे जातो

प्रकाशित कंटेनर रिव्हर्स NAT आधी स्वतःच्या पत्त्यावरून प्रतिसाद देतो. दोन रचना तो प्रतिसाद सार्वजनिक मार्गावर ठेवू शकतात, वेगवेगळ्या खर्चासह.

पूर्ण बोगदा VPN वर आल्यानंतरही होस्ट SSH ला प्रतिसाद देत राहतो, पण त्याच मशीनवरील Docker ने प्रकाशित केलेली सेवा शांत होते. ऐकणाऱ्यात काहीच बिघडलेले नाही: कंटेनर चालू आहे, पोर्ट मॅपिंग आहे आणि पॅकेट पोहोचते. कंटेनर निरोगी आहे आणि विनंती खरोखर त्याच्यापर्यंत पोहोचते. फरक एवढाच की Linux त्याचा मार्ग निवडतो तेव्हा प्रतिसाद कुठून सुरू होतो, आणि तोच फरक खालील दोन रचनांपैकी तुम्हाला कोणती हवी हे ठरवतो.

गंतव्य NAT मधून टपलचा मागोवा घ्या

एक होस्ट घ्या 192.0.2.10 वर, जो TCP 2222 172.30.240.5:22 वरील कंटेनरवर प्रकाशित करतो. 198.51.100.25 वरून येणारी विनंती कंटेनरपर्यंत पोहोचण्यापूर्वी भाषांतरित होते, आणि कंटेनर स्वतःच्या रूपात प्रतिसाद देतो.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

होस्टच्या मार्ग निर्णयाच्या वेळी प्रतिसाद अजूनही कंटेनरचा स्रोत पत्ता घेऊन जातो. रिव्हर्स भाषांतर नंतर प्रकाशित टपल पुनर्संचयित करते, आणि म्हणूनच मार्ग निवडला जातो त्या क्षणीच पॅकेट चुकीचे दिसते.

फक्त होस्टसाठीचा नियम ते का चुकवतो

WAN तक्ता फक्त 192.0.2.10 वरून येणाऱ्या पॅकेटसाठी निवडणारा नियम होस्टच्या स्वतःच्या डीमन्सना व्यापतो आणि हा पुढे पाठवलेला प्रतिसाद पूर्णपणे चुकवतो. प्रतिसादावरील स्रोत पत्ता 172.30.240.5 आहे, होस्ट नाही.

अति-सुधारणा म्हणजे कंटेनरमधून सर्व काही WAN मधून मार्गनिर्देशित करणे, ज्यामुळे कंटेनरची असंबंधित बाहेर जाणारी कनेक्शन्सही VPN मधून सूट होतात. ती मागितलेल्या धोरणापेक्षा वेगळी आहे, आणि सहसा नंतर कोणालातरी धक्का देते.

DNAT नंतरची जुळणी हा वेगळा हुक आहे

Docker चे फायरवॉल दस्तऐवज नमूद करते की सामान्य वापरकर्ता फिल्टरिंग DNAT नंतरचे गंतव्य पाहते, त्यामुळे सामान्य नियमात प्रकाशित पोर्ट 2222 जुळवणे हे कंटेनर पोर्ट 22 जुळवण्यासारखे नाही. मूळ टपल महत्त्वाचे असल्यास, कोणता पोर्ट दिसतो याचा अंदाज लावण्याऐवजी समर्थित मूळ-गंतव्य यंत्रणा वापरा.

हा हुक गोंधळ बरोबर दिसणारे आणि कधीही न जुळणारे नियम तयार करतो. धोरण पुन्हा लिहिण्यापूर्वी नियमावरचे काउंटर तपासा. हिट नसलेला नियम तुम्हाला सांगतो की तो अशा ठिकाणी मूल्यांकन केला जात आहे जिथे पॅकेट कधीही पोहोचत नाही.

रचना A: निर्णय कनेक्शन स्थिती म्हणून वाहून न्या

कनेक्शन मार्क इनग्रेस निर्णय भाषांतरातून नेऊ शकतो, पण महत्त्वाच्या मार्ग शोधापूर्वी तो पॅकेटवर पुनर्संचयित करावा लागतो. टप्पे असे आहेत:

  1. Docker, VPN किंवा अन्य धोरण-मालकाशी न टकरणारे मार्क फील्ड आणि नियम प्राधान्य राखून ठेवा.
  2. कनेक्शन ट्रॅकिंग उपलब्ध असलेल्या DNAT-पूर्व बिंदूवर फक्त इच्छित नवीन WAN कनेक्शन ओळखा.
  3. मूळ विनंतीलाच WAN तक्त्यात ढकलल्याशिवाय निर्णय कनेक्शन मार्कवर नोंदवा.
  4. प्रतिसादाच्या दिशेने, मार्गनिर्देशनापूर्वी फक्त तुमचे स्वतःचे मार्क बिट्स पॅकेटवर पुनर्संचयित करा.
  5. VPN नियम आधी जिंकू शकणार नाही इतका पूर्ण WAN तक्ता पुरेसा लवकर निवडा.

त्या तक्त्याला खरे जोडलेले मार्ग आणि गेटवे आवश्यक आहेत. मार्ग नसताना परिभाषित वर्तनही आवश्यक आहे. बोगद्यात शांतपणे पडणे हा सर्वात वाईट परिणाम आहे, कारण संरचना अजूनही चालू असल्यासारखी दिसते. त्याऐवजी बंद स्वरूपात अपयशी व्हा आणि ते नोंदवा.

रचना B: होस्टवर संपवा

कंटेनरसमोर TCP प्रॉक्सी किंवा रिव्हर्स प्रॉक्सी यासारखा हेतुपूर्वक संरचित होस्ट-बाजूचा फ्रंटएंड प्रतिसाद होस्टच्या पत्त्यावरून उत्पन्न होत असल्याचे टिकवतो. मग होस्टसाठी लिहिलेले नियम अपेक्षेप्रमाणे वागतात, आणि कंटेनर त्याच्या खाजगी नेटवर्कवर राहतो.

खर्च म्हणजे स्वतःची संरचना, स्रोत-पत्ता हाताळणी आणि प्रवेश नियंत्रणे असलेला आणखी एक हलणारा भाग. ही सहसा सोपी समर्थित सीमा असते, आणि मार्गनिर्देशन धोरण सोडून जाऊ शकणाऱ्या एका व्यक्तीने सांभाळायचे असल्यास ती अनेकदा योग्य उत्तर असते.

बदल पडताळा, हेतू नाही

सार्वजनिक बाजूने नवीन अधिकृत कनेक्शन उघडा आणि प्रतिसाद इच्छित इंटरफेसवरून बाहेर पडतो याची खात्री करा. नंतर कंटेनरने सुरू केलेली असंबंधित विनंती अजूनही VPN चे अनुसरण करते का ते तपासा.

एक नियम तपासण्यासाठी मशीनचा कनेक्शन तक्ता फ्लश करू नका: विद्यमान नोंदी त्यांचे आधीचे मॅपिंग टिकवतात, आणि फ्लश होस्टवरील बाकी सर्व तोडतो. पोर्ट प्रकाशित करणे पोहोचक्षमता ठरवते. ते प्रतिसादाचा मार्ग ठरवत नाही. निवडलेली रचना तिच्या तक्ता-नावांसह लिहून ठेवा, जेणेकरून घटनेच्या वेळी पुढील व्यक्तीला ती पुन्हा शोधावी लागणार नाही.

संबंधित लेख