AnyConnect की असुरक्षित सर्वर चेतावनी: स्वीकारें या आयात करें?

आप AnyConnect में गेटवे का होस्टनेम चिपकाते हैं, विंडो लाल या सफ़ेद हो जाती है, और एक संवाद पूछता है कि क्या ऐसे सर्वर पर भरोसा करें जिसका प्रमाणपत्र क्लाइंट सत्यापित नहीं कर सकता। स्वाभाविक कदम क्लिक करके काम शुरू करना है, और यही गलत प्रतिक्रिया है। उत्तर उस मशीन पर क्लाइंट की प्राथमिकताओं में लिखा जाता है और आगे के कनेक्शनों पर लागू होता है, इसलिए संवाद एक बार की चेतावनी का वेश धारण किया हुआ कॉन्फ़िगरेशन निर्णय है। क्लाइंट जिस क्रम में दिखाता है, उसी क्रम में मेरा यह रास्ता है।

आप वास्तव में जो चेतावनी देखते हैं, उसी से शुरू करें

लाल और सफ़ेद दिखावटी रूप नहीं हैं। लाल चेतावनी का अर्थ है कि प्रोफ़ाइल या प्राथमिकता असुरक्षित सर्वरों को अवरुद्ध करने पर सेट है, इसलिए वह सेटिंग बदलने तक क्लाइंट आगे बढ़ने से इंकार करता है; सफ़ेद चेतावनी का अर्थ है कि जैसे ही आप स्पष्ट उत्तर देंगे वह आगे बढ़ने देगा। तीसरा मामला समान दिखता है और अलग व्यवहार करता है: समाप्त हो चुका प्रमाणपत्र, जिसे क्लाइंट आयात करने का प्रस्ताव ही नहीं देगा, क्योंकि आयात उसे वैध नहीं बनाएगा। इन तीनों को अलग करने में एक सेकंड लगता है और आगे का सब कुछ तय हो जाता है।

इन सबके पीछे कारणों की एक छोटी सूची है: स्व-हस्ताक्षरित गेटवे प्रमाणपत्र, एक निजी CA जिस पर एंडपॉइंट भरोसा नहीं करता, या एक होस्टनेम जो प्रमाणपत्र के subject alternative names में नहीं है। तीनों में से कोई भी वही संवाद पैदा करता है और अलग सुधार माँगता है।

संवाद का उत्तर देने से पहले प्रमाणपत्र पढ़ें

चेतावनी से प्रमाणपत्र का विवरण खोलें और किसी बटन को छूने से पहले तीन फ़ील्ड देखें। subject और SAN में वही गेटवे होना चाहिए जिस तक आप वास्तव में पहुँचना चाहते थे, जारीकर्ता वह CA होना चाहिए जो आपका संगठन चलाता है, और वैधता की तिथियाँ आज को कवर करनी चाहिए। फिर SHA-256 फ़िंगरप्रिंट की तुलना उस प्रति से करें जो आपने इस कनेक्शन के अलावा कहीं और से ली है, किसी आंतरिक दस्तावेज़ पृष्ठ या टिकट से, क्योंकि उसी संवाद से पढ़ा गया फ़िंगरप्रिंट कुछ भी सिद्ध नहीं करता। यदि स्वतंत्र प्रति न मिले, तो अपवाद स्वीकार करने का आपके पास कोई आधार नहीं है।

यही वह कदम है जो प्रयोगशाला को उत्पादन गेटवे से अलग करता है। कल बनाए गए स्व-हस्ताक्षरित प्रमाणपत्र वाली परीक्षण मशीन पर क्लिक करना उचित है। कॉर्पोरेट गेटवे पर जहाँ उपयोगकर्ता इसके बाद लॉगिन विवरण लिखते हैं, वहाँ जिस प्रमाणपत्र को आप सत्यापित नहीं कर सकते वह संभावित इंटरसेप्शन व्यवस्था है, और क्लाइंट ही एकमात्र घटक है जो अब भी प्रश्न पूछ रहा है।

जानें कि प्रत्येक उत्तर ट्रस्ट स्टोर में क्या लिखता है

आयात के प्रश्न पर हाँ कहने से उस मशीन पर क्लाइंट के विश्वसनीय स्टोर में गेटवे का प्रमाणपत्र जुड़ जाता है। यह प्रति-सत्र अपवाद नहीं है: आगे के कनेक्शन उसी संकेत के बिना पूरे हो सकते हैं, जो उद्देश्य भी है और जोखिम भी, क्योंकि स्क्रीन पर कुछ भी किसी को याद नहीं दिलाता कि अपवाद मौजूद है। ना कहने पर लॉगिन केवल इस सत्र के लिए जारी रहता है। दोनों रास्ते आपको जोड़ते हैं, और उनमें से केवल एक मशीन बदलता है।

यदि आप लाल रास्ते पर हैं, तो पहला प्रयास लॉगिन ही नहीं है। प्रलेखित इनपुट क्रम एक connect पंक्ति और फिर दो पुष्टियाँ है, जो प्राथमिकता बदलता है और बाहर निकल जाता है; जो स्क्रिप्ट इसे सफलता मानती है उसने सेटिंग सहेजी है और कभी प्रमाणीकरण नहीं किया। प्रमाणपत्र आयात का प्रश्न केवल अगले प्रयास में दिखता है, इसलिए लोग मानते हैं कि संकेत अनियमित है।

यह क्रम केवल उँगलियों के लिए नहीं, ऑटोमेशन के लिए महत्वपूर्ण है। जो स्क्रिप्ट उत्तर हमेशा हाँ कहता है वह गेटवे बदलने के बाद भी काम करता रहता है, और आगे जो भी प्रमाणपत्र आए उस पर भरोसा करता रहता है।

उत्तर उसी क्रम में लिखें जिस क्रम में क्लाइंट पूछता है

जब क्लाइंट चेतावनी देता है पर कनेक्शन की अनुमति देता है, उत्तर एक निश्चित क्रम में आते हैं: connect, जारी रखने के लिए हाँ, फिर आयात का प्रश्न, फिर समूह, उपयोगकर्ता नाम और पासवर्ड। संकेतों का समय अनुमान लगाने के बजाय उन्हें इनपुट फ़ाइल में अलग पंक्तियों के रूप में लिखें। आयात से इंकार करना उसी फ़ाइल में एक वर्ण का परिवर्तन है, और बिना निगरानी चलने वाली किसी भी चीज़ के लिए यह अधिक सुरक्षित डिफ़ॉल्ट है।

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

हर स्क्रिप्ट को लीफ़ प्रमाणपत्र स्वीकार करना सिखाने के बजाय संगठन का CA एंडपॉइंट्स पर वितरित करना बेहतर है। सही SAN के साथ विधिवत जारी प्रमाणपत्र सभी के लिए संकेत हटा देता है, सत्यापन को अर्थपूर्ण रखता है, और किसी एक एंडपॉइंट की निर्णय-स्मृति पर निर्भर नहीं करता। रूट CA स्थापित करना लीफ़ आयात करने से भारी परिवर्तन है, इसलिए इसे हेल्प-डेस्क का शॉर्टकट नहीं, प्रबंधित रोलआउट मानें।

अपने गेटवे से अधिक जीने वाले अपवाद हटाएँ

AnyConnect इन प्राथमिकताओं को प्रति मशीन सहेजता है, इसलिए कार्यालय बदलने वाले लैपटॉप पर पुराने उत्तर जमा हो जाते हैं। प्रबंधित एंडपॉइंट्स पर सहेजी गई प्राथमिकताओं और आयात किए गए प्रमाणपत्रों की समीक्षा करें, और देखें कि कोई अपवाद अब भी ऐसे होस्टनेम का नाम लेता है जिसका स्वामी बदल गया है। जो प्राथमिकता किसी भी असुरक्षित सर्वर को स्वीकार करती है वह उस प्रमाणपत्र से व्यापक है जिसके लिए वह बनाई गई थी।

जो पैटर्न बनाए रखने योग्य है वह संकीर्ण है: सामान्य उपयोग के लिए विश्वसनीय प्रमाणपत्र, अस्थायी अपवाद के लिए प्रलेखित आउट-ऑफ़-बैंड फ़िंगरप्रिंट जाँच, और एक नामित स्वामी जो माइग्रेशन समाप्त होने पर उसे हटा देता है। यदि आप किसी प्रबंधित मशीन पर किसी भी सर्वर को स्वीकार करने वाली सामान्य सेटिंग पाएँ, तो उसे सुविधा नहीं, एक खोज मानें।