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 क्लाइंट में कोई अतिव्यापन नहीं है, तो ईमानदार विकल्प स्वीकृत वैकल्पिक सेवा या नियोजित गेटवे परिवर्तन हैं। एक लैपटॉप को संतुष्ट करने के लिए साझा नीति फिर से लिखना, या किसी फ़ोरम उत्तर ने उसका उल्लेख किया इसलिए ऐप खरीदना, अनुकूलता का प्रश्न ठीक वहीं छोड़ देता है जहाँ वह शुरू हुआ था।