सिमेट्रिक 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 की शब्दावली हाथ में रखें। सटीक शब्दों का उपयोग एक वाक्य का खर्च है और अगले पाठक को वही गलत पहचान दोहराने से रोकता है, और टिप्पणी लिखने का पूरा उद्देश्य यही है।