SSTP მარცხდება იქ, სადაც ბრაუზერის HTTPS წარმატებულია: რატომ
SSTP მუშაობს TLS-ის შიგნით 443 პორტზე, მაგრამ ეს ვებ მოთხოვნა არ არის. შეამოწმეთ TCP, TLS იდენტობა, SSTP გაცვლა და PPP ავთენტიფიკაცია ცალკე ეტაპებად.
ბრაუზერი ხსნის VPN ჰოსტის სახელს HTTPS-ით უჩივლებლად, და SSTP კლიენტი მაინც უარყოფს დაკავშირებას. ამ წყვილში არაფერია წინააღმდეგობრივი. SSTP იყენებს TLS-ს როგორც გარე ტრანსპორტს და შემდეგ ამავე კავშირის შიგნით ასრულებს საკუთარ მოთხოვნას და PPP დატვირთვას, ამიტომ გვერდის წარმატებული ჩატვირთვა მხოლოდ ერთ ვიწრო რამეს ამტკიცებს: ჰოსტი პასუხობს GET-ს 443 პორტზე. კლიენტი სხვა კითხვას სვამს, და სერვერმა შეიძლება ცუდად უპასუხოს მას.
გვერდი იტვირთება, გვირაბი კი არა
ადამიანები ბრაუზერის ტესტს მიმართავენ, რადგან ის სწრაფია, შემდეგ კი შედეგს სერვერის ხელმისაწვდომობისა და კონფიგურაციის მტკიცებულებად თვლიან. ეს არის მტკიცებულება მისამართების ზოლის მიერ გახსნილ გზაზე GET-ის შესახებ, მეტი არაფერი. VPN საუბარი იწყება იმავე TLS ხელის ჩამორთმევის შემდეგ, მაგრამ აგზავნის მეთოდსა და გზას, რომელსაც ვებ გვერდი არასდროს იყენებს. ამიტომ 200 პასუხი ბრაუზერისთვის არაფერს ამბობს იმაზე, არსებობს თუ არა SSTP საბოლოო წერტილი.
გამოყავით ორი დაკვირვება და ძებნა მოკლდება. ტრანსპორტი და სერტიფიკატების ჯაჭვი მუშაობს, და მათ ზემოთ პროტოკოლურ გაცვლაში რაღაც არ მუშაობს. ეს განსხვავებული გამოძიებაა გატეხილი პორტისა და ვადაგასული სერტიფიკატისგან, და სხვა მტკიცებულებებს მოითხოვს.
რას აგზავნის SSTP კლიენტი სინამდვილეში
კლიენტი აგზავნის HTTP მოთხოვნას SSTP_DUPLEX_POST მეთოდით /sra_{GUID}/ გზაზე, შემდეგ კავშირის სხეულს ღიად ინახავს როგორც ორმხრივ ნაკადს, რომელიც PPP ჩარჩოებს ატარებს. შესაბამისი სერვერი პასუხობს HTTP/1.1 200-ით და წყვეტს ვებ სერვერივით ქცევას. ყველაფერი სხვა ხელმოწერაა: 405 ან 404 ნიშნავს, რომ საბოლოო წერტილი არ არის, 301 ან 302 ნიშნავს, რომ რაღაც მოთხოვნას გადამისამართებს, ხოლო მყისიერი FIN ნიშნავს, რომ პროქსიმ ან სერვერმა ნაკადი დახურა.
ამიტომ სამიზნე უნდა იყოს SSTP სერვერი და არა ვებ სერვერი მიმაგრებული TLS სერტიფიკატით. მეთოდი, გზა და ხანგრძლივი სხეული პროტოკოლის მოთხოვნებია, ამიტომ საპირისპირო პროქსი ვერ დაამატებს მათ მხოლოდ კონფიგურაციით. პროქსი, რომელიც ჩვეულებრივ HTTPS-ს სრულყოფილად გადასცემს, მაინც შეიძლება უარყოს მისთვის უცნობი მეთოდი.
სად ამტვრევს ნაკადს პროქსი ან ვებ სერვერი
შუამავალი ამოწმებს HTTP მოთხოვნის სტრიქონს, სანამ რამეს გადასცემს, და უჩვეულო გზის მქონე მორგებული მეთოდი შეიძლება ვერ გაიაროს მისი წესები. ზოგი მოწყობილობა ჩვეულებრივ გვერდს აძლევს, ხოლო გვირაბს უარყოფს ან წყვეტს, ამიტომ კლიენტი იუწყება კავშირზე, რომელიც იწყება და შემდეგ კვდება, სუფთა უარის ნაცვლად. სხვები იღებენ მოთხოვნას, შემდეგ კი იყენებენ სხეულის ან უმოქმედობის ტაიმაუტს, რომელსაც PPP keepalive-ები ვერ გაუძლებს. ორივე კლიენტის მხრიდან ერთნაირად გამოიყურება, ამიტომ რომელი ეტაპი ჩავარდა, ერორის ტექსტზე უფრო მნიშვნელოვანია.
443 პორტის გაზიარება ვებსაიტსა და SSTP-ს შორის მარშრუტიზაციის არჩევანია, და არა დაპირება, რომ ყოველი ნახტომი ორივე საუბარს ერთნაირად გაუმკლავდება. თუ გზაზე დატვირთვის ბალანსირებელი, ფაირვოლი ან TLS დამამთავრებელია, დაამატეთ ის ეჭვმიტანილთა სიაში VPN კონფიგურაციის შეხებამდე.
შეამოწმეთ ეტაპები ცალ-ცალკე
გაუშვით შემოწმებები რიგით და გაჩერდით პირველ მარცხზე, რადგან ყოველი ეტაპი სხვა ფენას გამორიცხავს. ქვემოთ მოცემული TLS ზონდი გამოყოფს სერტიფიკატის იდენტობას ყველაფრისგან, რასაც SSTP აკეთებს. შეცვალეთ ჰოსტის სახელი თქვენი საბოლოო წერტილით და წაიკითხეთ subject და ჯაჭვი, რომელსაც ის ბეჭდავს.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comშემდეგ დააკავშირეთ დარჩენილი მტკიცებულებები ეტაპებს, ნაცვლად იმისა, რომ კლიენტის ერორიდან გამოიცნოთ. ქვემოთ მოცემული ცხრილი ბილეთში დასაციტირებელი შემოწმების სიაა, ხელმოწერით, რომელიც ერთ მარცხს შემდეგისგან ჰყოფს.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
ბილეთში ჩაწერეთ ბოლო წარმატებული ეტაპი იმის ნაცვლად, რომ დაწეროთ "დაკავშირება შეუძლებელია". MS-SSTP სპეციფიკაცია აღწერს მოთხოვნას და PPP გაცვლას, რომლებიც TLS ხელის ჩამორთმევას მოსდევს, და ეს არის მითითება იმისა, თუ რატომ ვერ ჩაანაცვლებს ბრაუზერის ტესტი არც ერთს.
ჯერ იდენტობა, შემდეგ PPP
TLS იდენტობა და PPP ავთენტიფიკაცია თანმიმდევრულია და არა ალტერნატიული, და მათი არევა ადამიანებს არასწორ სერვერის პარამეტრთან მიჰყავს. კლიენტი ჯერ ამოწმებს სერვერის სერტიფიკატს და მის დანიშნულებას, შემდეგ PPP აწარმოებს მოლაპარაკებას საკუთარ მდგომარეობაზე და ავთენტიფიცირებს მომხმარებელს გამოწვევა-პასუხის მეთოდით ან EAP-ით. სერტიფიკატის პრობლემა სხვა ერორს იძლევა, ვიდრე უარყოფილი პაროლი, და არც ერთი ერორი არ აღწერს იმ ეტაპს, რომელსაც მეორე ფარავს.
ჰოსტის სახელის მისამართით შეცვლა, ან სერტიფიკატის გაფრთხილების გვერდის ავლა, აშორებს იმ შემოწმებას, რომელიც ჩავარდნილ ეტაპს გამოავლენდა, ნაცვლად მისი გასწორებისა. შეინარჩუნეთ გაფრთხილება და წაიკითხეთ ის. ნუ გადააყენებთ PPP პაროლს, როცა HTTP გაცვლა არასდროს მიუახლოვდა SSTP ქცევას, რადგან სამოწმებელი მონაცემები არასდროს მოთხოვნილა.