SSTP-ის დროის ამოწურვა თუ სერტიფიკატის შეცდომა: როგორ განვასხვავოთ ისინი

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

ორი მარცხი, ორი განსხვავებული გაცვლა

SSTP გვირაბს HTTPS-ის ფორმის სესიის შიგნით ატარებს, ამიტომ ის უძლებს ქსელებს, რომლებიც 443-ის გარდა არაფერს უშვებს. კლიენტი ასრულებს TLS ხელის ჩამორთმევას, აგზავნის HTTP მოთხოვნას პროტოკოლისთვის დამახასიათებელი მეთოდით, და შემდეგ გვირაბი ამ ნაკადის შიგნით მუშაობს. ამ ნაბიჯებიდან რომელიმეში მარცხი აჩერებს კავშირს, და მხოლოდ უკანასკნელებს ეხებათ შესვლის მონაცემები.

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

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

დროის ამოწურვა ნიშნავს, რომ ეტაპი არასდროს დასრულდა

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

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

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

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

სერტიფიკატის შეცდომა ნიშნავს, რომ იდენტობა უარყოფილ იქნა

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

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

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

სად ერევა ეს ორი

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

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

სერტიფიკატის საკითხი და ხელმისაწვდომობის საკითხი ცალ-ცალკეა დოკუმენტირებული რაღაც მიზეზით.

ხელახლა გამოსცადეთ ნამდვილი კლიენტით, შემდეგ შიგნით გადადით

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

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

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