दो घरेलू राउटर, कोई फ़ॉरवर्ड किया गया पोर्ट नहीं, और एक 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 विकल्प जिन पर यह निर्भर है।

संबंधित लेख