NAT मागे SoftEther: थेट ट्राव्हर्सल की VPN Azure रिले?

तुमचा SoftEther सर्व्हर असा प्रदाता राउटरच्या मागे आहे जो तुम्ही बदलू शकत नाही, आणि क्लायंट अजूनही जोडतात, म्हणून तुम्ही गृहीत धरता की रिले सर्व काही वाहतो। ते खरे आहे की नाही हे कोणत्या यंत्रणेने काम केले यावर अवलंबून आहे: DNS नाव, समन्वित UDP मार्ग किंवा रिलेकडे जाणारा बाह्य बोगदा। तिन्ही जोडलेला क्लायंट तयार करू शकतात, आणि ते वेगवेगळ्या परिस्थितीत अयशस्वी होतात। वापरकर्ते किंवा हबला स्पर्श करण्यापूर्वी तुम्ही कोणता मार्ग खरेदी करता ते ठरवा।

तीन यंत्रणा, तीन वेगळी वचने

डायनॅमिक DNS म्हणजे नामकरण। ते होस्टनाव बदलत्या पत्त्याकडे ठेवते जेणेकरून लोक संख्येच्या मागे धावणे थांबवतील, आणि दुसरे काही करत नाही। मूळ NAT ट्राव्हर्सल म्हणजे समन्वय: दोन SoftEther टोक त्यांच्यातील भाषांतर उपकरणांमधून वापरण्यायोग्य UDP मार्ग उघडण्याचा प्रयत्न करतात। VPN Azure एक रिले आहे: सर्व्हर सेवेकडे बाहेर कॉल करतो, आणि क्लायंट रिलेच्या पायाभूत सुविधेवरील होस्टनावाने येतात।

तिन्ही एकमेकांना पूरक आहेत, एकाच वैशिष्ट्याच्या आवृत्त्या नाहीत। तैनाती नामकरण वापरू शकते तर तिचे कनेक्शन प्रत्यक्षात ट्राव्हर्सल किंवा रिलेवर अवलंबून असते।

क्लायंट आणि नेटवर्कवरून ठरवा

निवड क्लायंटपासून सुरू होते, कारण ट्राव्हर्सल फक्त मूळ SoftEther कनेक्शन यंत्रणेत असते। एकाच सर्व्हरवरील OpenVPN, L2TP/IPsec आणि SSTP श्रोते ते वारसा म्हणून घेत नाहीत, जरी एक होस्ट सामायिक करतात। वापरकर्ता काय चालवेल, नंतर नेटवर्क काय परवानगी देते ते पहा। केवळ TCP 443 ला परवानगी देणारे कॉर्पोरेट नेटवर्क तुम्हाला त्या पोर्टवरील रिलेकडे ढकलते, तर ट्राव्हर्सलला आवश्यक UDP पोर्ट पास करू देणारे नेटवर्क थेट मार्गाचा प्रयत्न करू शकते; दोन्ही प्रत्यक्ष इग्रेस धोरणाशी तपासा।

हाताने पोहोचणारा श्रोता जेव्हा प्रशासक एक प्रकाशित करू शकतो तेव्हा अजूनही वैध रचना आहे, परंतु तो स्वतःच्या पत्त्यांकन आणि फायरवॉल कामासह वेगळा प्रकल्प आहे।

सत्राने कोणती वाहतूक निवडली याची खात्री करा

वापरात असलेल्या मार्गासाठी कनेक्शन स्थिती हा एकमेव प्रामाणिक स्रोत आहे। ती सर्व्हरवर वाचा, आणि क्लायंटला मिळालेले होस्टनाव सोडवा।

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList कोणती सत्रे जोडलेली आहेत ते दाखवते, आणि त्यातील एकावरील SessionGet कनेक्शनचा प्रकार सांगते, सत्र रिलेमधून आले का हे देखील। रिलेच्या पायाभूत सुविधेवर सोडवले जाणारे रेकॉर्ड तुम्हाला सांगते की सत्र तिसऱ्या पक्षातून जाते, जे तुम्ही चाचणीत तो मार्ग अडवून पुष्टी करू शकता। मूळ क्लायंटसह, UDP प्रवेग डेटा मार्ग नियंत्रण मार्गापासून दूर नेऊ शकतो, म्हणून एक निरीक्षण संपूर्ण सत्राचे वर्णन करत नाही। पत्ता बदलल्यानंतर जुने झालेले डायनॅमिक DNS नाव, आणि बॅकएंड मार्ग नसतानाही उत्तर देणारे रिले, या दोन स्वतंत्रपणे तपासण्यायोग्य अयशस्वीता पद्धती आहेत। रचनेने जे हेतू धरले ते नाही, तुम्ही जे मोजले ते लिहा।

निवडलेला मार्ग कशावर अवलंबून आहे याची योजना करा

प्रत्येक मार्ग एक अवलंबित्व वाहतो। नेटवर्क संक्रमण किंवा नवीन भाषांतर उपकरणानंतर थेट ट्राव्हर्सल बदलू शकते, तर सेवा किंवा तिचा पोहोचण्यायोग्य पोर्ट अयशस्वी झाल्यास रिले सत्र अयशस्वी होते। दुसऱ्या नेटवर्कवरून पुन्हा जोडा आणि क्लायंटने पडताळलेल्या सर्व्हर ओळखीची खात्री करा, पूर्वी काम करणारा मार्ग त्याच चाचणीत ठेवा। नंतर VPN मागील खाजगी संसाधन तपासा, कारण प्राधिकरण, हब सदस्यत्व, पत्ता वाटप आणि परतीचे मार्ग कोणत्याही परिस्थितीत तुमची जबाबदारी राहतात।

होस्टनाव, प्रोटोकॉल, वैशिष्ट्य सेटिंग्ज आणि निरीक्षित वाहतूक लिहा। तोच चार-भाग रेकॉर्ड पुढील व्यक्तीला काम करणारे कनेक्शन पुन्हा तयार करू देतो।