SoftEther VPN Azure: रिले मार्ग, उघडे पोर्ट नाही

तुमचा सर्व्हर अशा राउटरच्या मागे आहे ज्याची तुम्ही कॉन्फिगरेशन करू शकत नाही, त्यामुळे पोर्ट फॉरवर्ड करण्याची स्पष्ट योजना उपलब्ध नाही. VPN Azure त्याच परिस्थितीसाठी आहे, आणि पहिल्या कनेक्शनची दिशा उलटून ते सोडवते: सर्व्हर बाहेर रिलेकडे जोडतो, आणि क्लायंट सर्व्हरऐवजी रिलेपर्यंत पोहोचतात. त्या उलटण्याची समज सेवा काय दुरुस्त करते आणि पुढे तुम्हाला कोणत्या मर्यादा भेटतील हे स्पष्ट करते.

मार्गात काय बदलते

पारंपरिक श्रोत्यासह क्लायंट एका सार्वजनिक पत्त्यावर TCP कनेक्शन उघडतो जे तुमचा राउटर सर्व्हरकडे पाठवतो. रिलेसह सर्व्हर रिले पायाभूत सुविधांकडे बाहेर जाणारे कनेक्शन टिकवतो, आणि रिले क्लायंट कनेक्शन स्वीकारून त्यांचा भार प्रतीक्षा करणाऱ्या सर्व्हरकडे पाठवतो. कोणतेही आंतर्गामी पोर्ट उघडले जात नाही, स्थिर पत्ता आवश्यक नाही, आणि राउटर अस्पर्शित राहतो. फायरवॉलच्या दृष्टिकोनातून सर्व्हर सामान्य बहिर्गामी क्लायंट आहे, म्हणूनच निर्बंधक नेटवर्क ते मंजूर करतात.

रिले त्या सर्व्हरला स्वतःच्या डोमेनवर नाव देते, आणि क्लायंट तिथे जोडण्यासाठी कॉन्फिगर होतात.

ते नाव रिले सेवेचे आहे, जी Microsoft Azure VPN Gateway नाही, दोघांनाही Azure काहीतरी म्हटले जात असले तरी. त्यांना अदलाबदलयोग्य मानल्यास काम करू शकत नाही असे कॉन्फिगरेशन तयार होते.

कोणते प्रोटोकॉल रिलेमधून जातात

रिले SoftEther प्रोटोकॉल वाहून नेते, आणि प्रकल्प SSTP ला क्लायंट पर्याय म्हणून नोंदवतो, जे उपयुक्त आहे कारण Windows सोबत SSTP क्लायंट येतो. पण तो होस्टवरील प्रत्येक श्रोत्यासाठी सामान्य वाहक होत नाही: OpenVPN श्रोता, IPsec प्रतिसादक आणि L2TP सेवा या प्रत्येकाला स्वतःचा पोहोचण्यायोग्य अंतिम बिंदू हवा, आणि केवळ SoftEther सर्व्हर जोडलेला असल्यामुळे त्यातील कोणीही रिलेमधून जात नाही.

म्हणून क्लायंट प्रोफाइल सर्व्हर पत्त्याऐवजी रिले नावाकडे निर्देश करतात, आणि थेट कनेक्शनसाठी बनवलेले विद्यमान प्रोफाइल बदलाशिवाय काम करणार नाही. रिले वाहून नेते नाही अशा प्रोटोकॉलभोवती रचना करण्यापूर्वी तुम्ही चालवत असलेल्या आवृत्तीसाठी समर्थित क्लायंटची यादी पहा.

रिले तुमच्यासाठी काय करत नाही

रिले हे वाहतूक आहे. ते वापरकर्ते, व्हर्च्युअल हब, प्रवेश धोरणे किंवा मार्ग तयार करत नाही, आणि तुमच्या सर्व्हरमागील खाजगी नेटवर्कबद्दल काहीही जाणत नाही. दूरस्थ क्लायंटना LAN उपजाळपर्यंत पोहोचायचे असल्यास, सर्व्हरला अजूनही ब्रिजिंग किंवा राउटिंग कॉन्फिगरेशन, परतीचा मार्ग आणि ते शक्य करणारे फायरवॉल धोरण लागते. दोन्ही टोकांवरील आच्छादक पत्ता योजनाही रिलेसाठी अदृश्य असतात आणि तुमची सोडवायची समस्या राहतात.

समर्थित सुरक्षा सेटिंग्जही तुमच्या निवडीच्या आहेत. प्रकल्प दस्तऐवजीकरणात जुन्या प्लॅटफॉर्मची उदाहरणे आहेत, आणि जुन्या स्क्रीनशॉटमधून जुनी सिफर किंवा प्रमाणपत्र सेटिंग्ज कॉपी करणे हे कोणीही लेखापरीक्षण करू शकत नाही अशी बोगदा बांधण्याचा चांगला मार्ग आहे. तुम्ही चालवत असलेल्या आवृत्तीसाठी सध्याचे मार्गदर्शन वापरा.

प्रमाणपत्र पडताळणी आणि वापरकर्ता प्रमाणीकरण सर्व्हरचीच जबाबदारी राहते, आणि रिले कधीही यापैकी कोणाचीही जागा घेत नाही.

त्याला अवलंबन म्हणून चालवा

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

विलंब तुमच्या वापरकर्त्यांच्या जवळपासऐवजी रिलेच्या भूगोलाचे अनुसरण करतो, जे त्यावर इंटरॅक्टिव्ह कार्यक्षमतेचे वचन देण्यापूर्वी मोजण्यासारखे आहे.

सर्व्हरची ओळख आणि नंतर वास्तविक अनुप्रयोग मार्ग तपासा, केवळ यशस्वी कनेक्शन बॅनर नाही, आणि तुम्हाला आवश्यक असलेला स्रोत रिले वाहून नेते त्या पत्ता कुटुंबावर पोहोचण्यायोग्य आहे का ते तपासा. रिलेचे नाव, वापरलेला प्रोटोकॉल आणि पर्यायी योजना नोंदवा, कारण ही तीन तथ्ये या दुव्याबद्दलच्या बहुतेक भविष्यातील प्रश्नांची उत्तरे देतात.