सिमेट्रिक 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 ची परिभाषा हाताशी ठेवा। अचूक शब्द वापरण्याचा खर्च एक वाक्य आहे आणि तो पुढील वाचकाला तेच चुकीचे निदान पुन्हा करण्यापासून थांबवतो आणि टीप लिहिण्याचा संपूर्ण हेतू तोच आहे।