SoftEther VPN Azure: रिले पथ, खुला पोर्ट नहीं

आपका सर्वर ऐसे राउटर के पीछे है जिसे आप कॉन्फ़िगर नहीं कर सकते, इसलिए पोर्ट फ़ॉरवर्ड करने की स्पष्ट योजना उपलब्ध नहीं है। VPN Azure ठीक उसी स्थिति के लिए है, और पहले कनेक्शन की दिशा उलटकर उसे हल करता है: सर्वर बाहर एक रिले से जुड़ता है, और क्लाइंट सर्वर के बजाय रिले तक पहुँचते हैं। उस उलटाव को समझना बताता है कि सेवा क्या ठीक करती है और आगे आपको कौन-सी सीमाएँ मिलेंगी।

पथ में क्या बदलता है

पारंपरिक लिसनर में क्लाइंट एक सार्वजनिक पते पर TCP कनेक्शन खोलता है जिसे आपका राउटर सर्वर तक भेजता है। रिले के साथ सर्वर रिले अवसंरचना की ओर एक बहिर्गामी कनेक्शन बनाए रखता है, और रिले क्लाइंट कनेक्शन स्वीकार करके उनका पेलोड प्रतीक्षारत सर्वर तक भेजता है। कोई अंतर्गामी पोर्ट नहीं खोला जाता, स्थिर पता आवश्यक नहीं है, और राउटर अछूता रहता है। फ़ायरवॉल की दृष्टि से सर्वर एक सामान्य बहिर्गामी क्लाइंट है, इसीलिए प्रतिबंधक नेटवर्क इसे अनुमति देते हैं।

रिले उस सर्वर को अपने डोमेन पर एक नाम देता है, और क्लाइंट वहाँ जुड़ने के लिए कॉन्फ़िगर होते हैं।

वह नाम रिले सेवा का है, जो Microsoft Azure VPN Gateway नहीं है, चाहे दोनों को Azure कुछ कहा जाए। उन्हें विनिमेय मानने से ऐसा कॉन्फ़िगरेशन बनता है जो काम नहीं कर सकता।

कौन-से प्रोटोकॉल रिले से पार होते हैं

रिले SoftEther प्रोटोकॉल ले जाता है, और परियोजना SSTP को क्लाइंट विकल्प के रूप में प्रलेखित करती है, जो उपयोगी है क्योंकि Windows के साथ एक SSTP क्लाइंट आता है। परंतु यह होस्ट पर हर लिसनर के लिए सामान्य वाहक नहीं बनता: OpenVPN लिसनर, IPsec उत्तरदाता और L2TP सेवा को अपना-अपना पहुँच-योग्य अंतिम बिंदु चाहिए, और केवल SoftEther सर्वर जुड़ा होने से उनमें से कोई भी रिले से नहीं गुज़रता।

इसलिए क्लाइंट प्रोफ़ाइल सर्वर पते के बजाय रिले नाम की ओर संकेत करते हैं, और सीधे कनेक्शन के लिए बनी मौजूदा प्रोफ़ाइल बिना बदलाव काम नहीं करेगी। रिले जिस प्रोटोकॉल को नहीं ले जाता, उसके चारों ओर डिज़ाइन करने से पहले आप जो संस्करण चलाते हैं उसके लिए समर्थित क्लाइंट सूची देखें।

रिले आपके लिए क्या नहीं करता

रिले एक परिवहन है। यह उपयोगकर्ता, वर्चुअल हब, प्रवेश नीतियाँ या रूट नहीं बनाता, और आपके सर्वर के पीछे के निजी नेटवर्क के बारे में कुछ नहीं जानता। यदि दूरस्थ क्लाइंट को LAN सबनेट तक पहुँचना है, तो सर्वर को अब भी ब्रिजिंग या रूटिंग कॉन्फ़िगरेशन, वापसी पथ और फ़ायरवॉल नीति चाहिए जो इसे संभव बनाती है। दोनों सिरों की अतिव्यापी पता योजनाएँ भी रिले के लिए अदृश्य हैं और आपकी हल करने की समस्या बनी रहती हैं।

समर्थित सुरक्षा सेटिंग्स भी आपके चुनने की हैं। परियोजना दस्तावेज़ में पुराने प्लेटफ़ॉर्म के उदाहरण हैं, और पुराने स्क्रीनशॉट से पुरानी सिफ़र या प्रमाणपत्र सेटिंग्स की नकल करना ऐसा सुरंग बनाने का अच्छा तरीका है जिसका कोई अंकेक्षण नहीं कर सके। आप जो संस्करण चलाते हैं उसके लिए वर्तमान मार्गदर्शन अपनाएँ।

प्रमाणपत्र सत्यापन और उपयोगकर्ता प्रमाणीकरण सर्वर की ही ज़िम्मेदारी रहते हैं, और रिले कभी इनमें से किसी का स्थान नहीं लेता।

इसे निर्भरता के रूप में चलाएँ

उपलब्धता में अब एक तीसरा पक्ष शामिल है। जब रिले पहुँच से बाहर हो, तो आपका सर्वर कितना भी स्वस्थ हो क्लाइंट जुड़ नहीं सकते, और विफलता बाहर से क्लाइंट समस्या जैसी दिखती है। रिले पथ की निगरानी सर्वर के स्वास्थ्य से अलग करें, और जिस दिन यह मायने रखे उस दिन के लिए किसी दूसरे पते पर सीधे लिसनर जैसी प्रलेखित वैकल्पिक योजना रखें।

विलंब आपके उपयोगकर्ताओं की निकटता के बजाय रिले के भूगोल का अनुसरण करता है, जिसे इस पर इंटरैक्टिव प्रदर्शन का वादा करने से पहले मापना उचित है।

सर्वर की पहचान और फिर एक वास्तविक अनुप्रयोग पथ सत्यापित करें, केवल सफल कनेक्शन बैनर नहीं, और जाँचें कि आपको जो संसाधन चाहिए वह रिले जिस पता परिवार को ले जाता है उस पर पहुँच-योग्य है या नहीं। रिले का नाम, प्रयुक्त प्रोटोकॉल और वैकल्पिक योजना लिख लें, क्योंकि ये तीन तथ्य इस लिंक के बारे में अधिकांश भविष्य के प्रश्नों का उत्तर देते हैं।