SoftEther VPN Azure: रिले मार्ग, खुला पोर्ट होइन

तपाईंको सर्भर त्यस्तो राउटरको पछाडि छ जसलाई तपाईं कन्फिगर गर्न सक्नुहुन्न, त्यसैले पोर्ट फर्वार्ड गर्ने स्पष्ट योजना उपलब्ध छैन। VPN Azure ठ्याक्कै त्यही अवस्थाका लागि छ, र पहिलो जडानको दिशा उल्टाएर त्यसलाई समाधान गर्छ: सर्भर बाहिर रिलेमा जोडिन्छ, र क्लाइन्टहरू सर्भरको सट्टा रिलेसम्म पुग्छन्। त्यो उल्टाइ बुझ्नाले सेवाले के सुधार्छ र अगाडि तपाईंले भेट्ने हरेक सीमा व्याख्या गर्छ।

मार्गमा के बदलिन्छ

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

रिलेले त्यो सर्भरलाई आफ्नै डोमेनमा नाम दिन्छ, र क्लाइन्टहरू त्यहाँ जोडिनका लागि कन्फिगर हुन्छन्।

त्यो नाम रिले सेवाको हो, जुन Microsoft Azure VPN Gateway होइन, दुवैलाई Azure केही भनिए पनि। तिनलाई अदलबदलयोग्य मान्दा काम गर्न नसक्ने कन्फिगरेसन बन्छ।

कुन प्रोटोकलहरू रिले पार गर्छन्

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

त्यसैले क्लाइन्ट प्रोफाइलहरू सर्भर ठेगानाको सट्टा रिले नामतर्फ सङ्केत गर्छन्, र सिधा जडानका लागि बनाइएको विद्यमान प्रोफाइल परिवर्तन बिना काम गर्दैन। रिलेले नबोक्ने प्रोटोकलको वरिपरि डिजाइन गर्नुअघि तपाईंले चलाउने संस्करणका लागि समर्थित क्लाइन्ट सूची हेर्नुहोस्।

रिलेले तपाईंका लागि के गर्दैन

रिले एक यातायात हो। यसले प्रयोगकर्ता, भर्चुअल हब, पहुँच नीति वा मार्ग बनाउँदैन, र तपाईंको सर्भर पछाडिका निजी नेटवर्कबारे केही जान्दैन। यदि टाढाका क्लाइन्टहरूले LAN सबनेटसम्म पुग्नुपर्छ भने, सर्भरलाई अझै ब्रिजिङ वा राउटिङ कन्फिगरेसन, फर्कने मार्ग र त्यसलाई सम्भव बनाउने फायरवाल नीति चाहिन्छ। दुवै छेउका ओभरल्याप हुने ठेगाना योजनाहरू पनि रिलेका लागि अदृश्य छन् र तपाईंको समाधान गर्नुपर्ने समस्या रहन्छ।

समर्थित सुरक्षा सेटिङहरू पनि तपाईंले छान्ने हुन्। परियोजना कागजातमा पुराना प्लेटफर्मका उदाहरण छन्, र पुरानो स्क्रिनसटबाट पुराना साइफर वा प्रमाणपत्र सेटिङ प्रतिलिपि गर्नु कसैले अडिट गर्न नसक्ने सुरुङ बनाउने राम्रो तरिका हो। तपाईंले चलाउने संस्करणका लागि वर्तमान मार्गदर्शन प्रयोग गर्नुहोस्।

प्रमाणपत्र प्रमाणीकरण र प्रयोगकर्ता प्रमाणीकरण सर्भरकै जिम्मेवारी रहन्छ, र रिलेले कहिल्यै तीमध्ये कुनैको स्थान लिँदैन।

यसलाई निर्भरताका रूपमा चलाउनुहोस्

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

ढिलाइ तपाईंका प्रयोगकर्ताको निकटताको सट्टा रिलेको भूगोल पछ्याउँछ, जुन यसमाथि अन्तरक्रियात्मक प्रदर्शनको वाचा गर्नुअघि मापन गर्न लायक छ।

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