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 मोड चलाउँछ र कुकीको लाइन मात्र पुनः लेख्छ। प्रमाणहरू स्क्रिप्टबाहिर राख्नुहोस् र तिनलाई चलाउने खातालाई मात्र पढ्न योग्य बनाउनुहोस्, र पुनःलेखनलाई आणविक बनाउनुहोस् ताकि असफल रनले आधा लेखिएको फाइल छाड्ने छैन।
यदि ताजा गर्न हरेक केही घण्टामा आवश्यक पर्छ भने, अन्तराल लेख्नुहोस्। त्यो गेटवेको सत्र नीतिको गुण हो, र ताजा गर्ने काम स्वचालित गर्ने वा लामो सत्र माग्ने भन्ने त्यसैले निर्धारण गर्छ।