ConnMan OpenConnect कुकी का समाप्त होना, प्रमाणपत्र की समस्या नहीं
लॉग में दो विफलताएँ एक जैसी दिखती हैं। पिन किए गए फ़िंगरप्रिंट की सत्र कुकी से तुलना करें, जिस फ़ील्ड की अवधि समाप्त हुई है उसे ताज़ा करें और फिर डेमॉन को पुनः आरंभ करें।
ConnMan एक दोपहर काम करता है और फिर मना कर देता है, और जर्नल की पंक्ति प्रमाणपत्र सत्यापन का ज़िक्र करती है। वह पंक्ति लोगों को ऐसे CA बंडलों की ओर भेजती है जो कभी टूटे ही नहीं थे। दो अलग-अलग ख़राबियाँ लगभग एक जैसी विफलता उत्पन्न करती हैं: सत्र कुकी की अवधि समाप्त हो जाती है, या सर्वर का प्रमाणपत्र वास्तव में बदल गया है। इन्हें लगभग एक मिनट में अलग किया जा सकता है, और इनमें से केवल एक ही फ़िंगरप्रिंट से जुड़ी है।
दो ख़राबियाँ, एक भ्रमित करने वाली लॉग पंक्ति
ये दो अवलोकनों पर अलग होती हैं, और किसी के लिए भी दूसरी बार पढ़ने की ज़रूरत नहीं है। पहला यह कि विफलता कब शुरू हुई: समाप्त अवधि वाली कुकी घंटों या दिनों के काम के बाद आती है, और बदला हुआ प्रमाणपत्र गेटवे बदलने के ठीक बाद आता है।
| Signal | Expired cookie | Changed certificate |
|---|---|---|
| When it started | after hours or days of working | right after a gateway change |
| Fingerprint from a fresh authenticate | unchanged | different value |
| Usual log tail | HTTP CONNECT 401 / unauthorized | signer not found / verify failed |
| Repair | replace the cookie, restart | re-pin deliberately, then restart |
एक मिनट की परीक्षा नीचे दिया गया authenticate रन है। इसके FINGERPRINT की तुलना फ़ाइल में मौजूद OpenConnect.ServerCert से करें। समान फ़िंगरप्रिंट और अलग COOKIE का अर्थ है केवल कुकी बदलें। अलग फ़िंगरप्रिंट का अर्थ है कि सर्वर का प्रमाणपत्र वास्तव में बदल गया है, इसलिए उसे जानबूझकर फिर से पिन करें और दर्ज करें कि किसने इसे स्वीकृत किया।
सामग्री टाइप करने के बजाय उसे उत्पन्न करें
NetworkManager के विपरीत, ConnMan में OpenConnect प्रोफ़ाइल के लिए कोई आयात चरण नहीं है। यह एक प्रोविज़निंग फ़ाइल पढ़ता है जिसके मान पहले से बनाए जाने चाहिए, और उन्हें बनाने का समर्थित तरीका OpenConnect का authenticate मोड है।
sudo openconnect --csd-wrapper=/home/user/.cisco/csd-wrapper.sh \
--authenticate --user myuser vpn.example.comआउटपुट चार मान छापता है: POST, COOKIE, HOST और FINGERPRINT। sha256: उपसर्ग वाला फ़िंगरप्रिंट सर्वर पिन है। कुकी सत्र आर्टिफ़ैक्ट है जिसकी आयु गेटवे तय करता है। इन्हें अलग प्रकार के रहस्य मानें: इनकी अवधि अलग-अलग समय-सारणियों पर समाप्त होती है, और केवल एक के बदलने की अपेक्षा है।
फ़ाइल दोनों को रखती है, और वे अलग तरह से पुराने होते हैं
प्रोविज़निंग फ़ाइल /var/lib/connman-vpn/ के अंतर्गत रहती है और इसे प्रत्येक कनेक्शन के लिए VPN डेमॉन पढ़ता है, ट्रे एप्लेट नहीं। कनेक्शन का नाम वैश्विक अनुभाग में और प्रोटोकॉल का विवरण प्रदाता अनुभाग में रखें।
[global]
Name = Company VPN
[provider_openconnect]
Type = OpenConnect
Name = Company Cisco VPN
Host = vpn.example.com
Domain = corp.example
OpenConnect.ServerCert = sha256:...
OpenConnect.Cookie = ...वही होस्ट नाम इस्तेमाल करें जो पोर्टल वास्तव में परोसता है। नंगा IP पता प्रमाणपत्र जाँच पास कर सकता है और फिर भी विफल हो सकता है, क्योंकि उपकरण वर्चुअल होस्ट पर रूट करता है और नाम की अपेक्षा करता है।
systemctl status connman-vpn --no-pager # is the daemon even installed and running
sudo systemctl restart connman-vpn # after the file edit
journalctl -u connman-vpn --since '1 hour ago' # after the connection attemptजर्नल वास्तव में क्या दिखाता है
ट्रे टूलटिप नहीं बताएगा कि आपके पास कौन-सी ख़राबी है। जर्नल बताएगा, यदि आप पहली चेतावनी भरी पंक्ति के बजाय क्रम पढ़ें। पुरानी कुकी आम तौर पर दिखाती है कि TLS बातचीत पूरी हुई और HTTP परत ने बाद में अस्वीकार किया; इसीलिए प्रमाणपत्रों के बारे में शब्द किसी प्राधिकरण विफलता के पास खड़े होते हैं।
एक नए authenticate रन की तुलना फ़ाइल के मानों से करें। यदि फ़िंगरप्रिंट मेल खाता है और केवल कुकी अलग है, तो विश्वास सेटिंग्स को छुए बिना आपका उत्तर मिल गया।
जिस फ़ील्ड की अवधि समाप्त हुई है उसे ताज़ा करें
authenticate कमांड दोहराएँ, OpenConnect.Cookie बदलें और डेमॉन पुनः आरंभ करें। फ़िंगरप्रिंट को अकेला छोड़ दें जब तक कि नया आउटपुट भिन्न मान न दिखाए; उस स्थिति में सर्वर का प्रमाणपत्र वास्तव में बदला गया है और फिर से पिन करना ऐसा निर्णय है जिसे किसी को दर्ज करना चाहिए, त्रुटि संदेश से चिपकाना नहीं।
ताज़ा करने को स्वचालित करना उचित है: एक छोटी स्क्रिप्ट मानक इनपुट से पासवर्ड पढ़ती है, authenticate मोड चलाती है और केवल कुकी पंक्ति फिर से लिखती है। क्रेडेंशियल को स्क्रिप्ट से बाहर रखें और केवल उसे चलाने वाले खाते के लिए पठनीय बनाएँ, और फिर से लिखने को परमाणु बनाएँ ताकि विफल रन आधी लिखी फ़ाइल न छोड़े।
यदि ताज़ा करने की ज़रूरत हर कुछ घंटों में हो, तो अंतराल लिख लें। यह गेटवे की सत्र नीति का गुण है, और यह तय करता है कि ताज़ा करने को स्वचालित करना है या लंबा सत्र माँगना है।