OpenVPN-ის გადატანა TAP-იდან TUN-ზე: მიგრაციის თანმიმდევრობა, რომელიც მუშაობს

dev tap-ის ნაცვლად dev tun ჩასმა ცვლის იმას, რასაც გვირაბი ატარებს და არა მხოლოდ მის სახელს. TAP ინტერფეისი Ethernet ჩარჩოებს ხიდს გადასცემს, ამიტომ კლიენტები ისე იქცევიან, თითქოს ოფისის კომუტატორში არიან ჩართულნი. TUN ინტერფეისი IP პაკეტებს ატარებს, ამიტომ კლიენტებს მარშრუტები სჭირდებათ, ხოლო მეორე მხარეს დაბრუნების გზა. კლიენტები, მისამართების გეგმა და ლოკალური ქსელის დაბრუნების მარშრუტი ყველამ უნდა იმოძრაოს ამ ცვლილებასთან ერთად.

მიგრაცია გვირაბით დამატებული ქსელის გადაპროექტებაა და ქვემოთ მოცემული თანმიმდევრობა მას შექცევადს ხდის.

ჩამოწერეთ, რა არის რეალურად დამოკიდებული Ethernet-ზე

ჩამოთვალეთ აპლიკაციები და არა ჰოსტები. დაადგინეთ, იყენებს თუ არა თითოეული მარშრუტიზებულ TCP ან UDP სერვისებს, მაუწყებლობით აღმოჩენას, ოფისის ლოკალური ქსელიდან DHCP-ს, არა-IP Ethernet პროტოკოლს, თუ იმ ვარაუდს, რომ ორივე მხარე ერთ ქვექსელშია. ჩვეულებრივი IP წვდომა მარშრუტიზებულ დიზაინს უძლებს. პროტოკოლი, რომელსაც ნედლი Ethernet ჩარჩოები სჭირდება, ვერ უძლებს და ვერც ერთი მარშრუტიზაცია ვერ აამუშავებს. აღმოჩენაზე დამოკიდებულ აპლიკაციებს სჭირდებათ შემცვლელი მექანიზმი, რომელიც გადასვლამდე უნდა გადაწყდეს და არა მის დროს.

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

შექმენით მისამართებისა და დაბრუნების მარშრუტების გეგმა

აირჩიეთ კლიენტების პრეფიქსი, რომელიც არ ემთხვევა ლოკალურ ქსელს, ხიდის ძველ დიაპაზონს ან ნებისმიერ ქსელს, რომელზეც კლიენტი უკვე აღწევს.dev tun, topology subnet და server 10.78.0.0 255.255.255.0, მაგრამ ეს ფრაგმენტია და არა მუშა პროფილი. შეინარჩუნეთ მის ირგვლივ დამტკიცებული TLS, იდენტობის, ტრანსპორტისა და წვდომის პოლიტიკა და გამოიყენეთ პრეფიქსი, რომლის თავისუფლებაც შეამოწმეთ.

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

გამოსცადეთ ცალკე მსმენელზე

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

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

გადაიტანეთ კლიენტები ჯგუფებად უკან დაბრუნების შესაძლებლობით

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

ჯგუფები ასევე გაძლევენ ადგილს იმ აპლიკაციის აღმოსაჩენად, რომელიც არავინ ახსენა, მაშინ როცა ძველი გზა ჯერ კიდევ არსებობს შესადარებლად.

გააუქმეთ ხიდი მხოლოდ მიღების შემდეგ

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

მიგრაცია დასრულებულია მაშინ, როცა მარშრუტიზებული წვდომის მოდელი ჩამონათვალისთვის მუშაობს და არა მაშინ, როცა TAP ინტერფეისი ქრება ip link-ის გამოსავლიდან.