प्रोटोकॉल 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 उघडण्याची सूचना कोणीही तपासू शकत नाही, आणि म्हणूनच ती वर्षानुवर्षे कार्यपद्धतीच्या पुस्तकांत टिकते.
हे सिद्ध करणारी चाचणी जोडा: बाहेरील इंटरफेसवर कॅप्चर करताना जोडा, आणि ट्रेसमध्ये प्रत्यक्ष दिसणारे बाहेरील प्रोटोकॉल आणि पोर्ट यांची पुष्टी करा.