अपने मौजूदा गेटवे के लिए Mac VPN क्लाइंट कैसे चुनें
SSL VPN एक उत्पाद परिवार है, कोई एक प्रोटोकॉल नहीं। गेटवे चलाने वाले से क्लाइंट, प्रोफ़ाइल और साइन-इन विधि पूछें, फिर Mac पर रूट और DNS जाँचें।
डाउनलोड पेज पर छह Mac VPN ऐप दिखाई देते हैं और उनमें से कोई नहीं बताता कि आपके नियोक्ता का गेटवे किसे स्वीकार करेगा। यह स्टोर की कमी नहीं है; यह हैंडऑफ की कमी है। एक SSL VPN एक उत्पाद परिवार है, प्रोटोकॉल नहीं, इसलिए एक जैसी लॉगिन स्क्रीन वाले दो गेटवे अलग क्लाइंट मांग सकते हैं। जब कोई मुझे Mac और सर्वर का पता सौंपता है तो मैं यह क्रम अपनाता हूँ: तय करें कि गेटवे क्या बोलता है, उससे मेल खाता क्लाइंट चुनें, और फिर टनल पर काम का भरोसा करने से पहले रूट और DNS जाँचें।
ऐप स्टोर से नहीं, गेटवे से शुरू करें
ऐप आपके Mac पर चलता है, लेकिन कनेक्शन स्वीकार करके पहुँच देने वाला कुछ और है: एक गेटवे, जिसका संचालक, पता, अनुकूल सेटिंग्स और आपको अधिकृत करने का तरीका हो। मुफ़्त क्लाइंट अच्छा सॉफ़्टवेयर हो सकता है और फिर भी इनमें से कुछ न दे। काम की पहुँच, घर का गेटवे और व्यावसायिक इंटरनेट एग्ज़िट — ये तीन अलग शुरुआती बिंदु हैं जो संयोग से एक ही डाउनलोड पेज साझा करते हैं।
कुछ भी इंस्टॉल या बदलने से पहले सेवा चलाने वाले से चार जवाब लें:
पहुँच मोड: ब्राउज़र पोर्टल, चुने गए ऐप तक पहुँच या पूरा नेटवर्क टनल। यह तय करता है कि आपको क्लाइंट की ज़रूरत है या नहीं।
गेटवे परिवार और समर्थित रिलीज़: उत्पाद, सक्रिय सेवा और ऐसा क्लाइंट संस्करण जो अब भी आपके macOS बिल्ड और Mac हार्डवेयर का समर्थन करे।
प्रमाणीकरण: पासवर्ड के साथ MFA, ब्राउज़र साइन-इन, डिवाइस सर्टिफिकेट या पोस्चर जाँच। स्वीकृत प्रवाह के बिना क्लाइंट जुड़ेगा और फिर अस्वीकार कर दिया जाएगा।
स्वामित्व: भरोसेमंद डाउनलोड या प्रबंधन स्रोत, इच्छित प्रोफ़ाइल और टूटने पर कौन सहायता देता है।
स्वामित्व वह मद है जिसे लोग छोड़ देते हैं। प्रबंधित Mac पर प्रोफ़ाइल अक्सर संगठन की प्रबंधन प्रणाली से आती है, और हाथ से बनाई गई कॉन्फ़िगरेशन अगली जाँच में बदल दी जा सकती है। तीसरे पक्ष का ऐप खोजने से पहले पूछें कि क्या आपसे खुद कुछ इंस्टॉल करने की अपेक्षा है।
SSL VPN परिवार का लेबल है, प्रोटोकॉल नहीं
TLS कनेक्शन की रक्षा कर सकता है जबकि उसके भीतर उत्पाद-विशिष्ट आदान-प्रदान लॉगिन, सेशन आवंटन और टनल ट्रैफ़िक संभालता है। वही आंतरिक आदान-प्रदान क्लाइंट को लागू करना होता है। गेटवे के HTTPS लॉगिन पेज तक पहुँचने वाला ब्राउज़र सर्टिफिकेट श्रृंखला और वेब सर्वर साबित करता है; यह साबित नहीं करता कि कोई असंबंधित VPN ऐप उसी मशीन तक टनल बना सकता है।
OpenConnect मेरे जाने का सबसे स्पष्ट उदाहरण है। इसका अपस्ट्रीम दस्तावेज़ीकरण अलग-अलग गेटवे परिवारों के लिए अलग प्रोटोकॉल मोड गिनाता है और अंतर-संचालन को आधिकारिक विक्रेता समर्थन से अलग रखता है। अगर हर SSL VPN एक ही प्रोटोकॉल बोलता, तो ये मोड अनावश्यक होते।
OpenVPN प्रोफ़ाइल की सीमा दूसरी दिशा में वही है: यह OpenVPN-संगत परिनियोजन के लिए आयात प्रारूप है। TLS को निर्माण खंड के रूप में साझा करना उसे किसी भी एंटरप्राइज़ गेटवे की कॉन्फ़िगरेशन फ़ाइल नहीं बना देता। इसीलिए चलता हुआ ब्राउज़र लॉगिन झूठा सकारात्मक है: पोर्टल पहुँच सफल हो सकती है जबकि कोई टनल न हो, और उठी हुई टनल को बाद में पोस्चर जाँच द्वारा अस्वीकार किया जा सकता है।
क्लाइंट को उससे मिलाएँ जो गेटवे बोलता है
परिवार पता चलते ही चुनाव तेज़ी से सिकुड़ जाता है। यह वह मैपिंग है जो मैं पहले जाँचता हूँ, और आखिरी स्तंभ किसी भी ऐप रेटिंग से अधिक मायने रखता है।
| गेटवे परिवार | macOS पर क्लाइंट | क्या देखें |
|---|---|---|
| IKEv2/IPsec, विक्रेता-निरपेक्ष | .mobileconfig प्रोफ़ाइल के साथ macOS का अंतर्निहित क्लाइंट | सर्वर पहचान, और ऐसी प्रोफ़ाइल जो प्रबंधित हो सकती है |
| OpenVPN 2.x | Tunnelblick या openvpn कमांड लाइन | .ovpn के साथ क्रेडेंशियल; क्लाइंट कोई सेवा नहीं देता |
| WireGuard | आधिकारिक WireGuard क्लाइंट या wireguard-tools | पीयर कॉन्फ़िगरेशन; wg show की दृश्यता क्लाइंट के अनुसार बदलती है |
| विक्रेता SSL VPN (AnyConnect, Pulse, GlobalProtect, F5, Fortinet) | विक्रेता क्लाइंट, या स्पष्ट --protocol के साथ OpenConnect | असमर्थित संयोजन, MFA और पोस्चर जाँच |
| केवल ब्राउज़र पोर्टल | कोई क्लाइंट नहीं | ऐप पहुँच नेटवर्क टनल नहीं है |
दो पंक्तियाँ चेतावनी के योग्य हैं। macOS का अंतर्निहित क्लाइंट वास्तविक IKEv2 कार्यान्वयन है, सामान्य SSL VPN क्लाइंट नहीं: उसके लिए बनी सेवा को सही प्रोफ़ाइल, अपेक्षित सर्वर पहचान और क्रेडेंशियल चाहिए, और प्रबंधित मशीन पर वह प्रोफ़ाइल लॉक हो सकती है। OpenConnect एक ही बाइनरी से कई विक्रेता प्रोटोकॉल कवर करता है, पर उसका अपना प्रोजेक्ट विक्रेता समर्थन का दावा नहीं करता; होस्ट स्कैनिंग, गेटवे द्वारा भेजे गए स्प्लिट-टनल नियम या कोई विशेष SSO प्रवाह केवल विक्रेता क्लाइंट में ही हो सकते हैं।
WireGuard का आकार भी वही है। सेवा पीयर देती है, क्लाइंट टनल देता है, और OpenVPN प्रोफ़ाइल उसका विकल्प नहीं है। macOS की एक सिलवट: App Store क्लाइंट अपनी टनल को नेटवर्क एक्सटेंशन के भीतर रखता है, इसलिए Homebrew टूल से wg show इंटरफ़ेस चालू होने पर भी कुछ नहीं बता सकता। इसके बजाय रूट और ट्रैफ़िक से सत्यापित करें।
कॉन्फ़िगर करें, फिर तय क्रम में सत्यापित करें
एक क्लाइंट और एक प्रोफ़ाइल इंस्टॉल करें, और जो बदला उसका नोट रखें। जुड़ने से पहले आधार रेखा लें ताकि आप बता सकें कि टनल क्या बदलती है:
scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dns
दी गई प्रोफ़ाइल से जुड़ें और वही कमांड दोहराएँ। पूर्ण टनल में डिफ़ॉल्ट रूट utun इंटरफ़ेस की ओर होना चाहिए; स्प्लिट टनलिंग में केवल आंतरिक प्रीफ़िक्स रूट होने चाहिए और आपका सार्वजनिक एग्ज़िट अपरिवर्तित दिखना चाहिए। DNS वह आधा हिस्सा है जो आमतौर पर टूटा रह जाता है: scutil --dns रिज़ॉल्वर को उसी क्रम में सूचीबद्ध करता है जिसमें सिस्टम उनका उपयोग करेगा, और सार्वजनिक रिज़ॉल्वर के नीचे बैठा आंतरिक रिज़ॉल्वर आंतरिक नामों को गलत सर्वर पर भेजेगा।
OpenVPN सेवा के लिए Tunnelblick एक उचित मुफ़्त क्लाइंट है, और उसकी अपनी मार्गदर्शिका छूटे आधे हिस्से के बारे में स्पष्ट है: यह VPN सेवा नहीं देता। आपको दी गई .ovpn फ़ाइल पर डबल-क्लिक करें, Tunnelblick को उसे इंस्टॉल करने दें, और उस पर भरोसा करने से पहले रिलीज़ को अपने macOS संस्करण से जाँचें।
विक्रेता गेटवे के लिए मैं अक्सर कमांड लाइन से OpenConnect से परीक्षण करता हूँ:
brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.com
टूल प्राप्त सर्टिफिकेट छापता है और अज्ञात श्रृंखला पर भरोसा करने से पहले रुकता है; वह संकेत एक विशेषता है, और --servercert pin-sha256:... के साथ पिन करना उस चेतावनी को स्वीकार करने से बेहतर है जिसे आपने पढ़ा नहीं। Ctrl-C टनल तोड़ देता है, क्योंकि फ़ोरग्राउंड openconnect में न किल स्विच है न पुनः-कनेक्ट तर्क। यह नैदानिक सत्र के लिए ठीक है और रोज़ के काम के लिए खराब डिफ़ॉल्ट है।
जब मिलाने के लिए कोई गेटवे न हो
कुछ लोग उलटी समस्या लेकर आते हैं: कोई संचालक नहीं, पता नहीं, सेवा नहीं। मुफ़्त Mac ऐप घर के राउटर पर आने वाली पहुँच नहीं बना सकता। अगर आप होटल से अपना नेटवर्क चाहते हैं, तो किसी को घर पर गेटवे चलाना होगा, उसे पैच रखना होगा, उसका पता प्रकाशित या हल करना होगा और तय करना होगा कि कौन से उपकरण पहुँच योग्य हैं।
अगर आपको निजी नेटवर्क तक पहुँच के बजाय अलग इंटरनेट एग्ज़िट चाहिए, तो क्लाइंट से पहले सेवा चुनें। स्वतंत्र क्लाइंट में खाली प्रोफ़ाइल सूची अक्सर टूटी मुफ़्त सदस्यता नहीं होती; हो सकता है कोई सदस्यता ही न हो और कोई सर्वर जुड़ा न हो। खर्च भी अलग रखें: क्लाइंट लाइसेंस, सेवा योजना और स्वयं चलाया गया गेटवे तीन अलग खरीद हैं।
काम का Mac नीति की परत जोड़ता है। मुफ़्त ऐप जुड़ते हुए भी गलत हो सकता है, क्योंकि स्वीकृत क्लाइंट डिवाइस जाँच या ऐसा प्रमाणीकरण प्रवाह लागू कर सकता है जो विकल्प में नहीं है। असंबंधित ऐप्स के बीच क्रेडेंशियल कॉपी करने के बजाय स्वीकृत विकल्प मांगें, और प्लेटफ़ॉर्म सुरक्षा बंद करने को संगतता का उपाय न मानें।
रिमोट-डेस्कटॉप व्यूअर भी अलग उत्पाद है। यह आपको दूसरे कंप्यूटर पर सत्र दिखाता है; यह आपके Mac के स्थानीय ऐप्स को वह नेटवर्क पथ नहीं देता जो टनल देती है।
पहले असली सत्र से पहले छोटी चेकलिस्ट
गेटवे परिवार और पहुँच मोड लिखित रूप में नाम दें, उनसे मेल खाता क्लाइंट ही इंस्टॉल करें, और इस्तेमाल की गई प्रोफ़ाइल दर्ज करें। फिर असली ट्रैफ़िक से तीन चीज़ें पुष्टि करें: टनल द्वारा स्थापित रूट, रिज़ॉल्वर क्रम, और IP के बजाय नाम से पहुँचा गया एक आंतरिक ऐप।
अगर कुछ विफल हो, तो एक बार में एक चर बदलें: क्लाइंट, प्रोफ़ाइल, प्रमाणीकरण प्रवाह। टनल के शुरू होने से इनकार करते समय लोड होता पोर्टल वेब-सर्वर की समस्या को क्लाइंट-संगतता की समस्या से अलग करता है। जब काम की सेवा जवाब दे और सार्वजनिक पथ अपेक्षा के अनुसार व्यवहार करे, तब आपके पास अनुमानों का ढेर नहीं बल्कि नामित, समर्थित व्यवस्था होती है।