Windows VPN თუ Cisco Secure Client: რომელია სწორი?
ბრენდი პროტოკოლის სახელი არ არის: Windows რამდენიმე მშობლიურ ტიპს გვთავაზობს და Cisco-ს კლიენტი ერთზე მეტი რეჟიმის პროფილს ატარებს. წაიკითხეთ პროფილი.
ერთი და იმავე კარიბჭისთვის ორი მითითება მოდის: დაუკავშირდით Windows VPN-ით ან დააყენეთ Cisco-ს კლიენტი. არც ერთი არ ასახელებს იმ გაცვლას, რომელსაც კარიბჭე ელოდება, რადგან Windows რამდენიმე მშობლიურ კავშირის ტიპს აჩვენებს და მომწოდებლის კლიენტი ერთზე მეტი რეჟიმის პროფილს ატარებს. ორივე იარლიყი პროგრამულ უზრუნველყოფას აღწერს, მაშინ როცა კარიბჭე პროტოკოლზე, ავთენტიფიკაციასა და პოლიტიკაზე მოლაპარაკებას აწარმოებს. პასუხი პროფილშია და მისი წაკითხვა კავშირის გარეშე შეიძლება.
იარლიყი პროგრამულ უზრუნველყოფას ასახელებს და არა გაცვლას
ბრენდი და ოპერაციული სისტემა ორი განსხვავებული ფაქტია და არც ერთი არ ირჩევს მავთულის ფორმატს. Windows მშობლიური ტიპების ერთობლიობას გვაწვდის, ხოლო Cisco-ს კლიენტი პროფილის ძრავას გვაწვდის, რომელსაც SSL ან IPsec/IKEv2 შეუძლია მართოს. ორივეს არევა ისეთ ცხრილებს ქმნის, რომლებიც გაცვლების ნაცვლად კომპანიებს ადარებს.
ქვემოთ მოცემული ცხრილი პროდუქტის კითხვას კითხვის სამი ადგილითა და თითოეულში შენახული ველით ცვლის. ჩაწერეთ ეს ველები და გაურკვევლობა გაქრება:
| Where to read it | Field name to record | What a mismatch looks like |
|---|---|---|
| Native Windows profile | TunnelType and AuthenticationMethod from Get-VpnConnection | The client offers IKEv2 while the gateway answers only on an SSL port |
| Vendor client profile | SSL or IPsec/IKEv2 mode, plus the client and headend version pair | The imported profile negotiates a mode this headend does not serve |
| Gateway configuration | Protocol, authentication policy and the certificate the headend presents | The client authenticates and then drops, because policy expects another method |
Microsoft-ის Windows VPN ტიპების ცნობარი მშობლიურ ტიპებს შორის IKEv2-სა და SSTP-ს ასახელებს, რაც აუქმებს აზრს, თითქოს მშობლიური პროფილი PPTP-ს ნიშნავს. Cisco-ს პროფილების დოკუმენტაცია აღწერს როგორც SSL, ისე IPsec/IKEv2 რეჟიმს შესაბამისი ცენტრალური კვანძის პოლიტიკით. ყოველი მომწოდებელი რამდენიმე ვარიანტს გვთავაზობს, ამიტომ არც ერთი სახელი არ განსაზღვრავს ერთ პროტოკოლს.
რას დებს მშობლიური ტიპები მავთულზე
IKEv2 UDP-ზე უსაფრთხოების ასოციაციებზე მოლაპარაკებას აწარმოებს და ტრაფიკს IPsec-ის შიგნით გადააქვს, რაც მას სხვა IKEv2 იმპლემენტაციების თანასწორო ხდის და არა Microsoft-ის სპეციფიკურ ნახაზად. SSTP PPP-ს HTTPS სესიის შიგნით ახვევს, ამიტომ გადის იმ პროქსებზე, რომლებზეც IKEv2 ვერ გადის, და მავთულზე TLS-ივით გამოიყურება, თუმცა TLS VPN პროტოკოლი არ არის. ეს ორი ფაქტი ხსნის ბილეთის დიდ ნაწილს, რომელიც ამბობს, რომ გვირაბი ერთ ქსელში მუშაობს და მეორეში ვერ ხერხდება.
L2TP IPsec-ით და ძველი PPTP ჩანაწერი ერთსა და იმავე ჩამოსაშლელ მენიუშია და მათი იქ ყოფნა სერვერის მხარდაჭერაზე არაფერს ამბობს. ჩამოსაშლელი მენიუ იმის სიაა, რასაც ოპერაციული სისტემა სცდის, და არა კარიბჭის შესაძლებლობების განაცხადი. მისი მხარდაჭერის სიად წაკითხვა ორსაათიანი საკრედენციალო ძებნის დასაწყისია.
მშობლიურ პროფილში მნიშვნელოვანი ველებია კავშირის ტიპი, ავთენტიფიკაციის მეთოდი და სერვერის იდენტობა. არასწორი ტიპი სხვა ეტაპზე ვარდება, ვიდრე ცუდი პაროლი, და სწორედ ეს განსხვავებაა მისაყოლებელი მინიშნება.
რას მატებს მომწოდებლის კლიენტი: პროფილებს და არა პროტოკოლს
Cisco-ს კლიენტი პროფილების კონტეინერია. SSL რეჟიმი და IPsec/IKEv2 რეჟიმი განსხვავდებიან გაცვლით, პორტის მოლოდინებითა და შეცდომის ტექსტით, და იმპორტირებული პროფილი მათ შორის ირჩევს. ამიტომ კლიენტის დაყენება ხელმისაწვდომობაზე არაფერს ამტკიცებს.
ვერსიები წყვილდება მიზეზით. ფუნქციები, ავთენტიფიკაციის ნაკადები და მდგომარეობის შემოწმებები კლიენტსა და ცენტრალურ კვანძს შორის მოლაპარაკდება, ამიტომ ძველი კლიენტი ახალი კვანძის წინაშე ისე შეიძლება ვარდეს, რომ ქსელის ხარვეზად იკითხება. ეს წყვილება კავშირის განსაზღვრებას ეკუთვნის და არა განახლების შენიშვნას.
სხვა ორგანიზაციიდან ექსპორტირებული პროფილი იშვიათად ემთხვევა ადგილობრივ ცენტრალურ კვანძს და მისი იმპორტი კლიენტს შეიძლება დაუტოვოს რეჟიმი, რომელსაც კარიბჭე არ ემსახურება. ჯერ წაიკითხეთ რეჟიმი პროფილიდან, შემდეგ შეადარეთ იგი კარიბჭის კონფიგურირებულ პროტოკოლსა და ავთენტიფიკაციის პოლიტიკას. მხოლოდ მათი დამთხვევის შემდეგ ხდება ქსელი საეჭვო. ეს თანმიმდევრობა ზოგავს პაკეტების ჩაწერას, რომელიც ჯანმრთელ TLS სესიას აჩვენებდა არასწორ სერვისზე მიმართულს.
წაიკითხეთ ადგილობრივი პროფილი, სანამ რამეს შეცვლით
Windows-ში მშობლიური კონფიგურაცია დარეკვის გარეშე იკითხება და გამოტანილი შედეგი პირდაპირ ასახელებს ტიპსა და ავთენტიფიკაციის მეთოდს. შეადარეთ ეს მნიშვნელობები იმას, რასაც კარიბჭის მფლობელი ამბობს, რომ კვანძი იღებს. თუ ტიპი ბილეთს არ ემთხვევა, ჯერ ბილეთი შეასწორეთ, რადგან ეს უფრო იაფია, ვიდრე კლიენტის ხელახლა დაყენება, რომელიც არასდროს ყოფილა არასწორი.
ეს ოთხი ბრძანება ფარავს პროფილს, მის მარშრუტებს, კავშირის ცდასა და პორტის ხელმისაწვდომობას. გაუშვით ისინი ამ თანმიმდევრობით იმ მანქანაზე, სადაც პროფილი უკვე დაყენებულია:
Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443პორტის ტესტი ის არის, რომელსაც ზედმეტად კითხულობენ. TCP 443 მსმენელი, რომელიც შესვლის გვერდს ემსახურება, და ერთი, რომელიც IKEv2-ს ამთავრებს, გარედან ერთნაირად გამოიყურებიან, რადგან პორტი ადგილია და არა პროტოკოლი.
შედეგი ჩაწერეთ სამ ველად: კლიენტი, რეჟიმი და კარიბჭე, და შეინახეთ ბილეთის გვერდით. ყველაფერი უფრო მოკლე მომდევნო ადამიანს იმავე გაურკვევლობის ხელახლა აღმოჩენის საშუალებას აძლევს.