Mac VPN प्रमाणपत्र लॉगिन: पहचान, कुंजी का उपयोग या गेटवे पर भरोसा?
प्रमाणपत्र आधारित लॉगिन के पीछे तीन निर्णय हैं: कौन-सी पहचान चुनी जाती है, VPN घटक अपनी कुंजी का उपयोग कर सकता है या नहीं, और गेटवे पर भरोसा है या नहीं।
प्रमाणपत्र आधारित VPN लॉगिन Mac से पासवर्ड से अधिक सीमित चीज़ मांगते हैं: इस विशिष्ट निजी कुंजी का, इसी निष्पादन संदर्भ में, उस गेटवे के सामने पहचान सिद्ध करने के लिए उपयोग करो। जब यह विफल होता है, तो संदेश सामान्यतः केवल अंतिम गलत हुई चीज़ का वर्णन करता है, जो शायद ही उसका कारण होता है। सिस्टम जिस क्रम में तीनों निर्णय लेता है उसी क्रम में उनका अनुसरण करने से निदान ईमानदार रहता है, और स्थानीय अनुमति की समस्या को श्रृंखला-सत्यापन विफलता मानने से रोकता है।
लॉगिन को उसी क्रम में चलिए जिस क्रम में Mac चलता है
पहले क्लाइंट एक पहचान चुनता है: उपयोगी निजी कुंजी के साथ जोड़ा गया प्रमाणपत्र, जो समर्थित स्टोर या क्रेडेंशियल प्रदाता के माध्यम से उपलब्ध है। फिर VPN घटक उस कुंजी के साथ क्रिप्टोग्राफ़िक क्रिया करने का अनुरोध करता है, और स्थानीय प्राधिकरण मॉडल उत्तर देता है। दोनों सफल होने के बाद ही दूरस्थ हैंडशेक होता है, जहाँ Mac गेटवे का मूल्यांकन करता है और गेटवे क्लाइंट के प्रमाण का मूल्यांकन करता है।
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
तालिका को ऊपर से नीचे पढ़ें और पहली विफल पंक्ति पर रुक जाएँ। विफलता के नीचे का सब कुछ अप्रमाणित है, इसीलिए “प्रमाणपत्र पर भरोसा नहीं है” इतना सामान्य और इतना अविश्वसनीय निष्कर्ष है।
स्थानीय अनुमति वास्तव में क्या कवर करती है
macOS की कीचेन व्यवस्था में, संरक्षित वस्तुओं के साथ क्रिया-विशिष्ट पहुँच नियम और विश्वसनीय अनुप्रयोगों की सूची होती है। निजी कुंजी से हस्ताक्षर करना उन क्रियाओं में से एक है, और नियम उस निष्पादन योग्य फ़ाइल पर लागू होते हैं जो इसे करती है, दस्तावेज़ के रूप में प्रमाणपत्र पर नहीं। Apple का पहुँच नियंत्रण संदर्भ इस व्यवस्था और iCloud कीचेन तथा पहुँच-समूह व्यवस्थाओं के बीच भी रेखा खींचता है, इसलिए एक के लिए लिखी सलाह दूसरे पर लागू नहीं होती।
इससे दो परिणाम मिलते हैं। सूची में दिखने वाला सार्वजनिक प्रमाणपत्र यह सिद्ध नहीं करता कि VPN का पृष्ठभूमि घटक उस कुंजी तक पहुँच ही सकता है। और फ़्रंट-एंड अनुप्रयोग को दी गई अनुमति किसी अलग हेल्पर या नेटवर्क एक्सटेंशन के बारे में कुछ नहीं कहती, क्योंकि वे अलग पहचान वाला अलग कोड हैं।
पुराने क्लाइंट से निष्पादन योग्य पथ की प्रतिलिपि बनाने के बजाय वास्तविक कार्यान्वयन और उसकी समर्थित क्रेडेंशियल-साझा करने वाली विधि की पहचान करें। पहले यह निश्चित करें कि सिस्टम कौन-सी पहचान प्रस्तुत करेगा:
security find-identity -v -p ssl-clienterrSecInteractionNotAllowed पढ़ना
यह स्थिति Security Server के साथ अस्वीकृत अंतःक्रिया की सूचना देती है, और प्रमाणपत्र श्रृंखलाओं के बारे में कुछ नहीं कहती। इसे उस क्रिया के साथ पढ़ें जिसने इसे उत्पन्न किया: ऐसे संदर्भ से भेजा गया हस्ताक्षर अनुरोध, जो संकेत नहीं दिखा सकता, इसी तरह विफल होगा, भले ही कुंजी और प्रमाणपत्र दोनों पूरी तरह वैध हों। शुरू करने की जगह वह क्रिया है जिसने इसे लॉग किया, प्रमाणपत्र स्टोर नहीं। भरोसा एंकरों के बारे में आप जो भी बदलेंगे, त्रुटि ठीक वहीं रह जाएगी।
इसलिए कोड को निष्पादन संदर्भ और प्राधिकरण जाँचने का कारण मानें। इसे इस प्रमाण के रूप में मानना कि गेटवे का CA अविश्वसनीय है, आपको समस्या के गलत आधे हिस्से में भेजता है, और वहाँ किया गया आपका बदलाव त्रुटि पर बिलकुल असर नहीं डालेगा।
संकीर्ण रूप से सुधारें, व्यापक रूप से नहीं
कनेक्शन के स्वामी के नामांकन या आयात निर्देशों से शुरू करें। क्लाइंट संस्करण, प्रोफ़ाइल का दायरा, चुनी गई पहचान और पहली संबंधित स्थानीय त्रुटि दर्ज करें, क्योंकि ये चार तथ्य ही सहायता हैंडऑफ़ को चाहिए और बाद की तुलना इन्हीं पर निर्भर है। प्रबंधित प्रोफ़ाइल या हार्डवेयर-आधारित पहचान के लिए प्रशासक या प्रदाता को हैंडऑफ़ ठीक करना पड़ सकता है, और स्थानीय क्लिकों की कोई भी मात्रा उसका विकल्प नहीं है।
जहाँ उत्पाद उपयोगकर्ता की स्वीकृति की अपेक्षा करता है, वहाँ निश्चित करें कि कौन-सा घटक मांग रहा है और समर्थित प्रवाह से केवल उसी पहुँच को स्वीकृति दें। जहाँ घटक के पास जिस संदर्भ में वह चलता है वहाँ संकेत उठाने का कोई रास्ता नहीं है, वहाँ प्रावधान को विक्रेता द्वारा प्रलेखित मार्ग का पालन करना होगा, किसी अन्य टर्मिनल विंडो से खींचे गए संवाद का नहीं।
पुरानी सलाह में दो बदलाव एक साथ बाँध दिए जाते हैं, और दोनों बहुत व्यापक हैं। हर अनुप्रयोग को निजी कुंजी तक पहुँच देना स्थानीय कुंजी उपयोग को आवश्यकता से कहीं आगे बढ़ा देता है, और प्रमाणपत्र को Always Trust पर सेट करना मशीन की हर चीज़ के लिए प्रमाणपत्र मूल्यांकन बदल देता है। इनमें से कोई भी “यह स्वीकृत VPN कार्यान्वयन, इसी इच्छित पहचान का उपयोग करते हुए” नहीं कहता।
गेटवे पढ़ने से पहले स्थानीय रूप से जाँचें
सुधार के बाद, पुष्टि करें कि स्थानीय क्रिया सफल होती है दूसरी ओर से आए किसी भी उत्तर की व्याख्या करने से पहले। यदि अब हस्ताक्षर काम करता है, तो बाद में नाम, श्रृंखला या क्लाइंट-प्रवेश का अस्वीकार नया परिणाम है, पुनरावृत्ति नहीं, और यह अलग ज़िम्मेदार वाले अलग निर्णय का है।
उपयोगी हैंडऑफ़ बताता है कि तीन निर्णयों में से कौन-सा विफल हुआ और वहीं रुक जाता है। इसमें कभी निजी कुंजी शामिल नहीं होती, और यह कभी असंबंधित कीचेन वस्तुओं को इस आशा में रीसेट नहीं करता कि स्वच्छ शुरुआत मदद करेगी। इन दो आदतों को घटना के दौरान नहीं, बल्कि पहले तय करें, जब सब कुछ एक साथ आज़माने का लोभ सबसे प्रबल होता है। “कीचेन फिर से बनाया” कहने वाला टिकट अगले पाठक को मूल खराबी के बारे में लगभग कुछ नहीं बताता।