SSTP ჯერ სერვერს ამოწმებს, შემდეგ კი მომხმარებელს
SSTP ჯერ სერვერის სერტიფიკატს ამოწმებს და მომხმარებელს მოგვიანებით PPP-ის მეშვეობით ამოწმებს. შეუსაბამეთ შეცდომა სწორ ეტაპს, ორივეს ერთდროულად შეხების ნაცვლად.
SSTP კლიენტს შეუძლია TLS დაასრულოს და მაინც უარყოს მომხმარებელი ერთი წამის შემდეგ. ეს თანმიმდევრობა შეცდომა არ არის, ეს პროტოკოლური დასტაა: ჯერ ტრანსპორტის უსაფრთხოება, შემდეგ მომხმარებლის ავთენტიფიკაცია. რადგან ორი ეტაპი სხვადასხვა შეტყობინებით ფარდება, მათ სხვადასხვა შესწორებაც სჭირდებათ. იმის წაკითხვა, რომელმა ეტაპმა შექმნა შეცდომა, დიაგნოზის უდიდესი ნაწილია.
სანდო სერტიფიკატი ადასტურებს საბოლოო წერტილს; ანგარიშზე ის არაფერს ამბობს.
რას ადგენს TLS-ის ხელის ჩამორთმევა
კლიენტი ამოწმებს სერვერის მიერ წარდგენილ სერტიფიკატს საკუთარი ნდობის საცავის, მოთხოვნილი ჰოსტის სახელის, ვალიდობის ფანჯრის და პლატფორმის მიერ გამოყენებული ნებისმიერი დამატებითი პოლიტიკის მიმართ. ეს იცავს კავშირს განკუთვნილ საბოლოო წერტილთან. მაგრამ არ ამტკიცებს, რომ კონკრეტული ანგარიში ჩართულია, არ არის ვადაგასული ან დისტანციური წვდომის უფლება აქვს. ეს ცალკე კითხვებია, რომლებსაც მოგვიანებით სხვა კომპონენტი სვამს.
ამიტომ სერტიფიკატის შემოწმებების მოცილება შესვლის მოთხოვნის მისაღწევად არასწორი შესწორებაა. თქვენ იღებთ შესვლის მოთხოვნას კავშირზე, რომელსაც ვერ ამოწმებთ. სერტიფიკატის შეცდომა ჰოსტის სახელს, საათს, ჯაჭვს ან ნდობის კონფიგურაციას ეკუთვნის.
რას ამატებს SSTP და PPP ზემოდან
SSTP HTTPS-ზე მუშაობს და შიგნით PPP-ს ატარებს, კავშირის გარშემო საკუთარი კონტროლის გაცვლით. შემდეგ PPP ასრულებს თავის ბმულისა და ავთენტიფიკაციის ეტაპებს, და ავთენტიფიკაციის მეთოდი დამოკიდებულია სერვერის პოლიტიკასა და კლიენტის შესაძლებლობებზე. PAP, CHAP, MS-CHAPv2 და EAP ყველა PPP-ის ავთენტიფიკაციის ვარიანტია ძალიან განსხვავებული თვისებებით. VPN-ის მომხმარებლის შემოწმება სწორედ ეს PPP ეტაპია და არა მის ქვეშ არსებული TLS ფენა.
ამიტომ მომხმარებლის უარყოფა შეიძლება ნიშნავდეს მონაცემებს, ანგარიშის შეზღუდვას ან მეთოდის შეუთავსებლობას.
სერვერის მხრიდან მიზეზი ბევრად უფრო სასარგებლოა, ვიდრე პროფილში ყველა საიდუმლოს განულება. ანგარიშის გამორთვის მოვლენა და მეთოდის მოლაპარაკების წარუმატებლობა კლიენტზე მსგავსად გამოიყურება და სერვერზე საერთო არაფერი აქვთ.
შეუსაბამეთ შეცდომა ეტაპს
შეამოწმეთ, აღწევს თუ არა კავშირი TLS-ს, შემდეგ SSTP HTTP გაცვლას, შემდეგ PPP ეტაპს. შეინახეთ ჟურნალების დროის ნიშნები გასწორებული განმეორებით ცდებს შორის, რომ ადრინდელი მარცხი გვიანდელ წარმატებას არ აურიოთ. კლიენტი, რომელიც ერთ ფანჯარაში ორ ცდას აღრიცხავს, სხვაგვარად ისე გამოჩნდება, თითქოს ბოლო მიღწეულ ეტაპზე ჩავარდა. წაიკითხეთ პირველი შესაბამისი შეცდომა და არა ბოლო სტრიქონი.
იგივე გასწორება მნიშვნელოვანია სერვერის მხარეს, სადაც ავთენტიფიკაციის ჩანაწერი და ტრანსპორტის ჟურნალი ხშირად ცალკე ფაილებია ცალკე საათებით. ორი წუთის გადახრა საკმარისია, რომ აშკარა მიზეზი შეუძლებლად გამოიყურებოდეს.
შესვლის შემდეგ ავტორიზაცია კვლავ ცალკეა
წარმატებული შესვლა ყველა კერძო რესურსს არ ანიჭებს. მარშრუტები განსაზღვრავენ, რა არის მისაწვდომი, DNS განსაზღვრავს, რა წყდება, და ყველა სერვისი კვლავ თავის უფლებებს იყენებს. დაკავშირებულად ნაჩვენები სესია განცხადებაა გვირაბზე და არა ფაილების გაზიარებაზე. როცა მომხმარებელს შეუძლია დაკავშირება და ერთ ჰოსტამდე ვერ აღწევს, გვირაბის ეტაპი უკვე დასრულებულია.
ეს იგივე ფენოვნებაა, რაც ხელის ჩამორთმევამ აჩვენა, ერთი დონით ზემოთ.
ანგარიშის აღდგენა ოპერატორის მიერ მხარდაჭერილ პროცესში შეინახეთ, ნაცვლად იმისა, რომ ტრანსპორტის პარამეტრები შეცვალოთ მომხმარებლის აშკარა უარყოფის პასუხად. გამორთული ანგარიშის გასწორებისთვის ტრანსპორტის შეცვლა იმ ტიპის შესწორებაა, რომელიც თითქოს მუშაობს, როცა ანგარიში დაუკავშირებელი მიზეზით ხელახლა ჩართულია.