Co migracja VPN musi zachować z łącza dzierżawionego
Łącze dzierżawione niosło adresację, opóźnienie i obietnice wsparcia. Zinwentaryzuj je, poprowadź oba kierunki i przyjmij tunel najpierw z rzeczywistym ruchem.
Łącza dzierżawione łatwo opisać i trudno zastąpić, bo umowa obejmowała więcej niż kabel. Niosło przekazanie, plan adresacji, oczekiwane opóźnienie i porozumienie o wsparciu, a tunel, który je zastępuje, dziedziczy wszystkie cztery, niezależnie od tego, czy ktoś je zapisał. Migracje zawodzą, gdy zespół kopiuje konfigurację routingu i resztę nazywa problemem operacyjnym. Zacznij od wymagań, a potem udowodnij każde na nowej ścieżce, zanim stara zostanie wyłączona.
Zamień łącze w listę właściwości
Pierwsze pytanie dotyczy tego, co stary serwis faktycznie przekazał: łącze routowane z małą podsiecią czy segment warstwy 2 współdzielony między lokalizacjami. Ta różnica decyduje, czy tunel IP może to w ogóle odtworzyć, bo tunel przenosi pakiety między dwoma adresami i nie przenosi wykrywania rozgłoszeniowego ani dowolnych EtherTypes. Łącze, które przedstawiało się jako port przełącznika, to inna migracja niż łącze, które przedstawiało /30.
Zapisz prefiksy lokalizacji, adresy bram, aplikacje, które wpisują adresy we własną konfigurację, oraz prefiksy, które gdzie indziej w środowisku na siebie nachodzą. Plan adresacji, który przetrwa migrację, jest wynikiem projektowania, a nie założeniem. Te cztery listy stają się później także kryteriami odbioru, więc trzymaj je tam, gdzie testerzy mogą je przeczytać.
Poprowadź nową ścieżkę w obu kierunkach
Tunel, który się podniesie, to tylko połowa drogi. Druga strona potrzebuje trasy powrotnej do każdego lokalnego prefiksu, a strona lokalna musi preferować tunel dla tych prefiksów, nie kradnąc ruchu, który nadal ma wychodzić przez internet. Przekazywanie asymetryczne to zwykły objaw tego, że jedna z tych połówek jest zrobiona poprawnie. Sprawdź tablicę drugiej strony tak samo starannie jak swoją, bo trasa powrotna to ta, której nikt nie skonfigurował.
ip route get 10.20.0.10Routing oparty na polityce czyni podział jawnym: oznacz ruch należący do pary lokalizacji i daj mu tablicę, której domyślnym wpisem jest tunel. IPsec dostarcza chronione stowarzyszenie i politykę, która decyduje, co do niego wchodzi, ale nie trasy wokół niego, jak opisuje architektura IPsec jako całość. Gdy znacznik pasuje zbyt szeroko, zwykły ruch webowy z lokalizacji też wchodzi do tunelu i wychodzi niewłaściwym wyjściem.
Przełącz się z wycofaniem, które już przetestowałeś
Dwie żywe ścieżki z różnymi właścicielami zachęcają do przekazywania asymetrycznego, więc podnieś nową w zdefiniowanym oknie i przenoś prefiksy w ogłoszonej kolejności. Zostaw stare łącze skonfigurowane i utrzymuj pozapasmową ścieżkę zarządzania, która nie zależy od żadnego z tuneli. Przenoś po jednym prefiksie tam, gdzie aplikacje na to pozwalają, i obserwuj tablicę sesji między przeniesieniami.
Zdecyduj z góry, jakie dowody upoważniają przełączenie i jaki warunek uruchamia wycofanie. Wycofanie, które wymaga naprawy nowego VPN przez nieudane połączenie, nie jest wycofaniem. Sformułuj wyzwalacz jako mierzalny warunek, a nie jako odczucie w sali.
Przyjmij z ruchem, który łącze naprawdę niosło
Ping dowodzi osiągalności i niewiele więcej. Przetestuj rozwiązywanie nazw, długotrwałe sesje, odrzucone przepływy i rozmiary pakietów, które stara ścieżka obsługiwała bez fragmentacji. MTU to miejsce, w którym tunele najczęściej różnią się od łącza, bo enkapsulacja zużywa bajty, które aplikacja uważała za dostępne. Zmierz największy ładunek, który przechodzi bez fragmentacji w obu kierunkach, nie tylko w stronę serwera.
ping -M do -s 1400 -c 3 10.20.0.10Jeśli ładunek 1400 bajtów przechodzi, a 1472 nie, maksimum ścieżki jest mniejsze, niż oczekują aplikacje, i znalazłeś rzeczywistą regresję, a nie kosmetyczną. Porównaj ten wynik z wymaganiami zapisanymi w pierwszym kroku i wycofaj łącze tylko wtedy, gdy właściciele tych aplikacji zaakceptują pomiar. Właśnie ten podpis zamienia udany test w zaakceptowaną migrację.