Wybierz stabilne źródło rejestracji dla członków GET VPN

Ktoś kieruje rejestrację członka grupy na adres loopback i ogłasza, że niestabilność GET VPN została rozwiązana. Czasem tak jest. Często loopback jest osiągalny tylko z własnej tablicy routingu członka i znikąd indziej, więc rejestracja znów się psuje, gdy następnym razem zapłonie uplink, który ją niósł. Adres rejestracji to tożsamość w płaszczyźnie sterowania i pomaga tylko wtedy, gdy w obu kierunkach istnieje rzeczywista ścieżka. Wybranie go świadomie jest tego warte i to mniejsza zmiana, niż sugeruje obiegowa opinia.

Co identyfikuje adres rejestracji

We wdrożeniu GDOI członek grupy rejestruje się na serwerze kluczy i otrzymuje od niego politykę grupy. Adres, który serwer kluczy zapisuje, jest tożsamością członka w tej rozmowie.

Ta tożsamość obejmuje rozmowę sterującą: rejestrację, odświeżanie kluczy i pobieranie polityki. Nie staje się źródłem ruchu klientów, i nie zmienia, które interfejsy chronią które przepływy.

Rozdzielenie obu rzeczy to pierwszy krok, ponieważ większość zamieszania wokół tego ustawienia bierze się z oczekiwania, że zmiana w płaszczyźnie sterowania naprawi objaw w płaszczyźnie danych.

Loopback jest tyle wart, ile jego trasa

Loopback daje członkowi adres logiczny, który nie znika, gdy jeden fizyczny uplink zawiedzie. To realna korzyść na routerze z kilkoma ścieżkami do serwera kluczy.

Ale to też tylko adres. Jeśli serwer kluczy nie ma trasy powrotnej, rejestracja zawodzi dokładnie tak jak wcześniej. Jeśli tablica routingu członka dociera do serwera kluczy tylko przez jeden uplink, loopback jest stabilny, a ścieżka nie.

Sprawdź osiągalność w obu kierunkach przez każdy uplink, który ma przetrwać. Loopback utrzymujący się administracyjnie nie dowodzi niczego o przekazywaniu, a awaria pojawia się jako nieosiągalny serwer kluczy, a nie jako problem interfejsu. Zapisz sprawdzenie jako polecenie na uplink, a nie jako założenie. Wtedy następne okno zmian zaczyna się od dowodów, a nie od schematu.

Trzymaj sterowanie i ruch chroniony osobno

Przewodnik Cisco dotyczący omijania GDOI opisuje interfejs rejestracji oraz relację między rejestracją a obsługą omijania. Czytaj zachowanie dla wersji, którą naprawdę uruchamiasz, zamiast traktować jedno zdanie jako uniwersalne polecenie.

Przejrzyj filtrowanie i translację na ścieżce sterującej i potwierdź, że ruch zarządzania kluczami nie trafia przypadkiem do polityki ochrony, która zależy właśnie od polityki grupy, którą próbuje pobrać. Taka zależność cykliczna to klasyczny sposób na to, by działające wdrożenie zawiodło po zmianie polityki.

Polityka płaszczyzny danych to odrębny projekt. Zmiana tego, skąd pochodzi rejestracja, pozostawia chronione przepływy, selektory i reguły omijania dokładnie tam, gdzie były.

Sprawdź tożsamość podczas przejścia

Przed zmianą zapisz grupę, wybrany adres rejestracji, miejsce docelowe serwera kluczy, kontekst routingu i dozwoloną ścieżkę sterującą. Po zatwierdzonej zmianie uplinku sprawdź ponownie widok zarejestrowanych członków na serwerze kluczy i stan sterowania członka.

To, co chcesz zobaczyć, to zamierzony logiczny punkt końcowy wciąż osiągalny i wciąż przedstawiony tak, jak go zaprojektowałeś. To, czego nie chcesz, to druga rejestracja z adresu, którego nie zamierzałeś, bo właśnie tak pojawiają się zduplikowane wpisy członków.

Potem przetestuj chroniony ruch aplikacji osobno. Przesyłanie może się udać, podczas gdy następne odświeżenie kluczy nie ma gdzie trafić, a udana rejestracja nie mówi nic o tym, czy konkretny przepływ jest właściwie wybrany i trasowany.

Czego stabilne źródło nie naprawia

Nie usuwa zduplikowanych wpisów członków utworzonych przez wcześniejszą błędną konfigurację. Nie naprawia awarii odświeżania kluczy spowodowanej niezgodnością polityk między członkiem a serwerem kluczy. Nie przetrwa awarii fizycznej ścieżki, która usunęła jedyną trasę do serwera kluczy.

Robi jedno: usuwa jedną zmienną — tożsamość nie zmienia się już, gdy zmienia się adres uplinku. Warto to mieć, i to jedna linia w projekcie, a nie cały projekt.

Kolejność pracy: nazwij ścieżkę sterującą, wybierz adres z trasą w obu kierunkach, potwierdź widok serwera kluczy, a potem osobno przetestuj ruch chroniony. Jeśli rejestracja nadal zawodzi, loopback nigdy nie był problemem.