प्रोटोकॉल 47 बनाम TCP पोर्ट 47: दो हेडर, दो नियम
प्रोटोकॉल संख्या और पोर्ट अलग-अलग हेडर में रहते हैं, इसलिए एक नियम दूसरे की जगह नहीं ले सकता। PPTP दोनों को अलग करता है, और पोर्ट का खाना GRE व्यक्त नहीं कर सकता।
होटल के नेटवर्क और सम्मेलन के फ़ायरवॉल अक्सर एक कस्टम अनुमति-खाना दिखाते हैं, और कोई उसमें 47 लिख देता है इस उम्मीद में कि PPTP काम करेगा। नियम बन जाता है, टनल फिर भी विफल रहता है, और अगली कोशिश किसी दूसरे नंबर का उपयोग करती है। गलती पैकेट में ही है: IPv4 में एक प्रोटोकॉल फ़ील्ड है जो बताता है कि IP हेडर के बाद क्या आता है, जबकि TCP और UDP में पोर्ट फ़ील्ड हैं जो केवल तभी मौजूद होते हैं जब आप उन हेडरों में से किसी एक के भीतर हों। ये एक ही अनुमति की दो वर्तनियाँ नहीं हैं।
IPv4 हेडर अगले प्रोटोकॉल का नाम बताता है
प्रोटोकॉल फ़ील्ड IPv4 हेडर में एक बाइट है, और यह पेलोड का वर्णन करने वाली संख्या रखता है: TCP के लिए 6, UDP के लिए 17, GRE के लिए 47, ESP के लिए 50। पैकेट फ़िल्टर करने वाली हर चीज़ गहराई में देखने से पहले वह मान पढ़ती है, क्योंकि गहरा हेडर केवल प्रकार जानने के बाद ही अर्थपूर्ण होता है। बातचीत में बाद में कोई पोर्ट बदलिए, और यह फ़ील्ड हिला नहीं है।
इसलिए प्रोटोकॉल 47 के विरुद्ध लिखा गया नियम IP परत का वर्णन करता है। निर्णय में कोई पोर्ट भाग ही नहीं लेता।
पोर्ट TCP और UDP के भीतर ही होते हैं, और कहीं नहीं
पोर्ट TCP और UDP हेडरों के भीतर सोलह-बिट पहचानकर्ता हैं, और उनका काम एक ही पता साझा करने वाली बातचीतों को अलग करना है। GRE हेडर एक प्रोटोकॉल प्रकार मान, अक्सर EtherType, साथ में मल्टीप्लेक्सिंग के लिए वैकल्पिक कुंजियाँ रखता है। इसलिए पोर्ट 47 वाक्यांश ऐसी किसी चीज़ का नाम नहीं देता जिससे GRE पैकेट मेल खा सके।
फ़ायरवॉल इंटरफ़ेस इसमें से कितना दिखाते हैं, इसमें अलग हैं। कुछ प्रोटोकॉल संख्या स्वीकार करते हैं, कुछ नाम वाली सूची देते हैं, और कुछ ही केवल पोर्ट के साथ TCP या UDP स्वीकार करते हैं।
PPTP एक साथ दोनों परतें उपयोग करता है
PPTP सबसे स्पष्ट उदाहरण है क्योंकि यह जानबूझकर अपना काम दोनों परतों में बाँटता है। नियंत्रण कनेक्शन पोर्ट 1723 पर TCP सत्र है, और डेटा पथ GRE, प्रोटोकॉल 47 है, जिसमें कहीं कोई पोर्ट शामिल नहीं है। जो फ़ायरवॉल 1723 की अनुमति देता है और कुछ नहीं, वह बातचीत शुरू होने देता है और फिर पेलोड फेंक देता है। टनल जुड़ने में विफल होने के बजाय प्रमाणीकरण के बाद अटका हुआ दिखता है, और इसलिए लक्षण अक्सर पासवर्ड की समस्या के रूप में दर्ज होता है।
| Path | Outer protocol | Port |
|---|---|---|
| Control channel | TCP, protocol 6 | 1723 |
| Data channel | GRE, protocol 47 | None |
नियम लिखते समय दोनों पंक्तियाँ अलग-अलग पढ़िए, और हर एक को विक्रेता के सिंटैक्स के सामने जाँचिए। एक पंक्ति को पोर्ट चाहिए, दूसरी को प्रोटोकॉल संख्या चाहिए, और कोई एक प्रविष्टि दोनों को नहीं ढकती।
पोर्ट-फ़ॉरवर्ड पृष्ठ GRE क्यों व्यक्त नहीं कर सकता
केवल TCP और UDP स्वीकार करने वाला फ़ॉरवर्डिंग फ़ॉर्म GRE का वर्णन नहीं कर सकता, फ़ॉर्म का नाम जो भी हो। पता अनुवाद दूसरी कठिनाई जोड़ता है, क्योंकि GRE में पोर्ट नहीं होते और अनुवादक को इसके बजाय कॉल पहचानकर्ता का पीछा करना पड़ता है। कुछ उपभोक्ता राउटर के साथ इसे संभालने वाला सहायक आता है; बहुतों के साथ नहीं, और कोई अतिरिक्त TCP अनुमति-प्रविष्टि वह व्यवहार नहीं बनाएगी।
जहाँ आधुनिक टनल ही असली आवश्यकता है, वहाँ अनुवादक के सही अनुमान लगाने की आशा करने के बजाय जानबूझकर TCP या UDP उपयोग करने वाला डिज़ाइन चुनिए।
एन्कैप्सुलेशन तय करता है कि फ़िल्टर क्या देखता है
एन्कैप्सुलेशन बाहरी पैकेट बदलता है, और बाहरी पैकेट वही है जिससे नियम मेल खाता है। मूल ESP प्रोटोकॉल 50 है, जबकि NAT पारगमन ESP को UDP 4500 के भीतर लपेटता है ताकि वह पता अनुवाद से बच जाए। जो फ़िल्टर UDP 4500 की अनुमति देता है वह कभी प्रोटोकॉल 50 नहीं देखता, और प्रोटोकॉल 50 के लिए लिखा फ़िल्टर कभी लिपटे रूप से मेल नहीं खाता।
क्लाइंट और गेटवे किस एन्कैप्सुलेशन पर सहमत हुए, यह पूछिए, फिर नियम ठीक उसी बाहरी आकार के लिए लिखिए, उससे अधिक कुछ नहीं।
नियम ऐसे लिखिए कि कोई उसे जाँच सके
हर नियम को पता परिवार, बाहरी प्रोटोकॉल, यदि हों तो परिवहन पोर्ट, दिशा और दोनों अंत बिंदुओं के रूप में व्यक्त कीजिए। समीक्षक उस वाक्य को पैकेट कैप्चर से मिलाकर निर्णय तक पहुँच सकता है। 47 खोलने का निर्देश कोई जाँच नहीं सकता, और इसीलिए वह वर्षों तक रनबुक में टिका रहता है।
वह परीक्षण जोड़िए जो इसे साबित करता है: बाहरी इंटरफ़ेस पर कैप्चर करते हुए जुड़िए, और पुष्टि कीजिए कि ट्रेस में वास्तव में कौन-सा बाहरी प्रोटोकॉल और पोर्ट दिखता है।