तपाईं कन्फिगर गर्न नसक्ने NAT पछाडिको VPN: अझै के काम गर्छ

प्रत्येक टनेल इन्डपोइन्टलाई अर्को पक्षले पुग्न सक्ने ठेगाना र पोर्ट चाहिन्छ, र तपाईंले प्रशासन नगर्ने राउटर यो आवश्यकता असफल हुनुको सामान्य कारण हो। रोचक कुरा चालहरू हुनु होइन, तर प्रत्येक चाल क्लाइन्टबाट नदेखिने म्यापिङ तालिकाको गुणमा निर्भर हुनु हो। तीमध्ये दुई गुणले लगभग सबै कुरा निर्धारण गर्छन्: म्यापिङ कसरी बन्छ, र भित्री पक्षले कहिल्यै सम्पर्क नगरेको ठेगानाबाट प्याकेट स्वीकार गर्छ कि गर्दैन। वातावरणलाई ती गुणअनुसार वर्गीकरण गर्नुहोस् र उपायहरू लोककथा रहन छोड्छन्।

म्यापिङ तालिकाले सबै कुरा निर्धारण गर्छ

नेटवर्क ठेगाना अनुवादले एउटा तालिका राख्छ जसमा आन्तरिक ठेगाना र पोर्ट सार्वजनिक ठेगाना र पोर्टको अगाडि दर्ता हुन्छन्। रेकर्डसँग मिल्ने जवाफहरू फर्काएर अनुवाद गरिन्छ, र मिल्ने रेकर्ड नभएको बाहिरबाट आउने प्याकेटलाई कुनै गन्तव्य हुँदैन। यही एउटा व्यवहारले राउटर पछाडिको श्रोता इन्टरनेटबाट किन पुग्न नसकिने हो भनी व्याख्या गर्छ। प्रत्येक दिशाको पहिलो प्याकेट भित्रबाटै सुरु हुनुपर्ने कुरा पनि यसले व्याख्या गर्छ।

राउटरको पक्षबाट तालिका हेर्नुहोस् र उपायहरू स्पष्ट हुन्छन्: या त केहीले स्थायी प्रविष्टि बनाउँछ, वा अस्थायी प्रविष्टि बनाएर ताजा राख्छ, वा ट्राफिक त्यो बाटो कहिल्यै जाँदैन। यो लेखको बाँकी भाग ती तीन अवस्था क्रममा हुन्। यहाँ केही पनि तालिकाले दर्ता गर्नेभन्दा बाहिरको विक्रेता सुविधामा निर्भर छैन।

भेटघाट सेवाले के गर्न सक्छ र के गर्न सक्दैन

UDP होल पन्चिङले फिल्टरलाई हराउने सट्टा बाहिर जाने रेकर्डलाई अस्थायी खुला ठाउँको रूपमा प्रयोग गर्छ। दुवै साथीले भेटघाट सेवासँग सम्पर्क गर्छन्, जसले प्रत्येक सार्वजनिक इन्डपोइन्ट जान्छ र अर्को पक्षलाई उसको इन्डपोइन्ट फर्काएर बताउँछ। त्यसपछि दुवै एकअर्कातिर पठाउँछन्, र प्रत्येक बाहिर जाने प्याकेटले जवाफ भित्र आउन दिने रेकर्ड बनाउँछ वा ताजा गर्छ। क्रमले नै यसलाई काम गराउँछ, र क्रमले नै यसलाई नाजुक बनाउँछ: अर्को पक्षले आफ्नो रेकर्ड बनाउनुअघि पठाउने साथी मात्र छोडिन्छ, जबकि क्षणभरपछिको पुनः प्रयास सफल हुन्छ। सेवा आफैले कुनै VPN ट्राफिक बोक्दैन, त्यसैले यसको एकमात्र शक्ति यसले समन्वय गर्ने समय हो।

म्यापिङ व्यवहारले बाँकी निर्धारण गर्छ, र RFC 4787 ले तीन आकार बताउँछ: इन्डपोइन्ट-स्वतन्त्र, ठेगाना-निर्भर, र ठेगाना तथा पोर्ट-निर्भर। अन्तिममा, साथीले लक्ष्य गर्नुपर्ने पोर्ट प्रत्येक गन्तव्यसँग परिवर्तन हुन्छ, त्यसैले अनुमान विश्वसनीय रहँदैन। त्यहीँ यो प्रविधि आफ्नो गतिरोधमा पुग्छ, किनकि क्यारियर-ग्रेड NAT र कडा कर्पोरेट फायरवल दुवैले योजनालाई आवश्यक पूर्वानुमान हटाउँछन्, र कति पटक पुनः प्रयास गरे पनि त्यो फर्किँदैन।

किपअलाइभ, रिबुट र सर्ने इन्डपोइन्ट

प्वाल परेको बाटो श्रोता होइन, प्रवाह हो, त्यसैले त्यसमाथि चल्ने सबैले परिवर्तन सहनुपर्छ। यसले आवधिक ट्राफिकले म्यापिङ जीवित राख्नुपर्छ, सार्वजनिक इन्डपोइन्ट कहिले सर्छ थाहा पाउनुपर्छ, र राउटर रिबुट भएपछि वा ठेगाना पुनः तोकिएपछि पुनः स्थापित हुनुपर्छ। मेस VPN उत्पादनहरूले त्यो तर्क आफ्नै नियन्त्रण तहमा राख्छन्, जबकि साधारण सर्भरले त्यो तपाईंलाई छोड्छ। किपअलाइभले त्यही म्यापिङ टिकेसम्म मात्र मद्दत गर्छ, र मोबाइल क्लाइन्टमा ब्याट्री खान्छ, त्यसैले आक्रामक अन्तराल निःशुल्क हुँदैन।

एक घण्टा सुतेको ल्यापटप सामान्यतया अर्को सार्वजनिक इन्डपोइन्टमा फर्कन्छ। बाटो पुनः स्थापित गर्ने सबैले फेरि भित्रबाट चल्नुपर्छ, जसले त्यही सर्त क्लाइन्टमा फर्काउँछ।

हराएको फर्वार्ड वरिपरि तीन बाटो

पहिलो बाटोले राउटरलाई आफै प्रविष्टि बनाउन भन्छ, UPnP IGD, NAT-PMP वा PCP मार्फत, सुविधा भए र खुला भए। दोस्रोले ट्राफिक सार्वजनिक ठेगाना भएको रिलेलाई सुम्पन्छ, जो सधैं काम गर्छ र सधैं ब्यान्डविथसँगै फरक विश्वास सीमाको खर्च लिन्छ। तेस्रोले दिशा उल्टाउँछ: आन्तरिक होस्टले सार्वजनिक सर्भरतिर बाहिर जाने टनेल खोल्छ र बाँकी सबै त्यसभित्र सवारी गर्छ।

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

रिले इन्डपोइन्टले त्यो साटासाट क्लाइन्ट कन्फिगरेसनमा देखिने बनाउँछ, जहाँ इन्डपोइन्ट साथीको आफ्नै ठेगाना होइन, रिले हो। स्थायी किपअलाइभले म्यापिङ तातो राख्छ, र अनुमति दिइएका प्रिफिक्सले क्लाइन्टले त्यसबाट के पठाउन सक्छ निर्धारण गर्छ। आन्तरिक होस्टबाट उल्टो टनेल अर्को मालिकसँगको उही विचार हो, र यसलाई NAT मा कुनै परिवर्तन चाहिँदैन। तीनमध्ये प्रत्येकले आउने सर्त हटाउँछ, तर डिजाइनअनुसार नमागिएको ट्राफिक रोक्ने फायरवललाई हराउँदैन, किनकि ट्राफिक अझै भित्रबाट सुरु हुन्छ।

उपायलाई राउटरको मालिकसँग मिलाउनुहोस्

यदि तपाईं राउटर प्रशासन गर्नुहुन्छ भने, स्थिर UDP फर्वार्ड कुनै पनि पन्चिङ योजनाभन्दा सजिलै लेखापरीक्षण गर्न सकिन्छ र तपाईंले देख्ने तरिकाले असफल हुन्छ। नगर्नुभए, विक्रेताले रिले वा होस्टेड नियन्त्रण तह दिन्छ कि र नीतिले त्यसको प्रयोग अनुमति दिन्छ कि भनी पत्ता लगाउनुहोस्। दुवै छैनन् भने, बाँकी विकल्प उल्टो टनेल वा इन्डपोइन्ट बाहिरबाट पुग्न नसकिने स्वीकार गर्नु हो। तपाईंले कुन प्रयोग गर्नुभयो भनी दर्ता गर्नु सुन्दा लाग्नेभन्दा महत्त्वपूर्ण छ, किनकि विकल्पहरू ट्राफिक कसले अवलोकन गर्न सक्छ र तेस्रो पक्षले केही बदल्दा के हुन्छ भन्नेमा फरक पर्छन्।

तपाईं पुगेको बाटो सिधा थियो वा रिलेमार्फत, यो ध्यान दिनुहोस्, किनकि यही एउटा तथ्यले ढिलाइ र असफलता व्यवहार दुवैको अनुमान दिन्छ। RFC 4787 यी सबैको तल्लो म्यापिङ व्यवहारको सन्दर्भ रहन्छ, र यसको म्यापिङ खण्ड पढ्नु तीन उपाय क्रममा परीक्षण गर्नुभन्दा छिटो हुन्छ। तालिकालाई तपाईंले कुन विकल्प छान्नुभयो भन्ने मतलब हुँदैन; अर्को प्याकेटले के गर्न सक्छ त्यति मात्र दर्ता गर्छ।