თქვენ აკრავთ ინსტალატორის ერთსტრიქონიან ბრძანებას სახელმძღვანელოდან, აჭერთ Enter-ს და იღებთ curl: (77). შეტყობინება სერტიფიკატის შემოწმების მდებარეობებს ახსენებს, ამიტომ ინსტინქტი გვკარნახობს, რომ VPN-ის პროვაიდერის სერტიფიკატი დაზიანებულია და უნდა ვეძიოთ დროშა, რომელიც შემოწმებას გამოტოვებს. ეს წაკითხვა მცდარია და მის მიხედვით მოქმედება ლოკალურ ფაილის პრობლემას უსაფრთხოების გადაწყვეტილებად აქცევს. დავუბრუნდეთ დასაწყისს.

ნაბიჯი 1: წაიკითხეთ, რას ნიშნავს ეს რიცხვი

შეცდომა 77 ლოკალურ CA შეყვანას ეხება: curl-მა ვერ შეძლო წაეკითხა ან ჩაეტვირთა ის სერტიფიკატის მასალა, რომლის ნდობაც უნდა ჰქონოდა. შეცდომა 60 მეორე მხარეს ეხება, როცა სერვერის ჯაჭვი არ ვალიდირდება. ისინი სახელმძღვანელოებში გვერდიგვერდ ჩნდება და საპირისპიროს ნიშნავს.

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

ნაბიჯი 2: წაიკითხეთ ბრძანება, რომელიც დააკოპირეთ

დაკოპირებული ბრძანებები სიმბოლოებს მალავს. პატარა -l ნიშნავს --list-only, რომელიც პროტოკოლების ჩამონათვალს ეხება. დიდი -L ნიშნავს --location, რომელიც HTTP გადამისამართებას მიჰყვება. ეს არ არის მართლწერის ალტერნატივები და ის სახელმძღვანელო, რომელიც ერთს წერს და მეორეს აღწერს, ხალხს იმ გადამისამართების გზაზე აგზავნის, რომელიც არასდროს ყოფილა გულისხმობილი.

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

ნაბიჯი 3: გაარკვიეთ, რომელ CA შეყვანას იყენებს ის აწყობა

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

curl --version

ჩაწერეთ ვერსია და TLS backend. აწყობა, რომელიც მშობლიურ ნდობის საცავს იყენებს, სისტემურ საცავს TLS ბიბლიოთეკის მეშვეობით კითხულობს, ხოლო პაკეტზე მიმართული აწყობა ფაილს კითხულობს. ცხადი --cacert, CURL_CA_BUNDLE პარამეტრი ან shell-ის გარსი ორივეს გადაფარავს, ამიტომ პაკეტით ინსტალაციამ შეიძლება არც კი შეეხოს იმ ფაილს, რომელიც რეალურად ფუჭდება.

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

ნაბიჯი 4: გაასწორეთ შეყვანა და არა შემოწმება

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

არ შეცვალოთ URL HTTP-ზე, არ დაამატოთ --insecure, და არ ენდოთ გაუხსნელი ჩამოტვირთვიდან დაკოპირებულ სერტიფიკატს. ამ ცვლილებათაგან თითოეული ცვლის იმას, რისი მიღებაც მზად ხართ, იმის გასწორების ნაცვლად, რისი წაკითხვაც curl-მა ვერ შეძლო, და ცვლილება ჩვეულებრივ ინციდენტზე დიდხანს ცოცხლობს.

რიცხვებისთვის ცნობარია curl-ის შეცდომების კატალოგი, და ის საკმარისად მოკლეა, რომ ერთხელ ყურადღებით წაიკითხოთ.

ნაბიჯი 5: ჩამოტვირთეთ, დაათვალიერეთ, შემდეგ გაუშვით

მიიღეთ ინსტალატორი ფაილში, ნაცვლად იმისა, რომ იმავე ბრძანებაში shell-ში გაატაროთ. ეს ერთი ცვლილება გამოყოფს შესამოწმებელ გადაცემას თქვენი უფლებებით მომუშავე კოდისგან.

curl -fL -o vpn-installer.sh https://example.invalid/install.sh
file vpn-installer.sh
head -n 40 vpn-installer.sh

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

გაიხსენეთ, რა გააკეთა HTTPS-მა და რა არა. მან დაადასტურა ტრანსპორტი იმ ჰოსტამდე, რომელსაც დაუკავშირდით; მან არ განიხილა სკრიპტის შიგთავსი და არ გეუბნებათ, სანდოა თუ არა გამომცემელი.

ნაბიჯი 6: დააშორეთ ინსტალაციის ნაბიჯები

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

თუ ინსტალაცია წარმატებით დასრულდა და გვირაბი ამოვიდა, ბილეთის დახურვამდე შეამოწმეთ მარშრუტები და ერთი რეალური დანიშნულება. curl-ის შეცდომა გასწორებულია მაშინ, როცა ჩვეულებრივი curl -I https://example.invalid კვლავ მუშაობს და არა მაშინ, როცა ინსტალატორი წუწუნს წყვეტს.

დაკავშირებული სტატიები