SSTP TLS-ის შემოწმების პროქსის უკან: სად წყდება სესია

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

დაიწყეთ იქ, სადაც კლიენტი ჩერდება

კლიენტი გადის ფიქსირებულ თანმიმდევრობას: TCP კავშირი 443 პორტზე, TLS ხელის ჩამორთმევა, სერტიფიკატის ვალიდაცია, SSTP-ის HTTP გაცვლა, PPP მოლაპარაკება და აუთენტიფიკაცია, შემდეგ IP კონფიგურაცია. ყოველ ეტაპზე ჩავარდნა სხვა კვალს ტოვებს, და მათი არევა არასწორ კონფიგურაციის გვერდზე მიგიყვანთ.

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

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

რას სთხოვს SSTP ქსელს, რომ ატაროს

SSTP მუშაობს TLS-ზე TCP 443-ში და შემდეგ აგზავნის HTTP მოთხოვნას სახელად SSTP_DUPLEX_POST, რომელიც განსაზღვრულია SSTP სპეციფიკაციაში, /sra_{GUID}/ ფორმის ბილიკზე. მოთხოვნა აცხადებს პრაქტიკულად უსასრულო შიგთავსის სიგრძეს და სესიის მთელი ხანგრძლივობის განმავლობაში ნაკადს ორივე მიმართულებით ღიად ინახავს. PPP ჩარჩოები ამ ნაკადის შიგნით მოძრაობს.

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

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

რატომ ცვლის შემოწმება იდენტობას

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

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

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

გამომცემელი განსაზღვრეთ პარამეტრების შეცვლამდე

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

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

ბრაუზერის ტესტი იმავე ჰოსტზე მხოლოდ იმას ამტკიცებს, რომ პროქსი GET-ს იღებს. ის არაფერს ამბობს SSTP მეთოდზე, მოთხოვნის URI-ზე ან სხეულის სიცოცხლეზე, ამიტომ მომუშავე ინტრანეტ გვერდი გვირაბის ბილიკის მხარდაჭერის მტკიცებულებად არ ჩათვალოთ.

აირჩიეთ მხარდაჭერილი ბილიკი

ჰკითხეთ ქსელის მფლობელს ერთი კონკრეტული კითხვა: უშვებს თუ არა პროქსი ბუფერიზაციის გარეშე ორმხრივ POST-ს ამ კარიბჭესთან 443 პორტზე? „დიახ“ იწვევს პროქსის გამონაკლისს ან VPN ჰოსტისთვის დოკუმენტირებულ გვერდის ავლას. „არა“ ნიშნავს, რომ შემოწმებული ბილიკი SSTP-ს ვერ ატარებს, და მხარდაჭერილი გამოსწორება სხვა ბილიკი ან პროტოკოლია და არა კლიენტის შესწორება.

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

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