ConnMan एक दुपार काम करतो आणि नंतर नकार देतो, आणि जर्नलची ओळ प्रमाणपत्र पडताळणीचा उल्लेख करते. ती ओळ लोकांना अशा CA बंडलांकडे पाठवते जी कधीच तुटली नव्हती. दोन वेगळे बिघाड जवळजवळ एकाच प्रकारचे अपयश निर्माण करतात: सत्र कुकीची मुदत संपते, किंवा सर्व्हरचे प्रमाणपत्र खरोखर बदलले आहे. ते सुमारे एका मिनिटात वेगळे करता येतात, आणि त्यापैकी फक्त एकच फिंगरप्रिंटशी संबंधित आहे.

दोन बिघाड, एक गोंधळात टाकणारी लॉग ओळ

ते दोन निरीक्षणांवर वेगळे होतात, आणि दोन्हीपैकी कोणालाही दुसरे वाचन लागत नाही. पहिले म्हणजे अपयश कधी सुरू झाले: मुदत संपलेली कुकी तास किंवा दिवसांच्या कामानंतर येते, आणि बदललेले प्रमाणपत्र गेटवे बदलानंतर लगेच येते.

SignalExpired cookieChanged certificate
When it startedafter hours or days of workingright after a gateway change
Fingerprint from a fresh authenticateunchangeddifferent value
Usual log tailHTTP CONNECT 401 / unauthorizedsigner not found / verify failed
Repairreplace the cookie, restartre-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 मोड चालवते आणि फक्त कुकीची ओळ पुन्हा लिहिते. ओळखपत्र स्क्रिप्टबाहेर ठेवा आणि ती चालवणाऱ्या खात्यालाच वाचनीय ठेवा, आणि पुनर्लेखन अणु करा जेणेकरून अपयशी रन अर्धवट लिहिलेली फाइल सोडणार नाही.

दर काही तासांनी ताजे करणे आवश्यक असल्यास, मध्यांतर लिहून ठेवा. ते गेटवेच्या सत्र धोरणाचे गुणधर्म आहे, आणि ताजे करणे स्वयंचलित करायचे की लांब सत्र मागायचे हे ते ठरवते.

संबंधित लेख