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 पछाडिको निजी स्रोत परीक्षण गर्नुहोस्, किनकि अधिकार, हब सदस्यता, ठेगाना बाँडफाँट र फिर्ता मार्ग जुनसुकै अवस्थामा तपाईंकै जिम्मेवारी रहन्छ।

होस्टनाम, प्रोटोकल, सुविधाका सेटिङ र अवलोकित यातायात लेख्नुहोस्। त्यही चार-भागको रेकर्डले अर्को व्यक्तिलाई काम गर्ने जडान पुनःउत्पादन गर्न दिन्छ।