უარყოფილი კავშირი სერტიფიკატის პრობლემა არ არის: VPN-ის საოპერაციო გზამკვლევი

კლიენტი ამბობს, რომ კავშირი უარყოფილია CRL-ის ხელახლა გენერირებისთანავე, ამიტომ CRL დამნაშავედ ჩანს. ასე არ არის. უარყოფა ტრანსპორტის დონის პასუხია, ხოლო სერტიფიკატის შემოწმება მოგვიანებით, გვირაბის ხელის ჩამორთმევის შიგნით ხდება. დროის დამთხვევა კონტექსტია, არა მტკიცებულება.

ორი შემოწმება ერთ წუთზე ნაკლებ დროში ჰყოფს შემთხვევებს და არც ერთი მათგანი არ ეხება ნდობის პარამეტრებს.

წაიკითხეთ შეცდომა იმ დონეზე, რომელმაც ის წარმოქმნა

ECONNREFUSED connect-იდან ნიშნავს, რომ ტრანსპორტის მცდელობა უარყოფილია: რაღაცამ reset-ით უპასუხა, ან სტეკმა მიუწვდომელი პორტი შეატყობინა. სერტიფიკატის პრობლემა ვერ შექმნის ამ შეცდომას, რადგან TLS-ის ხელის ჩამორთმევა არასოდეს იწყება ტრანსპორტის კავშირის გარეშე. თუ ხედავთ უარყოფას, კლიენტი არასოდეს მიმსვლელა სერტიფიკატის წარდგენამდე. ეს ერთი ფაქტი გამორიცხავს გაუქმებას მიზეზად.

საპირისპიროც მართალია. გაუქმებული სერტიფიკატი ქმნის დასრულებულ TCP კავშირს და წარუმატებელ ხელის ჩამორთმევას, რომელიც სერვერზე შემოწმების შეცდომად ფიქსირდება.

TCP-ის უარყოფა: არავინ უსმენს

TCP-ისთვის შეამოწმეთ, მუშაობს თუ არა განსაზღვრული ინსტანცია და მიბმულია თუ არა პროფილის მისამართსა და პორტზე. ss -lntp აჩვენებს მსმენელებს და მათი არქონა ჩვეულებრივი ახსნაა. ქსელის დაცვა, რომელიც წვეთავს და არა უარყოფს, კლიენტის მხარეს იმავე შეტყობინებას ქმნის, ამიტომ ორივეს ამოწმებთ.

შეამოწმეთ მისამართების ოჯახიც. სერვისი, მიბმული 127.0.0.1-ზე ან მხოლოდ IPv6-ზე, უარყოფს კლიენტს, რომელიც მეორეზე იხსნება.

შემდეგ წაიკითხეთ სერვისის ჟურნალი, ნაცვლად გამოცნობისა. CA-ს მოვლის შემდეგ გადატვირთვა შეიძლება ჩავარდეს წაუკითხავ ან დაკარგულ ფაილზე და არასოდეს მიაღწიოს მოსმენის მდგომარეობას, ჟურნალი კი ფაილს ასახელებს. ეს გაშვების ჩავარდნაა, სხვა ხარვეზი უარყოფილი სერტიფიკატისგან.

UDP-ს არ აქვს ხელის ჩამორთმევა, რომ უარყოს

OpenVPN UDP-ზე არ ამყარებს კავშირს TCP-ის გაგებით, ამიტომ connect-ის დროს უარსაყოფი არაფერია. Linux-ზე UDP სოკეტის მიერ ნაჩვენები შეცდომა შეიძლება მოდიოდეს ადრინდელი დატაგრამის მიერ წარმოქმნილი ICMP port-unreachable-იდან. udp(7) სახელმძღვანელოს გვერდი აღწერს ამ ასინქრონულ ქცევას.

ამიტომ UDP კლიენტს შეუძლია დაბეჭდოს უარყოფა, მაშინ როცა სერვერის პროცესი მუშაობს, მაგრამ მოსალოდნელ მისამართზე არ არის მიბმული.

სად მოწმდება CRL სინამდვილეში

CRL-ს კონსულტაცია ხდება TLS-ის ხელის ჩამორთმევის დროს, მას შემდეგ რაც მოპირდაპირე მხარე წარადგენს თავის სერტიფიკატს და მხოლოდ მაშინ, თუ სერვერის კონფიგურაცია ამას რთავს. OpenVPN-ის crl-verify პარამეტრი ფაილზე მიუთითებს და ჩავარდნა სერვერის ჟურნალში ჩნდება როგორც შემოწმების შეცდომა, სერტიფიკატის დასახელებით.

ამრიგად, გაუქმებული კლიენტი უერთდება ტრანსპორტის დონეზე და შემდეგ ავტორიზაციაში ვარდება. იგივე სერვერი, იგივე პორტი, სრულიად სხვა შეტყობინება.

როცა ამ ეტაპამდე მიხვალთ, შეამოწმეთ CRL-ის გამომცემი და მოქმედების თარიღები. არასწორი CA-ის მიერ ხელმოწერილი CRL, ან ის, რომელიც კლიენტის დაკავშირებამდე ამოიწურა, ქმნის შემოწმების შეცდომებს, რომლებსაც კლიენტის საკუთარ სერტიფიკატთან არავითარი კავშირი არ აქვს.

მოკლე გზამკვლევი შემდეგი შემთხვევისთვის

ჯერ დაადასტურეთ ტრანსპორტი: მსმენელი არსებობს, მისამართების ოჯახი სწორია, ქსელის დაცვა არ უარყოფს. შემდეგ დაადასტურეთ, რომ სერვისმა მოსმენის მდგომარეობას მიაღწია გაშვების ჟურნალის წაკითხვით. და მხოლოდ ამის შემდეგ შეხედეთ ხელის ჩამორთმევის შეცდომებს შემოწმების შეტყობინებების საძებნელად. შეინარჩუნეთ ეს რიგი ფიქსირებული, რადგან ყოველი ნაბიჯი გამორიცხავს მიზეზების მთელ კლასს.

ჩაწერეთ ტრანსპორტი, ამოხსნილი დანიშნულება, პორტი და შეცდომის ზუსტი ტექსტი. კლიენტის ხელახლა დაყენება ანადგურებს ამ მტკიცებულებას და ჩვეულებრივ არაფერს ცვლის.