प्रोटोकल 47 बनाम TCP पोर्ट 47: दुई हेडर, दुई नियम
प्रोटोकल नम्बर र पोर्ट फरक हेडरमा बस्छन्, त्यसैले एउटा नियमले अर्कोलाई प्रतिस्थापन गर्न सक्दैन। PPTP ले दुवैलाई छुट्याउँछ, र पोर्टको खानाले GRE व्यक्त गर्न सक्दैन।
होटेलका नेटवर्क र सम्मेलनका फायरवालले प्रायः अनुकूलन अनुमति-खाना देखाउँछन्, र कोही PPTP चल्ने आशामा त्यसमा 47 लेख्छ। नियम बन्छ, टनेल तैपनि असफल हुन्छ, र अर्को प्रयासले फरक नम्बर प्रयोग गर्छ। गल्ती प्याकेटमै छ: 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 खोल्ने निर्देशन कसैले जाँच्न सक्दैन, र त्यसैले त्यो वर्षौंसम्म कार्यविधि पुस्तिकामा टिक्छ।
यो प्रमाणित गर्ने परीक्षण थप्नुहोस्: बाहिरी इन्टरफेसमा क्याप्चर गर्दै जोडिनुहोस्, र ट्रेसमा वास्तवमै देखिने बाहिरी प्रोटोकल र पोर्ट पुष्टि गर्नुहोस्।