प्रमाणपत्र बदलल्यानंतर 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दुरुस्तीनंतर एक नव्हे तर दोन गोष्टी पडताळा: पोर्टल सुरुंगातून लोड होते, आणि सामान्य अंतर्गत पत्ता प्रतिसाद देतो। पूर्ण झालेला हस्तांदोलन फक्त हे सिद्ध करतो की विश्वासाचा निर्णय स्वीकारला गेला।