IPsec przez prywatną sieć WAN: granice polityk SRX do sprawdzenia

Prywatna sieć WAN może przenosić zewnętrzne pakiety tunelu IPsec, więc adresy peera nie muszą być publicznymi adresami internetowymi. Zmienia się ścieżka, którą podążają te zewnętrzne pakiety, oraz uprawnienia na interfejsie, który je odbiera. Na SRX zewnętrzna ścieżka sterowania, powiązanie interfejsu tunelu i polityka przekazywanego ruchu to trzy odrębne obiekty. Rozwiązywanie problemu w jednym, gdy pozostałe dwa są błędne, to zwykła przyczyna tego, że tunel pozostaje wyłączony.

Najpierw zapisz zewnętrzną ścieżkę IKE

Zapisz cztery wartości, zanim dotkniesz polityki: adres peera, lokalny interfejs odbierający IKE, kontekst routingu docierający do peera i trasę wybierającą ten interfejs. Pakiety IKE są adresowane do samego SRX, więc wymagają uprawnienia host-inbound w strefie odbioru, a nie polityki przekazywanego ruchu. Prywatny adres WAN nie usuwa tego wymogu, ponieważ pakiet nadal kończy się na urządzeniu.

Sprawdź zainstalowany stan za pomocą show security ike sa i konfigurację za pomocą show configuration security ike. Pierwsze pokazuje, czy istnieje faza 1; drugie pokazuje, co urządzenie uważa, że powinno robić.

Powiąż interfejs tunelu z właściwą polityką

VPN oparty na routingu wiąże interfejs tunelu z obiektem VPN, a chronione prefiksy są kierowane do tego interfejsu. Zapisz, który interfejs, która trasa i która polityka zezwalają aplikacjom między odpowiednimi strefami. Strefa o nazwie trust to kontener polityk, a nazwa nie dowodzi, że wymagane pakiety sterowania lub danych są dozwolone.

Czytaj rzeczywiste powiązania, a nie stary diagram: show configuration security ipsec vpn dla ustawienia powiązania z interfejsem i show configuration security policies dla reguł odwołujących się do strefy tunelu.

Jeśli chroniona trasa wskazuje gdzie indziej, tunel może być aktywny, podczas gdy ruch nigdy do niego nie trafia. To problem routingu w kostiumie IPsec.

Trzymaj trasę peera na underlay

Trasa do zewnętrznego peera musi być rozwiązywana przez underlay, a nie rekurencyjnie przez tunel, który ustanawia. Jeśli trasa peera wskazuje interfejs tunelu, pakiety IKE gonią własny tunel i faza 1 nigdy się nie kończy. Ścieżka zwrotna dla chronionego ruchu wymaga własnej poprawnej trasy i polityki, i zwykle to jest brakująca połowa, gdy jeden kierunek działa. Przeczytaj wpis tablicy routingu dla adresu peera i potwierdź, że interfejs wychodzący to interfejs WAN.

Sprawdź to za pomocą show route 198.51.100.10, podstawiając rzeczywisty adres peera, i potwierdź, że następny przeskok nie jest interfejsem tunelu.

Sprawdź sterowanie i usługę po kolei

Pracuj w górę: stan fazy 1, stan fazy 2, a następnie rzeczywisty przepływ aplikacji. show security ipsec sa wymienia asocjacje bezpieczeństwa, a show security flow session destination-prefix 10.60.0.0/16 pokazuje, czy dla chronionej sieci tworzone są przekazywane sesje.

Zdrowa relacja sterowania i działająca ścieżka danych to dwa różne wyniki, a zaliczenie fazy 2 nic nie mówi o tym, czy polityka zezwala na aplikację. Przetestuj jeden dozwolony przepływ i jeden, który polityka powinna odrzucić, aby różnica była widoczna.

Zapisz razem trasę peera, uprawnienie host-inbound, powiązanie tunelu, trasę wewnętrzną i politykę aplikacji. Te pięć zapisów pokazuje, która warstwa odpowiada za przyszłą awarię bez polegania na etykiecie portu.