Android VPN Cisco IOS-ზე: ხელშეკრულება, რომელიც პირველად უნდა მიიღოთ

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

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

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

შეაგროვეთ ინფორმაცია, სანამ რამეს დააყენებთ

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

1. კარიბჭის ჰოსტის სახელი ან მისამართი, რომელზეც კლიენტმა უნდა დარეკოს, და არის თუ არა ის გარედან ხელმისაწვდომი.
2. პროტოკოლი და ვერსია: IKEv2, IPsec-ის სხვა თაობა, ან TLS-ზე დაფუძნებული სერვისი.
3. პარტნიორის იდენტობა, რომელსაც კარიბჭე ელოდება, და რას წარმოადგენს ის თავად სანაცვლოდ.
4. ნდობის მასალა: რომელი CA ხელს აწერს კარიბჭის სერტიფიკატს, ან გამოიყენება თუ არა წინასწარ გაზიარებული გასაღები.
5. მომხმარებლის ავთენტიფიკაცია: სერტიფიკატი, EAP მომხმარებლის სახელი და პაროლი, ან წინასწარ გაზიარებული გასაღები.
6. მისამართების აუზი, რომელშიც კლიენტი ხვდება, ნიღბითა და კარიბჭით.
7. DNS სერვერები გვირაბის შიგნით გამოსაყენებლად და უნდა მიიღოს თუ არა ისინი კლიენტმა.
8. ნებადართული დანიშნულების პრეფიქსები და უნდა დაიბლოკოს თუ არა მათ გარეთ ტრაფიკი.
9. მხარდაჭერილი კლიენტის გამოშვებები და ტელეფონის ოპერაციული სისტემის ვერსიები, ასევე რეგისტრაციის ნებისმიერი მოთხოვნა.

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

მომწოდებლის სახელი პროტოკოლი არ არის

Cisco IOS და IOS XE დისტანციური წვდომის რამდენიმე სქემას გვთავაზობენ და ისინი ერთ გადაცემის ფორმატს არ იზიარებენ. IKEv2 FlexVPN-ის სტილის პროფილით არ არის იგივე სერვისი, რაც ძველი IKEv1 კონფიგურაცია, ხოლო TLS-ზე დაფუძნებული კლიენტის სერვისი კიდევ სხვა პროდუქტია, ხშირად იმავე გარემოში სხვა პლატფორმაზე.

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

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

რას ფარავს Android-ის ჩაშენებული სტეკი

Android პლატფორმის IKEv2/IPsec პროფილს გვაძლევს Ikev2VpnProfile-ის მეშვეობით, ცალკე ავთენტიფიკაციის ტიპებით წინასწარ გაზიარებული გასაღების, RSA სერტიფიკატის და EAP მომხმარებლის სახელისა და პაროლისთვის. Ikev2VpnProfile-ის ცნობარი არის ავტორიტეტი იმაზე, თუ რას იღებს ამგებელი, მათ შორის კარიბჭის ჰოსტის სახელი და სერვერის ძირეული CA, რომელიც მის შესამოწმებლად გამოიყენება.

ეს API შესაძლებლობის განაცხადია, არა თავსებადობის დაპირება. ის ამბობს, რომ პლატფორმას შეუძლია IKEv2 ამ ავთენტიფიკაციის ტიპებით. ის არ ამბობს, რომ რომელიმე OEM-ის პარამეტრების ეკრანი ყველა ველს აჩვენებს, და არც იმას, რომ სხვა პროდუქტიდან ექსპორტირებული პროფილის ფაილი იმპორტირდება.

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

შეამოწმეთ იმ თანმიმდევრობით, რომლითაც ხელშეკრულებაა დაწერილი

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

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

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

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

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

მარცხის რეჟიმები და უკან დაბრუნება

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

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