PPP-ზე დაფუძნებული VPN-იდან მისი დაშვებების კოპირების გარეშე გადასვლა
ჯერ ჩამოწერეთ იდენტობები, მისამართების პულები, მარშრუტები, DNS და წვდომის პოლიტიკა. მომუშავე ხელის ჩამორთმევა ჯერ არ ნიშნავს მიგრაციას, რომელმაც იგივე წვდომის საზღვარი შეინარჩუნა.
VPN-ის მიგრაცია დასრულებულია მაშინ, როცა მომხმარებლები, დანიშნულებები, სახელების გარჩევა და მარცხის ქცევა ჯერ კიდევ სწორია, და არა მაშინ, როცა ახალი კლიენტი მწვანე ხატულას აჩვენებს. ძველი PPP-ზე დაფუძნებული განლაგებები ატარებენ დაშვებებს, რომლებიც არასდროს დაიწერა: საერთო საიდუმლო, რომელიც ერთადერთი იდენტობის შემოწმებაც იყო, ფიქსირებული მისამართების პული, რომელსაც ქსელური ფარი ნებადართულთა სიაში ჰყავს, და DNS-ის სუფიქსი, რომელსაც სერვერი უგზავნის. პროტოკოლის შეცვლა ამ დაშვებების ჩამოწერის გარეშე იძლევა გვირაბს, რომელიც ხელის ჩამორთმევას ასრულებს, და საზღვარს, რომელიც არ არსებობს. ქვემოთ მოცემული თანმიმდევრობა ის არის, რომელსაც მე ვიყენებ, და ბოლო ნაბიჯი არის ის, რომელსაც გუნდები გამოტოვებენ.
ნაბიჯი 1: ჩამოწერეთ, რასაც ძველი კავშირი იძლევა
ინვენტარი იწერება და არ იმახსოვრება. ჩაწერეთ მხარდაჭერილი კლიენტები, აუთენტიფიკაციის როლები, მისამართების პულები, დაცული ქსელები, DNS-ის მოთხოვნები და სერვისის ნებართვები, რომლებიც მომხმარებელთა თითოეულ ჯგუფს სჭირდება.
L2TP/IPsec-ისთვის ორი შრე ცალსახად გამოყავით. IPsec-ის პარტნიორის იდენტობა აუთენტიფიცირებს მანქანებს; PPP აუთენტიფიცირებს მომხმარებელს, ჩვეულებრივ CHAP-ით ან MSCHAPv2-ით.
სწორედ ამ გამოყოფაში მალავენ ძველი განლაგებები თავიანთ დაშვებებს. წინასწარ გაზიარებული გასაღები, რომელსაც ყველა კლიენტი იზიარებს, აუთენტიფიცირებს ჯგუფს და არა მოწყობილობას, და ხშირად ეს არის ერთადერთი, რაც ოდესმე შეცვლილა. თუ PPP-ის ანგარიშია ნამდვილი მომხმარებელზე დაფუძნებული კონტროლი, თქვით ეს, რადგან ჩანაცვლებამ ის კონტროლი უნდა გაამრავლოს ისეთი რამით, რაც საერთო სტრიქონი არ არის. ჩაწერეთ ასევე ფიქსირებული წყაროს მისამართები და ლოკალური ქსელის გამონაკლისები, რადგან ეს არის ის დამოკიდებულებები, რომლებსაც არავინ არ ადოკუმენტირებს, სანამ ისინი არ გატყდება.
ნაბიჯი 2: დააპროექტეთ ჩანაცვლება განზრახ
ჩანაცვლების არჩევა არის მოთხოვნა-მოთხოვნით დათვალიერება: პროტოკოლი და მხარდაჭერილი კლიენტი, რომელსაც ორგანიზაცია უჭერს მხარს, და ყოველი იდენტობისა და წვდომის მოთხოვნა ხვდება რეალურ მექანიზმში. საერთო საიდუმლო ავტომატურად არ უდრის მოწყობილობის გასაღებს ან სერტიფიკატს, და მომხმარებელზე დაფუძნებული PPP-ის ანგარიში არ უდრის მოწყობილობის სერტიფიკატს.
მისამართების დიაპაზონები ყველაფერზე ადრე შეათანხმეთ, რადგან სახლის ან ოფისის LAN-ს გადამფარავი ჩანაცვლების პული ქმნის ხარვეზს, რომელსაც შიფრის სიმტკიცესთან კავშირი არ აქვს. შეამოწმეთ პული იმავე სიის მიმართ, რომელიც ძველი სერვისისთვის შეადგინეთ, და ასევე იმის მიმართ, რასაც ახალი კლიენტი ნაგულისხმევად ვარაუდობს. დაადასტურეთ დაცული ქსელების უკუმარშრუტიზაცია და დაადასტურეთ, რომ ახალ კლიენტს შეუძლია გაგზავნოს ან დაადოკუმენტოს ის DNS-ის სუფიქსი, რომელსაც ძველი აგზავნიდა. ეს ორი პუნქტი უფრო მეტ მიგრაციის ბილეთს ქმნის, ვიდრე თავად პროტოკოლის ცვლილება.
ნაბიჯი 3: დანერგეთ ეტაპობრივად და გადაამოწმეთ როგორც ნებართვა, ისე აკრძალვა
დანერგეთ ერთი წარმომადგენლობითი მომხმარებლითა და ერთი წარმომადგენლობითი აპლიკაციით. ტესტში შეიტანეთ კერძო DNS-ის გარჩევა, რადგან გვირაბი, რომელიც მისამართს აღწევს, მაგრამ შიდა სახელს ვერ ხსნის, მხოლოდ ნახევრადაა მიგრირებული. შეიტანეთ ასევე მოსალოდნელი მიუწვდომლობის მდგომარეობა: რა უნდა მოხდეს, როცა გვირაბი ვარდება, და აღასრულებს თუ არა ამას კლიენტი.
შემდეგ გამოსცადეთ დანიშნულება, რომელიც აკრძალული უნდა დარჩეს. ფართო დროებითი ნებართვის წესი შეიძლება ახალი გვირაბი ჯანმრთელად აჩვენოს, სანამ ჩუმად აშორებს იმ ავტორიზაციის საზღვარს, რომელსაც ძველი სერვისი აღასრულებდა, და ვერავინ შეამჩნევს აუდიტამდე. შეადარეთ ნებართვისა და აკრძალვის შედეგები გვერდიგვერდ, იმავე კლიენტიდან, იმავე სესიაში. ძველი სერვისი მუშაობაში შეინარჩუნეთ მანამ, სანამ ორივე სვეტი არ დაემთხვევა პროექტს.
ადმინისტრატორის წვდომის გადატანამდე დაადასტურეთ, რომ გაქვთ ავტორიზებული აღდგენის გზა, რომელიც არ არის დამოკიდებული იმ გვირაბზე, რომელსაც ცვლით.
ნაბიჯი 4: გააუქმეთ ძველი იდენტობა
ძველი იდენტობის სწორად გაუქმება ნიშნავს მოძველებული მომხმარებლებისა და მოწყობილობის სერთიფიკატების გაუქმებას იმ სერვისის მეშვეობით, რომელიც ფლობს მათ, შემდეგ კი ძველი პროფილებისა და მსმენელების წაშლას, როცა დამოკიდებულება აღარ რჩება. ლოკალური ფაილის წაშლა არ აუქმებს სხვაგან არსებულ ასლს, და ძველი მსმენელი, რომელიც ჯერ კიდევ იღებს ძველ საერთო საიდუმლოს, დაუკვირვებელი კარია.
ამ წერტილზე შენელება ღირს. ლეპტოპზე გაუქმებული კლიენტის პროფილი არ არის გაუქმებული სერთიფიკატი; სერთიფიკატი სერვერზე ცხოვრობს და ძალაში რჩება მანამ, სანამ სერვერი არ შეწყვეტს მის მიღებას. მოძებნეთ ძველი კონფიგურაციის სხვა ასლები — სატესტო მოწყობილობები, დავიწყებული ტელეფონი, ვიღაცის მიერ შენახული ინსტალატორი — და მსმენელის გამორთვა მიიჩნიეთ იმ მომენტად, როცა ძველი სერვისი ნამდვილად მთავრდება. მანამდე მიგრაციას ორი წინა კარი აქვს.
მიღების ჩანაწერი არის პირველი ნაბიჯის ინვენტარი დამატებული სვეტით: რას აკეთებს ახალი პროექტი თითოეული რიგისთვის და როგორ გადაამოწმეთ ის. ეს პროტოკოლის განახლებას აქცევს მტკიცებულებიან სერვისის მოთხოვნად.
შედეგი მიაბით სერვისის საჭიროებას და არა პროტოკოლის სახელს, რადგან ძველი დაშვებებით გადაკოპირებული თანამედროვე პროტოკოლი იგივე რისკია უკეთესი ჩარჩოთი. RFC 3193 აღწერს, როგორ გადაიზიდება L2TP IPsec-ის თავზე, რაც სასარგებლო შეხსენებაა, რომ ეს ორი შრე ყოველთვის ცალკე გადაწყვეტილება იყო. თუ ინვენტარში არის სტრიქონი, რომელსაც ვერ ხსნით, გაჩერდით და გაარკვიეთ, რა არის მასზე დამოკიდებული. მიგრაცია დასრულებულია, როცა სია მოსაწყენი ხდება.