स्थिर UDP पोर्ट पोर्ट फॉर्वर्डिंग टाळू शकतात, पण प्रत्येक NAT नाही

दोन घरगुती राउटर, एकही फॉर्वर्ड केलेला पोर्ट नाही, आणि तरीही कधी कधी जोडणारे VPN. UDP हे परवानगी देते, कारण फायरवॉल असे पॅकेट स्वीकारेल जे यंत्राने आधीच सुरू केलेल्या प्रवाहाशी जुळवू शकेल. ही वैशिष्ट्य नसून सशर्त युक्ती आहे, आणि फायरवॉल काय तुलना करतो हे कळल्यावर अटी सांगणे सोपे आहे. एकसारखी प्रोफाइल्स वेगवेगळ्या नेटवर्कवर वेगळी वागतात याचे कारणही हेच आहे.

फायरवॉल जी तुलना करतो

प्रत्येक बाहेर जाणारा डेटाग्राम एक अल्पकालीन नोंद तयार करतो: स्रोत पत्ता, स्रोत पोर्ट, गंतव्य पत्ता, गंतव्य पोर्ट. नोंदीशी जुळणारे जे काही येते त्याला उत्तर मानले जाते आणि जाऊ दिले जाते. इनबाउंड नियमांचा यात काही वाटा नाही.

म्हणून प्रश्न फायरवॉल सोबत्याला आत येऊ देतो का हा नाही. प्रश्न असा आहे की सोबत्याचे पॅकेट नोंद ज्या उत्तराची वाट पाहत आहे तसे दिसते का. त्या चार भागांच्या टपलमधील एक फील्ड बदला आणि पॅकेट अनोळखी होते. म्हणूनच फक्त पोर्ट क्रमांक बदलल्यावर चालणारे सेटअप तुटू शकते, आणि म्हणूनच तोच पोर्ट एका राउटरवर चालून पुढच्यावर अपयशी ठरू शकतो.

स्थानिक स्रोत पोर्ट स्थिर करा, आणि तोच क्रमांक देवाणघेवाणीच्या दोन्ही बाजूंना दिसेल. हीच संपूर्ण क्रियाविधी आहे, आणि युक्ती गूढ नसून नाजूक का आहे हे यावरून स्पष्ट होते.

प्रत्येक टोकावर एक पोर्ट स्थिर करणे

OpenVPN चा डीफॉल्ट UDP पोर्ट 1194 आहे, आणि lport तो कोणत्या पोर्टवरून पाठवतो ते ठरवतो. दोन्ही सोबत्यांना स्थिर करा आणि प्रत्येकाचा बाहेर जाणारा टपल दुसरा ज्या पोर्टवर ऐकत आहे तिकडे निर्देश करेल:

# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194

हे त्यांच्यामधील कोणतेही राउटर स्रोत पोर्ट पुन्हा लिहीत नाही तोपर्यंतच चालते. पॅकेट कॅप्चरमध्ये दिसतात पण बोगदा वर येत नाही, तेव्हा पुनर्लेखन हा पहिला संशयित असतो.

टपल जिथे जुळणे थांबवते

गंतव्यानुसार मॅप करणारा NAT प्रत्येक सोबत्याला वेगळा बाह्य पोर्ट देतो. तुमच्या सोबत्याला वापरण्यास सांगितलेला पत्ता त्याच्यापर्यंत पोहोचणारा पत्ता नाही, त्यामुळे येणारे पॅकेट कोणाशीही जुळत नाही आणि शांतपणे टाकून दिले जाते.

ऑपरेटर-स्तरीय भाषांतर, स्तरित NAT आणि पोर्ट यादृच्छिकीकरण सर्व एकाच पद्धतीने संपतात. पत्ते जसे आहेत तसे ठेवून पोर्ट पुन्हा लिहिणारा कोणताही मधला बॉक्सही तसेच.

स्ट्रीम वाहतुकीची स्थिती अधिक वाईट आहे. TCP हँडशेक टप्प्याटप्प्याने मागोवा घेतला जातो, त्यामुळे TCP-आधारित VPN अशा पद्धतीने अजिबात टोचता येत नाही आणि मार्गावर कुठेतरी ऐकणारा हवा असतो.

सहसा एक बाजू आधी अपयशी ठरते

प्रत्यक्षात दोन्ही नेटवर्क क्वचितच एकसारखी वागतात. एक राउटर अंदाज करता येणारे मॅपिंग देतो, तर दुसरा गंतव्यानुसार पोर्ट देतो, आणि परिणाम म्हणजे दोन घरांमध्ये चालणारे पण मोबाइल नेटवर्कवरून अपयशी ठरणारे कॉन्फिगरेशन. एकमेकांना विरोध करणारे अहवाल सहसा दोन वेगळ्या राउटर जोड्यांचे वर्णन करतात. कोणताही लेखक चुकीचा नाही, आणि कोणताही निकाल सामान्यीकृत होत नाही.

प्रोफाइलना हात लावण्यापूर्वी कोणत्या बाजूने पॅकेट टाकून दिले ते शोधा. दोन्ही टोकांवरील कॅप्चर एकाच प्रयत्नात हे ठरवतात: A मधून निघून B पर्यंत कधीही न पोहोचणारे डेटाग्राम म्हणजे प्रवाह मार्गात पुन्हा लिहिला गेला, तर B पर्यंत पोहोचूनही उत्तर परत न येणारे डेटाग्राम म्हणजे फायरवॉलने ते संबंधित म्हणून स्वीकारले नाहीत.

सार्वजनिक IPv6 पत्ते असलेले दोन सोबती संपूर्ण समस्या टाळतात. भाषांतराशिवाय जुळवण्यासारखे काही नाही, त्यामुळे सोबत्यांची नावे घेणारा फायरवॉल नियम पुरतो आणि रचना राउटरच्या वर्तनावर अवलंबून राहणे थांबवते.

कधी प्रयत्न थांबवावा

सार्वजनिक पत्ता असलेला होस्ट हेच विश्वासार्ह उत्तर आहे. तो दोन्ही सोबत्यांसाठी बोगदा संपवू शकतो, किंवा फक्त एकमेकांचा सध्याचा बाह्य पत्ता शोधण्यास मदत करू शकतो, आणि NAT काहीही करो, दोन्ही व्यवस्था चालतात. धोरण परवानगी देत असल्यास व्यवस्थापित ओव्हरले तेच समन्वय देते.

यापैकी कोणत्याहीला बंद फायरवॉलची गरज नाही. थेट कनेक्शन जिंकण्यासाठी संरक्षण बंद करणे म्हणजे थेट प्रयत्न आकर्षक का होता हे कारण टाकून देणे, आणि चाचणीच्या संपूर्ण कालावधीत यंत्र खुले ठेवणे.

आधी थेट व्यवस्था वापरून पहा, नंतर जे पाहिले ते लिहून ठेवा. NAT चे वर्तन आणि ते दाखवणारे कॅप्चर शेवटी वापरलेल्या पोर्ट जोडीपेक्षा अधिक मूल्यवान आहेत, कारण पुढील नेटवर्क वेगळे असेल. OpenVPN 2.6 मॅन्युअल दस्तऐवजीकरण करते lport आणि हे ज्यावर अवलंबून आहे ते remote पर्याय.