Przeniesienie jednej podsieci na nowy tunel VPN bez przerwy

Podnieś nowy tunel, przenieś jedną podsieć, i ta podsieć teraz okresowo zawodzi, podczas gdy wszystko inne działa bez zarzutu. Na wpół zmigrowane VPN-y zawodzą dokładnie tak, bo tunel nigdy nie był trudną częścią. Ścieżka obejmuje też to, która trasa wygrywa, które selektory pasują, co dopuszczają reguły dostępu, jak wracają odpowiedzi i każde tłumaczenie, które stosował stary projekt. Przenieś sam tunel, a nie przeniesiesz niczego z tego.

Tunel to łatwiejsza połowa ścieżki

Okresowe awarie po częściowej migracji zwykle oznaczają, że obie ścieżki są możliwe. Niektóre przepływy wybierają nowy tunel, inne zostają przy starym, a urządzenie pamiętające stan widzi wtedy odpowiedź przychodzącą ścieżką, której żądanie nigdy nie użyło. Dwie ścieżki nie są automatycznie bezpieczniejsze niż jedna; to dwie rzeczy, które mogą się nie zgadzać. Patrz na raporty o migotaniu, a nie na liczniki tunelu, bo liczniki będą wyglądać zdrowo przez cały czas.

Użyteczne pierwsze pytanie nie brzmi, który tunel jest lepszy. Brzmi: które przepływy wybierają dziś którą ścieżkę i czy żądanie oraz odpowiedź dostają tę samą odpowiedź.

Zbuduj cel, zanim go preferujesz

Potwierdź, że peery są zgodne i że nowy tunel niesie zamierzony zakres adresów. Dodaj przekazywanie i uprawnienia usług, których potrzebuje, dopóki jest jeszcze ścieżką niepreferowaną, aby samo przełączenie zmieniało tylko wybór i nic więcej.

Zapytaj zdalną lokalizację, jak będzie zwracać ruch. Jeśli odpowiedzi nadal wychodzą starym tunelem, nowa trasa lokalna powoduje asymetrię albo nie przechodzi filtra pamiętającego stan. Tłumaczenie też należy do projektu z tego samego powodu: zmieniony adres źródłowy zmienia także ścieżkę powrotną.

Przełącz wąsko i znaj drogę powrotną

Nazwij dokładną podsieć i mechanizm wspierany przez platformę, który preferuje jej nową trasę lub selektor. Definicje oparte na politykach nie zawsze zachowują się jak metryki tras, więc przeczytaj reguły nakładających się polityk w swojej implementacji, zanim uznasz, że wygrywa bardziej szczegółowe dopasowanie.

Przenieś jedną podsieć, nie jedną lokalizację. Zostaw dostęp zarządzający na ścieżce, której nie dotykasz, i zapisz wycofanie, zanim cokolwiek zastosujesz: która trasa lub polityka wraca, kto to robi i jak pozostają połączeni, kiedy to robią.

Asymetria i nieaktualny stan

Zapory i urządzenia NAT pamiętają interfejs, którego użył przepływ. Gdy żądanie i odpowiedź idą różnymi tunelami, urządzenie może odrzucić odpowiedź, choć każda ścieżka działa sama. Testuj przepływem, który otworzysz po zmianie, bo ustanowiona sesja może przez godziny dalej używać starej ścieżki.

Jeśli obserwowany adres źródłowy się przesunął, znajdź każdą politykę, która wymienia stary. Migracja, która po cichu zmienia źródło, łamie reguły, których nikt nie zaklasyfikował jako część projektu VPN.

Udowodnij obie odpowiedzi, a potem wycofaj starą politykę

Ze zwykłego hosta w zmigrowanej podsieci dotrzyj do zamierzonej usługi i sprawdź obserwowane źródło oraz interfejs odpowiedzi. Następnie przetestuj sieć, która ma pozostać na starym tunelu, bo migracja kończy się dopiero wtedy, gdy obie odpowiedzi są poprawne. Drugi test to ten, który ludzie pomijają, i to on łapie selektor szerszy, niż zamierzałeś.

Wycofaj przestarzałą politykę dopiero wtedy, gdy żadna pozostała podsieć od niej nie zależy, i zapisz końcową trasę wraz z jej właścicielem w inwentarzu selektorów. Ukończenie to nie to, że nowy tunel zgłasza, że jest podniesiony; to to, że każda sieć podąża swoją zamierzoną ścieżką.