स्थिर 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 विकल्पहरू।