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 विफलता नहीं। नियम सुधार और रूटिंग जाँच को दो अलग निष्कर्षों के रूप में रखें।
जो रूप आपने देखा, जो प्रोटोकॉल नियम जोड़ा और बाद में जो काउंटर देखा, उसे दर्ज करें। तीन पंक्तियाँ, और अगला व्यक्ति एक दोपहर के बजाय एक मिनट में नामस्थान की गलती को रूटिंग की गलती से अलग पहचान सकेगा।