VPN ავთენტიფიკაციის backend-ის მიგრაცია ძველი ჰეშების ხელახლა გამოყენების გარეშე
VPN იდენტობების გადატანა გადასვლაა და არა ასლი: ავთენტიფიკაციის ჯაჭვის რუკა შეადგინე, საპილოტე ჯგუფი გადაიტანე, სერტიფიკატების ცვლილებები გამოსცადე და დაგეგმე აღდგენა, რომელსაც გადატვირთვა არ გააუქმებს.
მომხმარებლის სახელები ახალ კატალოგში ჩნდება, მიგრაცია დასრულებულად გამოცხადდება და შესვლები მაინც ვერ ხდება. კარიბჭეს კვლავ სჭირდება მხარდაჭერილი ავთენტიფიკაციის გზა და სწორი ავტორიზაციის შედეგი და არც ერთი მათგანი არ გამომდინარეობს კატალოგიდან, რომელიც ახლა ანგარიშებს შეიცავს. Backend-ის გადატანა სასიცოცხლო ციკლის მქონე გადასვლაა, არა კოპირების სამუშაო. ქვემოთ მოცემული სიმპტომია ის, რომელიც ჩვეულებრივ ავლენს განსხვავებას.
სიმპტომი: ანგარიშები არსებობს, სესიები არა
ახალი კატალოგი ყველა მომხმარებლის სახელს შეიცავს, სატესტო მიბმა წარმატებით სრულდება და VPN კლიენტი მაინც აბრუნებს ავთენტიფიკაციის შეცდომას. ასეთი კომბინაცია ნიშნავს, რომ იდენტობა არსებობს, მაგრამ კარიბჭის მიერ გამოყენებული შემოწმების გზა ვერ აღწევს მას, ან აღწევს მეთოდით, რომელსაც ვერ დააკმაყოფილებს. ორივე კონფიგურაციაა და ეს სხვადასხვა პრობლემაა.
პირველი გაყვანილობაა: კარიბჭე მიუთითებს backend-ზე, რომელიც არ პასუხობს, იყენებს საერთო საიდუმლოს, რომელსაც მეორე მხარე არ ელოდება, ან ითხოვს ატრიბუტს, რომელსაც ახალი სერვისი არ აბრუნებს. მეორე კრიპტოგრაფიულია: მეთოდი მოითხოვს თავდაპირველ საიდუმლოს და ახალი საცავი მხოლოდ მის ჰეშს ინახავს. შეცდომის ტექსტი ორივე შემთხვევაში მსგავსია, ამიტომ ორივეს ერთ პრობლემად განიხილავენ.
ამ ორის გამოყოფა ანგარიშებზე შეხებამდე კვირას ზოგავს. ერთი მარშრუტიზაციისა და ნდობის საკითხია, მეორე სერტიფიკატების გადატვირთვის გადაწყვეტილება, და მათი შერევა ცვლილებებს ქმნის, რომლებსაც ვერავინ მიაკუთვნებს.
ჯაჭვის რუკა შეადგინე, სანამ ვინმეს გადაიტან
თითოეული კლიენტის პროფილისთვის ექვსი რამ ჩაწერე: გარე ავთენტიფიკაციის მეთოდი, შესაძლო შიდა მეთოდი, სერვერის იდენტობა, რომელსაც კლიენტი ელოდება, ინტერფეისი კარიბჭესა და backend-ს შორის, ატრიბუტი, რომელსაც კარიბჭე ჯგუფის წევრობაზე ასახავს, და აქედან გამომდინარე რესურსების პოლიტიკა. მათი თანმიმდევრობით კითხვა გვიჩვენებს, რომელ რგოლს არ ჰყავს მფლობელი. თითოეულ ელემენტს ჰყავს მფლობელი და გადასვლა იმარცხებს იმაზე, რომელიც არავინ შეამოწმა.
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
ჩვეულებრივი კატალოგში შესვლა ამ ჯაჭვის თითქმის არაფერს გადის. ის ამტკიცებს, რომ ანგარიში არსებობს და პაროლი მუშაობს, ესე იგი ზუსტად ის ნაწილი, რომელიც არასდროს ყოფილა ეჭვქვეშ.
ჰეშები მეთოდებს შორის არ მოძრაობს
სერტიფიკატების თავსებადობა ერთხელ უნდა შემოწმდეს, სანამ რომელიმე ჯგუფი გადაადგილდება. FreeRADIUS ნათლად აღწერს გაყოფას: CHAP შემოწმებას, რომელსაც თავად სერვერი ასრულებს, სჭირდება ნამდვილი პაროლი, ხოლო MS-CHAP იღებს ამ პაროლს ან შესაბამის NT მასალას. სხვა მიზნისთვის შექმნილი ჰეში არც ერთ შემთხვევას არ ერგება, რაც არ უნდა ძლიერი იყოს.
განსხვავება იმაშია, ვინ ითვლის მტკიცებულებას. მეთოდი, რომელიც კატალოგზე მიბმით ამოწმებს, კატალოგს აძლევს საშუალებას შეამოწმოს ის, რაც შეუძლია. მეთოდი, რომელიც გამოწვევის პასუხის გადათვლით ამოწმებს, თავად საიდუმლოს მოითხოვს, რადგან სერვერმა იგივე გამოთვლა უნდა შეასრულოს.
სადაც მასალა აკლია, პატიოსანი ვარიანტებია მხარდაჭერილი გადატვირთვა, ხელახალი რეგისტრაცია, გარე შემოწმების სერვისი ან მეთოდის შეცვლა. აღდგენადი პაროლების დროებითი ექსპორტი ამ სიაში არ არის. ის ქმნის ღია ტექსტურ სერტიფიკატების საცავს პროექტის ყველაზე ქაოტურ კვირაში და ჩვეულებრივ გადატანას გადაურჩება.
საპილოტე ჯგუფი, შემდეგ სასიცოცხლო ციკლის ცვლილებები
დამტკიცებული იდენტობების მცირე ჯგუფი რეალური კლიენტით გადაიტანე და ოთხი რამ გამოსცადე: ახალი შესვლა, განზრახ არასწორი სერტიფიკატი, რესურსები, რომლებზეც სესიას წვდომა შეუძლია, და რესურსები, რომლებზეც არ უნდა ჰქონდეს. კლიენტის მიერ მიღებული სერვერის იდენტობაც შეამოწმე, რადგან სერტიფიკატის სახელის შეუსაბამობა უხილავია, სანამ ვინმე კლიენტის ჟურნალს წაიკითხავს.
შემდეგ გამოსცადე ცვლილებები, რომლებზეც დანერგვა ნამდვილად არის დამოკიდებული. შეცვალე პაროლი, განაახლე ან ხელახლა დაარეგისტრირე სერტიფიკატი და ერთ საპილოტე ანგარიშს წვდომა მოუხსენი. თითოეულის შემდეგ დაადასტურე, რომელმა გადამმოწმებელმა დაამუშავა მცდელობა, რადგან გადასვლამდე შექმნილმა სესიამ შეიძლება განაგრძოს მუშაობა და არაფერს ამტკიცებს შემდეგი შესვლის შესახებ.
პროფილის მიწოდება იდენტობის შეცვლისგან გამოყავი. თითოეულ ჯგუფს სჭირდება განკუთვნილი პროფილი, სერტიფიკატის ან რეგისტრაციის მდგომარეობა, ავთენტიფიკაციის სერვისი, რომელიც უნდა გამოიყენოს, და მხარდაჭერის კონტაქტი, და ამ ჩანაწერებიდან არც ერთი არ უნდა შეიცავდეს საიდუმლოს.
თუ ძველი და ახალი გზა ერთად არსებობს, დასრულების თარიღით შემოსაზღვრე. ავტომატურმა უკუქცევამ შეიძლება ანგარიში ძველი სერტიფიკატით შემოუშვას მას შემდეგ, რაც ახალმა მფლობელმა წვდომა მოხსნა, და ეს ხელმისაწვდომობის ნიღბით დაფარული უსაფრთხოების რეგრესიაა.
უკან დაბრუნება ვერ აღადგენს სერტიფიკატს
გადასვლის შებრუნება კატალოგს ზუსტად იმ მდგომარეობაში ტოვებს, რომელშიც ახლა არის. გადატვირთული პაროლი გადატვირთული რჩება, გაუქმებული სერტიფიკატი გაუქმებული რჩება, ხოლო შეცვლილი სერტიფიკატის ფორმატი შეცვლილი რჩება. ეს კატალოგში მომხდარი მოვლენებია და კარიბჭე არასდროს ყოფილა მათი წყარო. აღდგენა თითოეული მოვლენისთვის უნდა განისაზღვროს და ამის არც ერთი ნაწილი არ უნდა იყოს დამოკიდებული საიდუმლოს აღდგენაზე შეუთავსებელი ჰეშიდან.
შეინარჩუნე ადმინისტრაციული გზა, რომელიც არ იყენებს მიგრირებულ კავშირს. როცა ახალი ავთენტიფიკაცია ვერ მუშაობს, შეაჩერე ჯგუფი და გამოიყენე მისი დოკუმენტირებული აღდგენის გზა იმის ნაცვლად, რომ ვადის დაცვისთვის ყველასთვის ავთენტიფიკაცია დასუსტდეს.
ჯგუფების დაფარვის შემდეგ ძველი backend სერტიფიკატები, პროფილები და ნდობის ურთიერთობები მფლობელების მეშვეობით გააუქმე. დაადასტურე, რომ ძველი გზა აღარ უშვებს მომხმარებლებს, და შეინარჩუნე საიდუმლოს არმქონე იდენტობა-პოლიტიკის ასახვა, რომელიც მხარდაჭერას ჯერ კიდევ სჭირდება. მიგრაცია დასრულებულია, როცა ახალი სასიცოცხლო ციკლი მუშაობს და ვეღარავინ შედის ძველი გზით, და არა მაშინ, როცა ანგარიშების სია სრულად გამოიყურება.