Mac VPN प्रमाणपत्र: गेटवे कौन-सा खाता देखता है?
प्रोफ़ाइल लेबल, क्रेडेंशियल और खाता फ़ील्ड अलग-अलग सवालों के जवाब देते हैं। कुछ भी नाम बदलने से पहले प्रिंसिपल से गेटवे की मैपिंग तक जाएँ।
प्रोफ़ाइल आपका नाम दिखाती है, प्रमाणपत्र का दृश्य लेबल कुछ और कहता है, और गेटवे का लॉग एक तीसरा पहचानकर्ता दर्ज करता है। इनमें से कोई झूठ नहीं बोलता, और यही समस्या है: तीन अलग-अलग फ़ील्ड ऐसे पढ़े जा रहे हैं जैसे वे एक ही सवाल का जवाब देते हों। कनेक्शन एक क्रेडेंशियल, एक IKEv2 पहचानकर्ता और एक खाता प्रस्तुत करता है, और गेटवे तय करता है कि इनमें से कौन किसे अधिकृत करता है।
एक कनेक्शन में तीन पहचानें
दृश्य प्रोफ़ाइल नाम लोगों के लिए एक लेबल है। यह कनेक्शन चुनता है और कुछ नहीं। प्रमाणपत्र एक क्रेडेंशियल है, और यह कुछ साबित कर सकता है या नहीं, इस पर निर्भर करता है कि क्लाइंट के पास मेल खाती निजी कुंजी है या नहीं। खाता फ़ील्ड किसी प्रिंसिपल के बारे में एक दावा है, और सर्वर इसे किसी दूसरी स्थानीय पहचान पर मैप करने के लिए स्वतंत्र है।
जब प्रमाणीकरण विफल हो, तो पूछें कि त्रुटि तीनों में से किससे संबंधित है। अस्वीकृत क्रेडेंशियल, अज्ञात पहचानकर्ता और निष्क्रिय खाता अलग-अलग संदेश उत्पन्न करते हैं, और उन्हें एक ही «प्रमाणपत्र समस्या» मानने से आप गलत कंसोल तक पहुँच जाते हैं।
मूल फ़ील्ड को उनके काम के अनुसार पढ़ें
प्रबंधित मूल IKEv2 कॉन्फ़िगरेशन में, Apple का पेलोड संदर्भ मानों को अलग करता है, और प्रमाणीकरण विधि तय करती है कि कौन-सा संयोजन आवश्यक है:
| Field | Identifies | Common misreading |
|---|---|---|
| AuthName | Username for the configured arrangement | Assuming it is the certificate subject |
| LocalIdentifier | IKEv2 client identifier | Assuming it must equal the username |
| PayloadCertificateUUID | Referenced credential payload | Assuming any installed certificate will do |
एक प्रमाणपत्र और एक EAP लॉगिन की एक ही कनेक्शन में अलग-अलग भूमिकाएँ हो सकती हैं। केवल इसलिए कि उनमें से एक ऐसा करता है, हर फ़ील्ड को वही पाठ रखने के लिए बाध्य न करें, और यह न मानें कि एक बदलने से बाकी रद्द हो जाते हैं। किसी तीसरे पक्ष का VPN ऐप पूरी तरह अलग मॉडल दिखा सकता है; मूल फ़ील्ड नाम उसमें ले जाने के बजाय उसके प्रलेखित पहचान-चयन का उपयोग करें।
सर्वर प्रमाणपत्र क्लाइंट पहचान नहीं है
जो प्रमाणपत्र गेटवे को सत्यापित करता है वह विश्वास का स्थिर आधार है। यह साबित करता है कि आप उसी सर्वर तक पहुँचे जिसकी आपको अपेक्षा थी। क्लाइंट पहचान एक अलग वस्तु है: इसमें उस निजी कुंजी तक पहुँच शामिल है जो साबित करती है कि जुड़ने वाला पक्ष वही है जो होने का दावा करता है। किसी दृश्य खाते का नाम बदलना एक को दूसरा नहीं बना सकता।
यहीं एक नेकनियत सुधार गलत हो जाता है। गेटवे का CA प्रमाणपत्र क्लाइंट स्टोर में आयात करने से क्लाइंट प्रमाणीकरण के लिए कुछ नहीं होता, और उस प्रविष्टि को उपयोगकर्ता के नाम से लेबल करने से वह उपयोगकर्ता पहचान नहीं बन जाती। दोनों वस्तुएँ प्रोफ़ाइल के अलग-अलग हिस्सों में रहती हैं और अलग-अलग सवालों के जवाब देती हैं।
प्रिंसिपल से गेटवे की मैपिंग तक जाएँ
पुष्टि करें कि क्रेडेंशियल किसके लिए जारी किया गया था: इस उपयोगकर्ता, इस डिवाइस या किसी साझा भूमिका के लिए। Mac लॉगिन खाता अपने आप वह प्रिंसिपल नहीं है, और किसी दूसरी मशीन से कॉपी किया गया प्रमाणपत्र उसी मशीन की पहचान बनाए रखता है जिसके लिए वह जारी किया गया था।
फिर लेबल नहीं, वास्तविक क्रेडेंशियल की तुलना करें। जारीकर्ता, क्रम संख्या और फ़िंगरप्रिंट आपको और व्यवस्थापक को पुष्टि करने देते हैं कि आप एक ही वस्तु पर चर्चा कर रहे हैं। प्रदर्शित नाम संपादन योग्य होते हैं और अक्सर दोहराए जाते हैं, जिससे किसी घटना के दौरान वे सबसे खराब संभव पहचानकर्ता बन जाते हैं।
अंतिम चरण गेटवे पर है। उसके स्वामी से कहें कि एक कनेक्शन को प्रस्तुत पहचानकर्ताओं और उन्हें उपभोग करने वाले खाता-मैपिंग नियम के साथ सहसंबद्ध करें। क्लाइंट-पक्ष का लेबल यह स्थापित नहीं कर सकता कि सर्वर ने क्या तय किया, और जो नियम किसी प्रमाणपत्र को निष्क्रिय खाते पर मैप करता है वह विफल होगा, जबकि क्लाइंट के सभी फ़ील्ड सही दिखते हैं।
उस परत की मरम्मत करें जिसके पास यह बेमेल है
यदि प्रोफ़ाइल गलत क्रेडेंशियल की ओर इशारा करती है, तो उसका संदर्भ या उसका चयन सुधारें। यदि क्रेडेंशियल किसी अन्य प्रिंसिपल का है, तो लेबल संपादित करने के बजाय जारीकर्ता के पुनः-नामांकन से गुजरें। यदि गेटवे किसी वैध क्रेडेंशियल को गलत खाते से बाँधता है, तो उसके नीति-स्वामी को मैपिंग ठीक करनी होगी। ये तीन अलग-अलग बदलाव हैं, तीन अलग-अलग अनुमोदकों के साथ।
नवीनीकरण भी उसी सावधानी का हक़दार है। प्रमाणपत्र बदलना, उसका दृश्य लेबल बदलना और किसी व्यक्ति को खाता प्रणालियों के बीच ले जाना ज़रूरी नहीं कि मैपिंग को एक ही तरह से प्रभावित करें। लिख लें कि तीनों में से आपने क्या बदला, क्योंकि अगली विफलता क्लाइंट की ओर से एक जैसी और गेटवे लॉग में अलग दिखेगी।
केवल वे न्यूनतम सार्वजनिक पहचानकर्ता साझा करें जिनकी सहायता टीम को आवश्यकता है। निजी कुंजी या पूरा पहचान बंडल कभी उस आदान-प्रदान का हिस्सा नहीं होता, चाहे इससे निदान कितना भी सुविधाजनक हो जाए।