सिमेट्रिक NAT र VPN: लेबल होइन, म्यापिङ नाप्नुहोस्
इन्डपोइन्ट-निर्भर म्यापिङले पियर-टु-पियर खोजीलाई असर गर्छ, सामान्य क्लाइन्ट-देखि-सर्भर टनेललाई होइन। पोर्ट नाप्नुहोस्, र सिधा बाटो असफल भए रिले प्रयोग गर्नुहोस्।
एउटा सहयोग थ्रेड “सिमेट्रिक NAT, यहाँ VPN काम गर्दैन” भन्ने निर्णयमा टुंगिन्छ, अनि क्लाइन्ट कुनै कारणविना तीन पटक पुनः स्थापना गरिन्छ। लेबलले हानि गर्छ किनकि यसले कसैले नसोधेको प्रश्नको उत्तर दिन्छ। बाहिरतिर स्थिर सर्भरसँग जोडिने क्लाइन्टले पहिलो प्याकेट पठाउने क्षणमै म्यापिङ बनाउँछ, र उत्तरलाई लगभग हरेक नेटवर्कले लागू गर्ने नियमअनुसार फर्कन दिइन्छ। इन्डपोइन्ट-निर्भर म्यापिङले साँच्चै जटिल बनाउने कुरा दुई पियरले एकै समयमा एकअर्कासम्म पुग्न खोज्नु हो, र त्यो फरक परीक्षण हो।
एउटा लेबलपछाडि दुई प्रश्न लुकेका छन्
पहिलो प्रश्न यो हो कि यस नेटवर्कपछाडिको होस्टले ज्ञात सार्वजनिक ठेगाना र पोर्टमा सत्र खोल्न सक्छ कि सक्दैन। टनेल क्लाइन्टका लागि यो सामान्य अवस्था हो, र उत्तर लगभग सधैं हुन्छ। राउटरले आन्तरिक स्रोत अभिलेख गर्छ, बाह्य पोर्ट बाँडफाँट गर्छ, र उत्तरलाई जान दिन्छ किनकि त्यो भित्रबाट सुरु भएको सत्रको हो।
दोस्रो प्रश्न यो हो कि फरक नेटवर्कपछाडिका दुई होस्टले बीचमा सर्भरविना साझा बाटो पत्ता लगाएर एकअर्कालाई पठाउन सक्छन् कि सक्दैनन्। त्यो प्रत्येक नेटवर्कले ती बाह्य पोर्ट कसरी बाँडफाँट गर्छ भन्नेमा निर्भर छ, र म्यापिङको व्यवहारको महत्व त्यहीँ मात्र छ।
दुवैलाई मिसाउँदा त्यही पुरानो गलत निदान उत्पन्न हुन्छ: पियर-टु-पियर सुविधा असफल हुन्छ, कसैले NAT-प्रकारको परीक्षण चलाउँछ, सबैभन्दा खराब श्रेणी देख्छ, र सामान्य टनेल पनि काम गर्न सक्दैन भन्ने निष्कर्ष निकाल्छ। असफल भएको कुरा कहिल्यै टनेल थिएन।
म्यापिङ र फिल्टरिङ दुई फरक गुण हुन्
RFC को शब्दावली विक्रेताहरूले प्रयोग गर्ने नामभन्दा बढी सटीक छ, र यसलाई टिकटमा लैजानु उपयुक्त छ किनकि यसले विवाद टुंग्याउँछ। म्यापिङ भनेको बाह्य पोर्ट कसरी बाँडफाँट हुन्छ भन्ने हो। फिल्टरिङ भनेको कुन आउने प्याकेटलाई जान दिइन्छ भन्ने हो। नेटवर्क एउटामा कडा र अर्कोमा उदार हुन सक्छ, र त्यही संयोजन नै पियर-टु-पियर प्रोटोकलले सहनुपर्ने कुरा हो।
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
तेस्रो पङ्क्ति भनेको अधिकांश उपभोक्ता राउटर र मोबाइल अपरेटरहरूले सिमेट्रिक भनेर बुझ्ने कुरा हो। ध्यान दिनुहोस् कि लेबलले बाँडफाँटको मात्र वर्णन गर्छ। त्यस्तो म्यापिङ र उदार फिल्टरिङ भएको नेटवर्कले अझै पनि भर्खरै बाँडफाँट गरेको पोर्टमा आउने प्याकेट स्वीकार गर्न सक्छ, त्यसैले होल-पन्चिङ केहीमा सफल हुन्छ र केहीमा असफल।
फिल्टरिङका आफ्नै तीन अवस्था छन् र प्रत्येकका लागि आफ्नै नाम छ। “ठेगाना र पोर्ट-निर्भर फिल्टरिङ” भन्ने अर्थमा टिकटमा “सिमेट्रिक NAT” लेख्नुले अर्को व्यक्तिलाई पुस्तिकाको गलत अध्यायमा पठाउँछ। दुवै परीक्षणमा फरक व्यवहार गर्छन्, त्यसैले यो गल्ती केवल सैद्धान्तिक होइन।
नाम दिनुको सट्टा म्यापिङ नाप्नुहोस्
तपाईंले नियन्त्रण गर्नुहुने कुनै पनि UDP सेवाको सर्भर पक्षबाट बाँडफाँट गरिएको पोर्ट सिधै अवलोकन गर्न सक्नुहुन्छ। सार्वजनिक होस्टमा क्याप्चर सुरु गर्नुहोस्, क्लाइन्टबाट पठाउनुहोस्, र प्याकेट आएको स्रोत पोर्ट पढ्नुहोस्:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820इन्डपोइन्ट पङ्क्ति तीनमध्ये सबैभन्दा उपयोगी छ, किनकि WireGuard ले प्रत्येक पियरबाट पाएको अन्तिम ठेगाना र पोर्ट अभिलेख गर्छ। त्यो पोर्टलाई क्लाइन्टले प्रयोग गर्छ भन्ने ठान्ने पोर्टसँग तुलना गर्नुहोस्। जब जहिले कुनै अनुवाद हुन्छ ती फरक हुनेछन्, र महत्वपूर्ण प्रश्न यो हो कि मान स्थिर रहन्छ कि रहँदैन।
दोस्रो गन्तव्य पोर्ट वा दोस्रो सर्भरविरुद्ध अवलोकन दोहोर्याउनुहोस् र फेरि तुलना गर्नुहोस्। यदि बाह्य पोर्ट गन्तव्यअनुसार बदलिन्छ भने म्यापिङ ठेगाना र पोर्ट-निर्भर हुन्छ। यदि त्यो उही रहन्छ भने नेटवर्कले एउटै म्यापिङ दिन्छ र खोजीसँग अवसर हुन्छ।
STUN-आधारित उपकरणहरूले एउटै वर्गीकरण एकै चरणमा जानकारी दिन्छन्, र नेटवर्कले सार्वजनिक STUN सर्भरतर्फ बाहिर जाने UDP लाई अनुमति दिँदा ती प्रयोग गर्न उपयुक्त हुन्छ। अनुमति नदिँदा माथिको क्याप्चर विधि अझै काम गर्छ र तपाईंको नियन्त्रणमा पहिले नै रहेको होस्टबाहेक केही चाहिँदैन।
असफलतासँग मिल्ने उपाय छान्नुहोस्
यदि असफल हुने सुविधा पियर-टु-पियर हो भने समर्थित उत्तरहरू रिले, दुवै पियर पुग्न सक्ने भेट सेवा, वा फरक टोपोलोजी हुन्। TURN ठ्याक्कै यसैका लागि छ, र आफ्नै रिले समावेश गर्ने उत्पादनले तपाईंलाई केही नेटवर्क शत्रुतापूर्ण हुने अपेक्षा गरेको बताउँछ।
यदि असफल हुने सुविधा सामान्य टनेल हो भने म्यापिङको व्यवहार तपाईंको समस्या होइन र माथिको कुनै पनि लागू हुँदैन। क्लाइन्टले साँच्चै पठाइरहेको छ, सर्भरले प्याकेट देखिरहेको छ, र उत्तर फर्किरहेको छ भनी जाँच्नुहोस्। त्यो क्रम तीन अवलोकन हो र यसलाई राउटरको NAT श्रेणीबारे केही जान्न आवश्यक पर्दैन।
जुन काम गर्दैन त्यो हो केही जोडिनुअघि स्थानीय पोर्ट परिवर्तनहरू छर्नु। क्लाइन्टको स्रोत पोर्ट बदल्नुले नेटवर्कले म्यापिङ कसरी बाँडफाँट गर्छ भन्ने बदल्दैन। पाँचौं प्रयासमा संयोगवश सफलता झुटो सकारात्मक हो, र महिनौंसम्म यसलाई उपाय भनी उद्धृत गरिनेछ।
निर्णय होइन, संरचना अभिलेख गर्नुहोस्
उपयोगी टिप्पणीले कुन प्रोटोकल, सत्र कुन दिशामा सुरु हुन्छ, बाटोमा रिले छ कि छैन, र तारमा के अवलोकन गरियो भनी बताउँछ। “सिमेट्रिक NAT, काम गर्दैन” निरर्थक छ, किनकि यो एकै समयमा टनेलबारे गलत छ र पियरको बाटोबारे जानकारी दिँदैन।
यदि तपाईंले परीक्षण गर्नुभयो भने नापिएको पोर्ट स्थिरता र फिल्टरिङको व्यवहार समावेश गर्नुहोस्। यी दुई तथ्यले अरूलाई पूरै अन्वेषण दोहोर्याउनु नपरी नयाँ सुविधा त्यो नेटवर्कमा चल्ने हो कि होइन भनी अनुमान गर्न दिन्छ। प्रत्येक सहायता पृष्ठमा अलि फरक अर्थ राख्ने विक्रेता-श्रेणीभन्दा ती राम्ररी पुराना पनि हुन्छन्।
अन्तमा, यो लेख्दा RFC 4787 को शब्दावली हातमा राख्नुहोस्। सटीक शब्द प्रयोग गर्न एक वाक्यको खर्च हुन्छ र यसले अर्को पाठकलाई त्यही गलत निदान दोहोर्याउनबाट रोक्छ, र टिप्पणी लेख्नुको पूरै उद्देश्य त्यही हो।