Mac मा SonicWall VPN: SSL क्लाइन्ट वा मूल L2TP?

Mac बाट सुरु गरी बाहिरतिर लाग्नुहोस्, किनकि क्लाइन्टको निर्णय फायरवालले लिन्छ र त्यो डेस्कटपमा मात्र प्रतिबिम्बित हुन्छ। सिस्टम सेटिङ खोल्नुहोस्, पहिले नै कुन VPN कन्फिगरेसन छ हेर्नुहोस्, र पासवर्ड टाइप गर्नुअघि प्रशासकलाई एउटा प्रश्न सोध्नुहोस्। उत्तर सक्षम रिमोट-एक्सेस सेवा हो, लगइन पृष्ठको उपकरण मोडेल होइन। एउटै ल्यापटपमा दुई क्लाइन्ट हुन सक्छन् र तीमध्ये कुनै पनि सही नहुन सक्छ।

कुन सेवा खुला छ गेटवेलाई सोध्नुहोस्

एउटै उत्पादन नाममुनि दुई रिमोट-एक्सेस सेवा देखिन्छन् र ती पूर्ण रूपमा फरक व्यवहार गर्छन्। एउटा SSL VPN हो जहाँ विक्रेताको क्लाइन्टले पुगिन्छ, र अर्को IPsec वा L2TP हो जसलाई macOS को अन्तर्निहित क्लाइन्टले डायल गर्न सक्छ। ती पोर्ट, प्रमाणीकरण र ठेगाना वितरणमा भिन्न छन्, त्यसैले एउटाको प्रोफाइल अर्कोसामु बेकार छ। Mac पक्षबाट मात्र छान्नु कन्फिगरेसनको पोशाकमा अनुमान हो।

एकैचोटि तीन कुरा माग्नुहोस्: इजाजतपत्र प्राप्त र सक्षम सेवा, त्यो सेवाले macOS मा समर्थन गर्ने क्लाइन्ट र संस्करण, र त्यसले अपेक्षा गर्ने प्रमाणीकरण प्रवाह। यसभन्दा कमले अर्को असफलतामा तपाईंलाई अनुमान गर्न छोड्छ।

मूल L2TP को बाटो हिँड्नुहोस्

Mac मा प्रोफाइल थपिएको हरेक बेला मूल जडान हुन्छ, र सेटिङ प्यानलले त्यसलाई Wi-Fi र Ethernet को छेउमा देखाउँछ। सूची खाली भएमा मेसिनमा कुनै पनि VPN कन्फिगरेसन छैन र समस्या जडानमा होइन, व्यवस्थामा छ। तलको आदेशले इन्टरफेसले लुकाउन सक्ने कन्फिगरेसनसमेत गरी प्रणालीले वास्तवमै के राख्छ छाप्छ।

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

scutil --nc list
networksetup -listallnetworkservices

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

SSL क्लाइन्टको बाटो हिँड्नुहोस्

SSL VPN क्लाइन्ट TLS मार्फत पोर्टलमा जडान हुन्छ, त्यसपछि आफ्नै सुरुङ र आफ्नै ठेगाना नीति चलाउँछ। यसलाई पोर्टलको ठेगाना, खाता र परिनियोजनले लाद्ने दोस्रो कारक चाहिन्छ, र यसले पहिलो पटक चल्दा सामान्यतया सञ्जाल विस्तार स्थापना गर्छ। एउटा क्लाइन्टका लागि निर्यात गरिएको प्रोफाइल अर्कोमा आयात हुने कुरा दुर्लभ छ, दुवैले तल IPsec बोले पनि। विस्तार स्वीकृत नभएसम्म यीमध्ये केही पनि सिस्टम सेटिङको VPN सूचीमा देखिँदैन।

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

स्थापना गर्नुअघि macOS संस्करणलाई विक्रेताको हालको समर्थन वक्तव्यसँग जाँच्नुहोस्, र इन्स्टलरले गोपनीयता र सुरक्षामा स्वीकृति माग्ने अपेक्षा गर्नुहोस्। अवरुद्ध विस्तार कहिल्यै सुरु नहुने जडानजस्तै देखिन्छ।

रिब्रान्डिङ सूचना ठीकसँग पढ्नुहोस्

क्लाइन्टका नाम सर्छन्, र नाम बदल्नु प्रोटोकल परिवर्तन होइन। विक्रेताको सूचना कि Mobile Connect अब NetExtender बन्दै छ ब्रान्डिङ वर्णन गर्छ, त्यसैले डेस्कटप प्लेटफर्म समर्थनबारे पुरानो वक्तव्य नयाँ नाम भएको हरेक एपमा सार्न सकिँदैन।

तपाईंले वास्तवमै स्थापना गरेको क्लाइन्टलाई बन्डल पहिचानकर्ता र संस्करणद्वारा चिन्नुहोस्, आइकनको लेबलद्वारा होइन। त्यो भिन्नताले तपाईंको Mac मा कुन समर्थन म्याट्रिक्स लागू हुन्छ निर्धारण गर्छ।

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