Przenoszenie OpenVPN z TAP na TUN: kolejność migracji, która działa

Zamiana dev tap na dev tun zmienia to, co przenosi tunel, a nie tylko jego nazwę. Interfejs TAP przekazuje ramki Ethernet do mostu, więc klienci zachowują się tak, jakby byli podłączeni do biurowego switcha. Interfejs TUN przenosi pakiety IP, więc klienci potrzebują tras, a druga strona potrzebuje drogi powrotnej. Klienci, plan adresów i trasa powrotna LAN muszą przesunąć się razem z tą zmianą.

Migracja to przeprojektowanie sieci z dołączonym tunelem, a poniższa kolejność pozwala je odwrócić.

Zinwentaryzuj to, co naprawdę zależy od Ethernetu

Wypisz aplikacje, nie hosty. Ustal, czy każda z nich korzysta z routowanych usług TCP lub UDP, wykrywania przez rozgłaszanie, DHCP z biurowego LAN, protokołu Ethernet innego niż IP albo założenia, że oba końce są w tej samej podsieci. Zwykły dostęp IP przetrwa projekt routowany. Protokół wymagający surowych ramek Ethernet nie przetrwa i żadna ilość routingu tego nie naprawi. Aplikacje zależne od wykrywania potrzebują mechanizmu zastępczego ustalonego przed przełączeniem, a nie w jego trakcie.

Ta inwentaryzacja jest jednocześnie listą akceptacyjną. Każda pozycja, której nie można przenieść, staje się udokumentowanym wyjątkiem albo powodem, by utrzymać mały segment TAP wyłącznie dla tego obciążenia.

Zbuduj plan adresów i tras powrotnych

Wybierz prefiks klientów, który nie nakłada się na LAN, stary zakres mostu ani żadną sieć, do której klient już dociera. Serwer z topologią podsieci potrzebuje fragmentu takiego jak dev tun, topology subnet i server 10.78.0.0 255.255.255.0, ale to tylko fragment, a nie działający profil. Zachowaj wokół niego zatwierdzoną politykę TLS, tożsamości, transportu i dostępu oraz użyj prefiksu, który zweryfikowałeś jako wolny.

Następnie zapisz miejsca docelowe, do których klienci muszą dotrzeć, i to, kto zapewnia drogę powrotną. Serwer potrzebuje włączonego przekazywania i dozwolonej dalszej drogi. Routery LAN potrzebują trasy z powrotem do nowego prefiksu albo projekt potrzebuje tłumaczenia źródła z wiążącym się z tym kosztem widoczności. Trasa wypychana do klienta konfiguruje klienta, a nie drogę odpowiedzi LAN.

Przetestuj na osobnym nasłuchu

Postaw nową usługę obok starej na własnym porcie i we własnym zakresie adresów, zamiast zastępować jedyny działający punkt wejścia. Wydawaj profile testowe przez istniejący proces rejestracji, aby nikt nie przebudowywał CA z powodu migracji. Podłącz jednego reprezentatywnego klienta z aktywną tylko ścieżką testową, a następnie porównaj przydzielone adresy, prywatny DNS, aplikacje z inwentaryzacji i ścieżki, które powinny pozostać zablokowane.

Uwzględnij test ponownego połączenia i ruchu powrotnego. Ukończony uścisk dłoni nic nie mówi o tym, czy druga strona potrafi odpowiedzieć.

Przenoś klientów grupami z wycofaniem

Migruj grupami tak małymi, by awaria była zadaniem wsparcia, a nie przestojem. Utrzymuj starą usługę w działaniu i udokumentowaną, dopóki rzeczywiste przepływy pracy każdej grupy nie przejdą, a wycofanie zapisz jako powrót do poprzedniego profilu, a nie przebudowę. W miarę przenoszenia każdej grupy aktualizuj reguły zapory oparte na adresach, monitoring i wszelki dostęp inicjowany przez serwer dla nowego prefiksu.

Grupy dają też miejsce na odkrycie aplikacji, o której nikt nie wspomniał, podczas gdy stara ścieżka wciąż istnieje do porównania.

Wycofaj most dopiero po akceptacji

Usunięcie urządzenia TAP to ostatni krok, a nie pierwszy. Sprawdź, czy most nadal przenosi adres zarządzania serwera, ścieżkę monitoringu lub niezwiązane obciążenie, zanim cokolwiek usuniesz. Wycofaj zależności startowe, członkostwo w moście i rezerwacje DHCP przez ich właścicieli, w tej kolejności, z notatką o tym, co zostało usunięte.

Migracja jest skończona, gdy routowany model dostępu działa dla inwentaryzacji, a nie gdy interfejs TAP znika z wyniku ip link.