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 के पीछे के निजी संसाधन का परीक्षण करें, क्योंकि प्राधिकरण, हब सदस्यता, पता आवंटन और वापसी मार्ग किसी भी स्थिति में आपकी जिम्मेदारी रहते हैं।

होस्टनाम, प्रोटोकॉल, सुविधा सेटिंग्स और देखा गया ट्रांसपोर्ट लिखें। वही चार-भाग वाला रिकॉर्ड अगले व्यक्ति को काम करने वाला कनेक्शन दोबारा बनाने देता है।