Windows-ის ჩაშენებული VPN ვერ აღწევს მომწოდებლის SSL კარიბჭემდე: რატომ

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

ოთხი ტიპი და ერთი დიალოგი

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

სია ერთი ბრძანების მოშორებითაა და ღირს მისი გაშვება ნებისმიერ სხვა დიაგნოსტიკამდე, რადგან ერთი წამი სჭირდება და არასწორი ვარაუდების მთელ კლასს შლის:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

თუ პროფილი ამბობს SSTP-ს და კარიბჭე RRAS სერვერი არ არის, შეუსაბამობა უკვე დადგენილია. სერტიფიკატის ან ქსელური ფარის არც ერთი სამუშაო ამას არ შეცვლის.

SSTP და მომწოდებლის TLS 443 პორტზე ერთნაირად გამოიყურება

SSTP PPP სესიას TLS-ში ახვევს და TCP 443-ზე მოძრაობს. Microsoft-ის სტეკში მას RRAS ამთავრებს, რომელიც სერვერის სერტიფიკატს წარმოადგენს, რომელსაც კლიენტი ამოწმებს. Fortinet-ის, Citrix-ის ან Pulse-ის მოწყობილობა ასევე ამთავრებს TLS-ს 443-ზე, და მისი პორტალი ნებისმიერ ბრაუზერში უჩივლელად იხსნება.

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

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

შეცდომები, რომლებიც გვირაბის არსებობამდე ჩნდება

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

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

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

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

დაკავშირებულ პროფილსაც შეუძლია ყველაფრის გატეხვა

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

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

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

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

შეამოწმეთ მილსადენი, შემდეგ ტიპი

იმუშავეთ ამ თანმიმდევრობით და გაჩერდით, როცა ნაბიჯი ჩავარდება, ყველაფრის ერთდროულად მორგების ნაცვლად:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

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

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