Docker पोर्ट प्रकाशन आणि VPN स्रोत: तुम्ही चुकवता त्या दोन जुळण्या

नियम म्हणतो VPN सर्व्हरचा पत्ता प्रकाशित सेवेला अनुमती द्या, आणि तरीही जोडणी तुटते. हा निकाल सामान्य आहे, आणि ती Docker ची बिघाडी नाही. दोन वेगळ्या जुळण्या चुकीच्या आहेत: तुम्ही लिहिलेला स्रोत होस्टला मिळणारा स्रोत नसेल, आणि तुम्ही लिहिलेला पोर्ट फिल्टरला दिसणारा पोर्ट नसेल. दोन्ही दुरुस्त करण्यासाठी सेवेच्या आकृतीऐवजी पॅकेटचा मार्ग पाहावा लागतो.

गैरसमज: VPN सर्व्हरला अनुमती द्या आणि काम संपले

राउटेड VPN क्लायंटचा टनेल पत्ता Docker होस्टपर्यंत टिकवू शकते. स्रोत भाषांतर करणारे गेटवे तो पत्ता स्वतःच्या पत्त्याने बदलू शकते. दोन्ही रचना वैध आहेत, आणि त्या एकाच वापरकर्ता कृतीसाठी वेगवेगळे स्रोत देतात.

म्हणून VPN सर्व्हर IP हे वाक्य गृहीतकाचे वर्णन करते, निरीक्षणाचे नाही. तुमच्यासमोर दोनपैकी कोणती रचना आहे हे कळेपर्यंत नियम हा अंदाज आहे.

स्रोत: क्लायंट पूल की भाषांतरित गेटवे

चार गोष्टी क्रमाने तपासा. पहिली, क्लायंट पत्ता पूल, उदाहरणार्थ 10.90.0.0/24. दुसरी, गेटवे तो पूल होस्टपर्यंत पोहोचण्यापूर्वी भाषांतरित करते का. तिसरी, एका नवीन जोडणीसाठी होस्ट प्रत्यक्षात कोणता स्रोत पाहतो. चौथी, अनुप्रयोग प्रमाणीकरण वैयक्तिक वापरकर्त्यांना वेगळे करते का, कारण सामायिक भाषांतरित पत्ता ते करू शकत नाही.

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

पोर्ट: DNAT तुम्ही जुळवता तो क्रमांक बदलते

Docker iptables सह सामान्य Linux ब्रिज प्रकाशनात, 8443 वरून कंटेनर पोर्ट 443 वरचे होस्ट मॅपिंग फॉरवर्डिंग फिल्टर चालण्यापूर्वी भाषांतरित होते. पॅकेट फिल्टरकडे गंतव्य पोर्ट 443 सह पोहोचते. त्या क्षणी 8443 शी जुळणारा नियम कधीही सक्रिय होत नाही, क्लायंटने टाइप केलेले 8443 असले तरी.

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

कोणता क्रमांक हेतू व्यक्त करतो ते ठरवा. नियम कंटेनरच्या आतील सेवेचे रक्षण करत असेल तर DNAT नंतरच्या कंटेनर पोर्टशी जुळवा. नियमाने क्लायंटने काय मागितले ते वर्णन करायचे असेल तर conntrack पर्यायासह मूळ गंतव्याशी जुळवा, आणि त्याबरोबर येणारा अतिरिक्त जुळवणी खर्च व नियम क्रमाची काळजी स्वीकारा.

साखळी: DOCKER-USER, INPUT नाही

Docker चे iptables मार्गदर्शक वापरकर्ता फॉरवर्डिंग धोरण DOCKER-USER साखळीत ठेवते, ज्याचे मूल्यांकन Docker च्या स्वतःच्या फॉरवर्डिंग नियमांपूर्वी होते. होस्ट सेवेतून INPUT साखळीत नकल केलेला नियम होस्टकडे पाठवलेली रहदारी गाळतो, कंटेनरकडे फॉरवर्ड होणारी रहदारी नाही. ही चूक बरोबर दिसणारा आणि कंटेनरच्या मार्गावर कोणताही परिणाम न करणारा नियम तयार करते.

स्रोत श्रेणी, प्रभावी गंतव्य पोर्ट, प्रोटोकॉल आणि आवक इंटरफेस एकाच नियमात एकत्र ठेवा. प्रत्येक फॉरवर्ड होणाऱ्या गंतव्यासाठी केवळ-स्रोत अनुमती एका प्रकाशित सेवेला अनुमती देण्यापेक्षा व्यापक आहे.

नवीन जोडण्यांनी पडताळा

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

या तपासण्यांच्या मागील साखळी क्रम आणि पोर्ट भाषांतराचे वर्तन Docker चे iptables मार्गदर्शक मध्ये नोंदवले आहे. कोणतीही कृती नकलण्यापूर्वी ते वाचा, आणि स्थापित Docker कोणता बॅकएंड वापरतो याची खात्री करा, कारण nftables बॅकएंड धोरण वेगळ्या पद्धतीने एकत्रित करतो.