IKEv1 XAuth-ითა და OTP-ით: რას ითხოვს ყოველი მოთხოვნა
ჯგუფური PSK, მომხმარებლის XAuth გაცვლა და OTP გამოწვევა სამი განსხვავებული შეყვანაა. დაუკავშირეთ ყოველი მოთხოვნა მის მფლობელს, სანამ სხვა კლიენტს დააყენებთ.
IKEv1 PSK-ით, XAuth-ითა და OTP-ით არ ითხოვს ერთ რთულ პაროლს. ის ფენებად აწყობს პირებს შორის გაზიარებულ გასაღებს, მომხმარებლის გაცვლას და მეორე ფაქტორს, რომლის მოთხოვნის წესს backend განსაზღვრავს. თითოეულ ფენას თავისი მფლობელი და თავისი შეცდომის შეტყობინება აქვს. მათი არევა აიძულებს ადამიანებს ხელახლა აკრიფონ ერთჯერადი კოდი ველში, რომელიც ჯგუფურ საიდუმლოს ინახავს.
დაუკავშირეთ ყოველი მოთხოვნა იმ ფენას, რომელიც მას ითხოვს, სანამ სხვა კლიენტს დააყენებთ ან ანგარიშის მონაცემებს აღადგენთ.
სამი საიდუმლო, სამი მფლობელი
წინასწარ გაზიარებული გასაღები პირთა ურთიერთობას ეკუთვნის და მას ერთხელ აყენებს ის, ვინც ორივე ბოლოს მართავს. მომხმარებლის მონაცემები ავთენტიფიკაციის backend-ს ეკუთვნის და ყოველ შესვლაზე მოწმდება. მეორე ფაქტორი ტოკენების სისტემას ეკუთვნის, რომლის პასუხიც ყოველ ცდაზე იცვლება. არც ერთი არ ცვლის მეორეს და განლაგება, რომელიც მათ ერთ პაროლად თვლის, იმ ფენაზე ფუჭდება, რომელიც არავის აღუწერია.
ჩაწერეთ სამი სვეტი: მფლობელი, ვადა და შეცდომის შეტყობინება, რომელსაც თითოეული წარმოქმნის. სწორედ ეს ცხრილია დიაგნოსტიკის იარაღი და არა კლიენტის ველების სახელები.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: პირის კი არა, წყვილის
ამ ძველ განლაგებაში წინასწარ გაზიარებული გასაღები gateway-ების წყვილს ავთენტიფიცირებს, ამიტომ მომხმარებლის შესვლა მას არასოდეს ცვლის. ის ასევე არის მნიშვნელობა, რომელიც ყველაზე ხშირად იმგვარად არის არასწორი, რომ ზოგადი მოლაპარაკების შეცდომას იძლევა მოთხოვნის ნაცვლად. როცა გვირაბი იმარცხებს მომხმარებლის ნებისმიერი მოთხოვნის გამოჩენამდე, ეჭვმიტანილები გასაღები ან წინადადებები არიან.
მომხმარებლის მონაცემები პირველი ფაზის ჩავარდნას ვერ გამოასწორებს. მისი როტაცია ხარჯავს ერთადერთ მონაცემს, რომლის უსაფრთხოდ როტაციაც შეგიძლიათ, და ამყარებს არასწორ თეორიას.
XAuth: ძველი მომხმარებლის გაცვლა
XAuth ამატებს მომხმარებლის ავთენტიფიკაციის გაცვლას IKEv1-ის წყვილის ავთენტიფიკაციის ზემოთ და gateway წყვეტს, რომელი backend ამოწმებს მას. ამ backend-ის მიხედვით, გაცვლამ შეიძლება მიიღოს დირექტორიის პაროლი, RADIUS მონაცემები ან ტოკენის პასუხი. სიტყვა XAuth გაცვლის ტრანსპორტს აღნიშნავს და არა მონაცემის ტიპს.
შეამოწმეთ, რომელ backend-ზე მიუთითებს gateway-ის პროფილი. ეს გეტყვით, რას მოსთხოვენ მომხმარებელს და რას ცვლის სინამდვილეში პაროლის აღდგენა, და არც ერთი მათგანი კლიენტის პროფილში არ ჩანს.
OTP: რასაც backend მოითხოვს
ზოგიერთი განლაგება პაროლის შემდეგ ცალკე ერთჯერად კოდს ითხოვს, სხვები კი დოკუმენტირებული გამყოფით კომბინირებულ შეყვანის ფორმატს განსაზღვრავენ. ორივე არსებობს და თქვენს წინ არსებული პროფილი წყვეტს რომელი. კონკატენაციის გამოგონება იმიტომ, რომ სხვაგან იმუშავა, სარეგისტრაციო ტოკენის დაწვის ყველაზე გავრცელებული გზაა. ამას მხოლოდ თავად gateway-ის დოკუმენტაცია წყვეტს.
გამოიყენეთ დოკუმენტირებული ფორმატი კლიენტთან, რომელსაც შეუძლია gateway-ის მიერ შემოთავაზებული გაცვლის დასრულება.
სად კბენს კლიენტის საზღვარი
Fortinet აღნიშნავს, რომ FortiClient 7.4.4 და უფრო ახალი ვერსიები აღარ უჭერენ მხარს IKEv1-ს IPsec VPN-ებისთვის, რაც პროდუქტისა და ვერსიის საზღვარია და არა საყოველთაო მოხსნა, როგორც FortiClient-ის თავსებადობის შენიშვნა აღრიცხავს. სხვა კლიენტებიც არ არიან ურთიერთშემცვლელი: OpenConnect და openfortivpn კონკრეტულ gateway პროტოკოლებზე საუბრობენ და არა თვითნებურ IKEv1 პროფილებზე. ცალ-ცალკე შეამოწმეთ დაყენებული კლიენტის IKE ვერსია, PSK რეჟიმი, XAuth მხარდაჭერა და ინტერაქციის მოდელი. კლიენტი, რომელიც სხვა მეთოდით უერთდება, საწყის მოთხოვნას არ უმტკიცებია.
IKEv1 მოძველებულია, ამიტომ მხარდაუჭერელი ძველი კლიენტის საფუძველზე აშენებული ახალი განლაგება ხანმოკლე გადაწყვეტაა. სთხოვეთ gateway-ის მფლობელს მხარდაჭერილი მიგრაციის გზა, მათ შორის, როგორ გაუმკლავდებიან იქ მეორე ფაქტორს.
დიაგნოსტიკა ფაქტორის გამორთვის გარეშე
ჟურნალში გამოყავით ეტაპები: წყვილის მოლაპარაკება, მომხმარებლის გაცვლა, მეორე ფაქტორის შედეგი, შემდეგ მისამართისა და მარშრუტის მინიჭება. ჩაწერეთ კომპონენტი და ეტაპი იმის ნაცვლად, რომ კოდი ყველა ველში სცადოთ. ფაქტორის გამორთვა იმისთვის, რომ ტესტმა გაიაროს, ქმნის გვირაბს, რომელიც განლაგების შესახებ არაფერს ამტკიცებს.
შეინახეთ სარეგისტრაციო საიდუმლოებები და გაზიარებული გასაღები დაცულ საცავში ორგანიზაციის პროცესის მიხედვით. მუდმივ ფაილში არსებული ერთჯერადი კოდი ფაქტორია, რომელმაც შეწყვიტა ფაქტორი ყოფნა.