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 ნიშნავს, რომ მხოლოდ ქუქი უნდა შეიცვალოს. განსხვავებული ანაბეჭდი ნიშნავს, რომ სერვერის სერტიფიკატი ნამდვილად შეიცვალა, ამიტომ განზრახ ხელახლა ჩამოწექით იგი და ჩაწერეთ ვინ დაამტკიცა ეს.
შექმენით მასალა ხელით აკრეფის ნაცვლად
ConnMan-ს არ აქვს OpenConnect-ის პროფილის იმპორტის ნაბიჯი, NetworkManager-ისგან განსხვავებით. ის კითხულობს მომარაგების ფაილს, რომლის მნიშვნელობები წინასწარ უნდა იყოს შექმნილი, და მათი შექმნის მხარდაჭერილი გზა 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 რეჟიმს და გადაწერს მხოლოდ ქუქის სტრიქონს. შეინახეთ სამეურნეო მონაცემები სკრიპტის გარეთ და წაკითხვადი მხოლოდ იმ ანგარიშისთვის, რომელიც მას უშვებს, ხოლო გადაწერა გახადეთ ატომური, რომ წარუმატებელმა გაშვებამ ნახევრად დაწერილი ფაილი არ დატოვოს.
თუ განახლება ყოველ რამდენიმე საათშია საჭირო, ჩაწერეთ ინტერვალი. ეს გეითვეის სესიის პოლიტიკის თვისებაა და განსაზღვრავს, ავტომატიზდეს განახლება თუ უფრო გრძელი სესია მოითხოვოს.