ESP हा IP प्रोटोकॉल 50 आहे, TCP पोर्ट 50 नाही: काय परवानगी द्यावी
प्रोटोकॉल क्रमांक आणि पोर्ट क्रमांक वेगवेगळ्या नावांच्या जागा आहेत. TCP पोर्ट 50 साठीचा नियम काहीही परवानगी देत नाही, आणि NAT ट्राव्हर्सल ESP ला UDP 4500 मध्ये हलवते.
फायरवॉल फॉर्म TCP पोर्ट विचारतात, आणि स्पष्ट नोंद 50 आहे. ती नोंद काहीही परवानगी देत नाही, कारण ESP हा IP प्रोटोकॉल क्रमांक 50 आहे आणि प्रोटोकॉल क्रमांक पोर्ट नसतात. दोन्ही नावांच्या जागा फक्त लहान पूर्णांक सामायिक करतात आणि दुसरे काहीही नाही, आणि IKE संपेपर्यंत आणि संरक्षित रहदारी कधीच न पोहोचेपर्यंत चूक अदृश्य राहते.
लहान संख्या सामायिक करणाऱ्या दोन नावांच्या जागा
IP हेडरमध्ये पुढे काय येते हे नाव देणारे प्रोटोकॉल फील्ड असते: TCP साठी 6, UDP साठी 17, ICMP साठी 1, ESP साठी 50, AH साठी 51. TCP किंवा UDP हेडरमध्ये पोर्ट क्रमांक असतात, जे गंतव्य होस्टवर प्रक्रिया निवडतात. प्रोटोकॉल 50 आणि TCP पोर्ट 50 असंबंधित मूल्ये आहेत, परंतु संवाद बॉक्स त्यांना परस्पर बदलण्यायोग्य दाखवू शकतो.
म्हणूनच पोर्ट फॉरवर्डिंग नियम मूळ ESP व्यक्त करू शकत नाही. फॉरवर्ड करण्यासाठी ESP गंतव्य पोर्ट नाही, आणि फक्त पोर्ट नियम समजणाऱ्या उपकरणाकडे त्या पॅकेटसाठी शब्दसंग्रहच नाही. योग्य नियम त्याऐवजी IP प्रोटोकॉलचे नाव घेतो. कोणताही पोर्ट संवाद त्या पॅकेटसाठी चुकीचे साधन आहे.
गोंधळाचा दुसरा अर्धा भागही आहे. पॅकेट एन्क्रिप्टेड असताना त्यातील सर्व काही अपारदर्शक असते, मूळ कनेक्शनच्या TCP हेडरसह. त्या पॅकेटवर पोर्ट तपासणारा फायरवॉल बाहेरील हेडरकडे पाहत असतो, ज्यात मूळ प्रकरणात तपासण्यासाठी पोर्ट नसतात.
मूळ ESP, नंतर एन्कॅप्स्युलेटेड पर्याय
मूळ ESP थेट IP प्रोटोकॉल म्हणून वाहून नेले जाते, जे तितकेच कार्यक्षम आणि त्रासदायक आहे. अतिरिक्त हेडर नसल्यामुळे कार्यक्षम, आणि पत्ते व पोर्ट भाषांतर करणारे कोणतेही उपकरण त्याचा मागोवा घेऊ शकत नाही म्हणून त्रासदायक. NAT ट्राव्हर्सल हेच सोडवण्यासाठी आहे: ESP पॅकेट UDP मध्ये गुंडाळून, भाषांतरकाकडे पुन्हा लिहिण्यासाठी पोर्ट देतो.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
दोन्ही स्वरूप एकाच डेटा चॅनेलची पर्यायी तैनाती आहेत, एकाचे स्तर नाहीत. मूळ ESP ला परवानगी दिल्याने एन्कॅप्स्युलेटेड स्वरूपाला परवानगी मिळत नाही, आणि UDP 4500 ला परवानगी दिल्याने मूळ रहदारीला परवानगी मिळत नाही, म्हणून नियमसंच तैनातीशी जुळला पाहिजे, योगायोगाने दोन्ही झाकू नये.
इथे शोधणेही महत्त्वाचे आहे. अंतिम बिंदू वाटाघाटी दरम्यान स्वरूपांमध्ये निर्णय घेतात, आणि बदल सामान्यतः त्यांच्यामध्ये NAT आढळल्यावर होतो. त्यामुळे बोगदा उभारल्यानंतर बदलणारा मार्ग रहदारी तुमच्या नियमांनी कधीही झाकली नसलेल्या नावांच्या जागेत हलवू शकतो.
कनेक्शन प्रत्यक्षात कोणते स्वरूप वापरते ते वाचा
फायरवॉलवरून अंदाज लावण्याऐवजी अंतिम बिंदूला विचारा. Linux मध्ये स्थिती नोंद सांगते की संघटन UDP एन्कॅप्स्युलेशन वापरते का आणि कोणते पोर्ट सहभागी आहेत. पॅकेट कॅप्चर तारेतून त्याच प्रश्नाचे उत्तर देते, आणि दोन्ही नियमसंच वाचून आशा धरण्यापेक्षा वेगवान आहेत.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'पहिला आदेश NAT ट्राव्हर्सल वापरात असताना एन्कॅप्स्युलेशन प्रकार दाखवतो आणि नसताना काहीही दाखवत नाही. दुसरा दाखवतो की दोन स्वरूपांपैकी कोणते प्रत्यक्षात इंटरफेस ओलांडत आहे, आणि यामुळे कागदावर बरोबर दिसणाऱ्या संरचनेबद्दलचे वाद संपतात.
विरोधी पुरावा त्याच पायरीचा भाग आहे. शून्य जुळणी नोंदवणारा नियम तुम्हाला सांगतो की पॅकेट कधीच त्याच्यापर्यंत पोहोचले नाही, आणि तो फायरवॉलचा नाही, राउटिंग किंवा निवडकाचा प्रश्न आहे.
नंतर नियंत्रण चॅनेल स्वतंत्रपणे पुष्टी करा. IKE कडे स्वतःचे पोर्ट आणि स्वतःचे लॉग आहेत, आणि डेटाशिवाय पूर्ण झालेली वाटाघाटी हेच या लेखाचा विषय असलेले विभाजन आहे.
नियम योग्य नावांच्या जागेत लिहा
प्रोटोकॉल नियम आणि पोर्ट नियम वेगवेगळ्या सूचना आहेत, म्हणून साधनाने तुम्हाला अभिप्रेत असलेले व्यक्त केले पाहिजे. nftables मध्ये प्रोटोकॉल जुळणी स्पष्ट आहे, आणि एन्कॅप्स्युलेटेड पर्यायाला स्वतःचा UDP नियम मिळतो. दोन्ही नियम शेजारी ठेवा जेणेकरून पुनरावलोकनात जोडी दिसेल.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptचुकीच्या निदानाची भरपाई करण्यासाठी कोणताही नियम रुंदावण्याच्या मोहाला बळी पडू नका. प्रत्येक इंटरफेसवर ESP प्रोटोकॉलसाठी सर्व परवानगी देणे, किंवा कुठूनही कुठेही UDP परवानगी देणे, लक्षण सुधारते आणि तुम्ही सेट करू पाहत असलेले नियंत्रण काढून टाकते. स्वरूप माहीत झाल्यावर अरुंद समर्थित प्रवाह जवळजवळ नेहमी पुरतो.
शेवटी, बोगदा चालतो पण अनुप्रयोग चालत नाही तेव्हा स्तर सरळ ठेवा. गेटवेवर पोहोचणाऱ्या पॅकेटसाठी अजूनही फॉरवर्डिंग, परतीचा मार्ग आणि त्यांना स्वीकारणारे धोरण लागते, आणि त्यातले काहीही ESP नियमाने व्यक्त होत नाही. गहाळ पोर्ट विशिष्ट अपयश स्पष्ट करतो, प्रत्येक IPsec अपयश नाही. नियम दुरुस्ती आणि राउटिंग तपासणी दोन स्वतंत्र निष्कर्ष म्हणून ठेवा.
तुम्ही पाहिलेले स्वरूप, जोडलेला प्रोटोकॉल नियम आणि नंतर पाहिलेला काउंटर नोंदवा. तीन ओळी, आणि पुढचा माणूस दुपारऐवजी एका मिनिटात नावांच्या जागेतील चूक राउटिंगच्या चुकीपासून वेगळी करू शकेल.