प्रमाणपत्र परिवर्तन गरेपछि OpenConnect ले गेटवेलाई किन अस्वीकार गर्छ?
गेटवेको प्रमाणपत्र परिवर्तनपछिको प्रमाणीकरण असफलता विश्वासको निर्णय हो, बिग्रिएको सुरुङ होइन। जारी गर्ने CA र एउटै कुञ्जी पिन गर्नेबीच छान्नुहोस्।
गेटवेहरू प्रमाणपत्रहरू परिवर्तन गर्छन्, र हिजोसम्म जोडिएको क्लाइन्ट पहिलो TLS आदानप्रदानमा रोकिन थाल्छ। सन्देशले नेटवर्क खराबी नभई प्रमाणीकरणको कारण बताउँछ, र मेसिन आफै परिवर्तन भएको छैन, यही उपयोगी सङ्केत हो। टुटेको कुरा अहिले प्रस्तुत गरिएको प्रमाणपत्र र क्लाइन्ट विचार गर्न तयार भएका मूलहरूबीचको सम्बन्ध हो। यसलाई मर्मत गर्नु विश्वासको निर्णय हो, त्यसैले विकल्प लेख्नु अघि त्यो निर्णय लिनुहोस्।
कुनै पनि विश्वास सेटिङ परिवर्तन गर्नु अघि असफलता पढ्नुहोस्
अनुपस्थित हस्ताक्षरकर्ता जस्तो त्रुटिको अर्थ शृंखला क्लाइन्टले स्वीकार नगर्ने कुनै कुरामा टुट्छ। त्यो आन्तरिक अधिकारीको नवीकृत प्रमाणपत्र, सार्वजनिक अधिकारीको प्रतिस्थापन, वा बीचमा रहेको यन्त्रले आफ्नै प्रमाणपत्र प्रस्तुत गरेको हुन सक्छ। केवल शब्दावलीले ती अवस्थाहरू छुट्याउन सक्दैन, त्यसैले निर्णय गर्नु अघि जारीकर्तालाई हेर्नुहोस्।
जडान एक पटक अग्रभागमा चलाउनुहोस् र असफल हुन दिनुहोस्, किनकि अन्तरक्रियात्मक आउटपुटमा सर्भर नाम, जारीकर्ता शृंखला र क्लाइन्टले गणना गरेको फिङ्गरप्रिन्ट हुन्छ। त्यो जारीकर्तालाई तपाईंको संस्थाले साँच्चै सञ्चालन गर्ने अधिकारीसँग तुलना गर्नुहोस्। फिङ्गरप्रिन्ट परिवर्तन भयो तर जारीकर्ता भएन भने, तपाईं पहिले नै विश्वास गर्ने माध्यमबाट नवीकरण पुष्टि नहुन्जेल यसलाई शंकास्पद मान्नुहोस्। यो बिन्दुमा अनुमान गर्नु भनेको अन्ततः कसैले बीचमा आउनेको कुञ्जी पिन गर्ने बाटो हो।
त्यही टिप्पणीमा क्लाइन्ट संस्करण लेख्नुहोस्। विश्वासको समस्या जस्तो देखिने धेरै असफलता पुरानो क्लाइन्टले नयाँ गेटवे आदानप्रदान सामना गर्दा आउँछन्।
जारीकर्तामा विश्वास गर्ने र एउटा कुञ्जी पिन गर्नेबीच छान्नुहोस्
दुवै विकल्पले जडान सफल बनाउँछन्। ती पछि विपरीत तरिकाले टुट्छन्, त्यसैले छनोट तपाईं सहन सक्ने असफलताको हो।
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
प्रमाणपत्र तपाईं स्वतन्त्र रूपमा प्रमाणित गर्न सक्ने अधिकारीबाट आएको भए CA फाइलतिर जानुहोस्, किनकि नवीकरणहरू क्लाइन्टका आर्गुमेन्ट छुनु बिना काम गरिरहन्छन्। यसलाई प्रणालीका मूलहरू अक्षम गर्ने स्विचसँग जोड्नुहोस्, नभए सार्वजनिक अधिकारीले तपाईंको तर्फबाट जाँच पूरा गर्न सक्छ। यसको सट्टा गेटवेसँग प्राप्त गर्न सकिने CA नभए वा सकेसम्म साँघुरो अपवाद लक्ष्य भए पिन गर्नुहोस्। कुनै पनि मार्ग अमूर्त रूपमा बढी सुरक्षित छैन: CA नवीकरणहरूभरि विस्तार हुन्छ, पिन समीक्षा गर्न सजिलो छ।
तपाईं जुनसुकै छान्नुहोस्, विश्वस्त मान परिवर्तन हुनु अघि विश्वस्त रहेको माध्यमबाट आउनुपर्छ। प्रशासक, गेटवेमा कन्सोल सत्र, वा अग्रिम रूपमा लिइएको प्रतिलिपि सबै योग्य छन्। प्रम्प्टले देखाउने जुनसुकै फिङ्गरप्रिन्ट प्रतिलिपि गर्नु सुविधाजनक छ र बीचमा आउनेले ठ्याक्कै त्यही आशा गर्छ।
तपाईंले साँच्चै सुरु गर्ने कमाण्डमा मान राख्नुहोस्
पिन सर्भर-प्रमाणपत्र विकल्पमा जान्छ, र त्यसको उपसर्गले इन्कोडिङ निर्धारण गर्छ: sha1 वा sha256 अन्तर्गत हेक्साडेसिमल सार्वजनिक-कुञ्जी डाइजेस्ट, र pin-sha256 अन्तर्गत base64 कुञ्जी पिन। यो दिँदा त्यो पटकका लागि प्रणालीको विश्वास पनि अक्षम हुन्छ, त्यसैले पिन गरिएको कुञ्जी नै पूरै निर्णय बन्छ।
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trustक्लाइन्टले काटिएको डाइजेस्ट मिलाउँछ, उपसर्गपछि चार अक्षर मात्रै पनि स्वीकार गर्छ, जुन सुविधा नभई जाल हो। छोटो गरिएको मान स्थानीय रूपमा पास हुन्छ र अझै तपाईंले लक्ष्य गरेको गेटवे पहिचान गर्दैन। सन्देशबाट फेरि टाइप गर्नुको सट्टा क्लाइन्टले पहिलो प्रयासमा छापेको पूरा स्ट्रिङ प्रतिलिपि गर्नुहोस्। त्यसपछि तयार विकल्पलाई जडान सुरु गर्ने र्यापर स्क्रिप्ट, युनिट फाइल वा प्रोफाइलमा सार्नुहोस्, ताकि विश्वासको निर्णय समीक्षायोग्य रहोस् र पछिका सम्पादन जानाजानका हुन्।
डेस्कटप लन्चर र NetworkManager प्लगइनले जडान आर्गुमेन्टको आफ्नै प्रतिलिपि राख्छन्। डिस्कमा सम्पादित स्क्रिप्ट अघि आयात गरिएको प्रोफाइलसम्म पुग्दैन, त्यसैले भण्डारण गरिएको मान जितिरहन्छ।
आफूलाई बाहिर ताल्चा नलगाई रोलओभर सम्हाल्नुहोस्
विकल्प एक पटकभन्दा बढी दिन सकिन्छ, त्यसैले योजनाबद्ध परिवर्तनले बाहिर जाने र भित्र आउने कुञ्जी सँगै स्वीकार गर्न सक्छ। गेटवे परिवर्तन हुनु अघि नयाँ पिन थप्नुहोस्, सत्रहरू स्थानान्तरण हुँदा दुवैलाई सूचीमा राख्नुहोस्, र पुरानो कुञ्जी गएपछि अवकाश लिएको हटाउनुहोस्। त्यो झ्याललाई मालिक चाहिन्छ, किनकि बिर्सिएको दोहोरो पिनले कुञ्जीलाई कसैले नहेरी विश्वस्त राख्छ। नयाँ कुञ्जी जोडी उत्पादन गर्ने पुनर्निर्माणले शुद्ध पिन तोड्छ, र पुनःप्राप्ति उल्टो दिशामा त्यही प्रक्रिया हो।
पिनको छेउमा परिवर्तनको मिति लेख्नुहोस्। समीक्षा मिति नभएको पिन भ्रमित गर्ने त्रुटि सन्देश बोकेको भविष्यको अवरोध हो।
विश्वास सम्पादन गर्नु अघि क्लाइन्ट संस्करण बहिष्कृत गर्नुहोस्
पुरानो क्लाइन्टले गेटवेले त्यसपछि परिवर्तन गरेको प्रमाणीकरण प्रतिक्रिया पार्स गर्दा असफल हुन सक्छ, र सतहको सन्देश अझै पार्सरको सट्टा जडानको कुरा गर्छ। स्थापित संस्करणलाई गेटवेले अभिलेख गर्ने कुरासँग तुलना गर्नुहोस्, र कुनै पनि विश्वास सेटिङ परिवर्तन गर्नु अघि हालको प्याकेज एक पटकको प्रोफाइलमा परीक्षण गर्नुहोस्।
openconnect --versionमर्मतपछि एक होइन, दुई कुरा प्रमाणित गर्नुहोस्: पोर्टल सुरुङबाट लोड हुन्छ, र सामान्य आन्तरिक ठेगानाले जवाफ दिन्छ। पूरा भएको ह्यान्डशेकले विश्वासको निर्णय स्वीकारिएको मात्र प्रमाणित गर्छ।