Dwa łącza WAN na lokalizację wyglądają jak redundancja, dopóki nie spróbujesz udowodnić, której pary adresów użył dany przepływ. Na SRX jedna brama IKE przenosi jeden interfejs zewnętrzny i jeden adres lokalny; lista zdalnych kandydatów nie tworzy drugiego źródła lokalnego. Dlatego ten przewodnik zaczyna się od macierzy par, a nie od konfiguracji, ponieważ Junos bez oporu zatwierdzi projekt, który pokrywa tylko połowę zamierzonych kombinacji. Trafiłem na to na dwóch SRX345s: tunel zapasowy wstał czysto i mimo to ściągnął sesję przy powrocie.

Przejdź kroki po kolei: wypisz pary, które musisz obsłużyć, zbuduj jedną bramę na źródło lokalne, potwierdź, które skojarzenie przeniosło ruch, i dopiero potem zdecyduj, co może zmieniać każdy rodzaj awarii.

Zmapuj pary, zanim dotkniesz CLI

Jeśli witryna A może wysyłać z A1 lub A2, a witryna B może odbierać na B1 lub B2, masz cztery zewnętrzne pary adresów. Większość projektów potrzebuje dwóch z nich stale, a pozostałe dwa traktuje jako opcjonalne. Zapisz macierz i oznacz każdy wiersz, bo każdy obiecany wiersz kosztuje później bramę, interfejs tunelu i decyzję routingu.

Local sourceRemote candidateRequired?
A1, ISP1 addressB1steady state
A1, ISP1 addressB2decide explicitly
A2, ISP2 addressB1decide explicitly
A2, ISP2 addressB2backup path

Każda wymagana para potrzebuje trzech rzeczy naraz: osiągalnego underlayu między dokładnie tymi adresami, wzajemnej akceptacji tożsamości peera i adresu źródłowego po obu stronach oraz chronionej ścieżki powrotnej. Para, która działa tylko w jednym kierunku, nadal pokazuje tunel, a awaria ujawnia się później jako jednokierunkowy ruch aplikacji.

Jedna brama na źródło lokalne, a nie na zdalną witrynę

Lista adresów zdalnych należy do bramy, podobnie jak źródło lokalne. dokumentacja bram IKE trzyma adresy zdalne, interfejs zewnętrzny, adres lokalny i wykrywanie martwego peera jako osobne ustawienia, i właśnie o to chodzi: dwa źródła lokalne oznaczają dwie bramy na dwóch jednostkach st0. Współdzielenie polityki IKE między nimi jest w porządku; trzymanie jednej bramy i liczenie, że sama zmieni źródło, już nie.

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

Następnie podłącz tunele i daj zdalnemu prefiksowi dwa next hopy, po jednym na tunel:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

Czy jedna brama może trzymać dwie instrukcje typu address, zależy od wersji i od tego, który proces IKE działa na urządzeniu. Starsze Junos oparte na kmd przyjmują jeden adres zdalny na bramę; nowsze kompilacje obsługują wielu kandydatów, ale dokładają własne ograniczenia, a klastry wysokiej dostępności to częste miejsce, w którym to wsparcie się zawęża. Sprawdź informacje o wydaniu dla swojej dokładnej kompilacji, zanim skopiujesz to ze starszego chassis.

Potwierdź, które skojarzenie przeniosło pakiet

Dwa SA i dwa tunele nie mówią, który z nich przekazał sesję. Zapytaj urządzenie wprost i porównaj pola z parą, którą zamierzałeś:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

Wynik szczegółowy podaje bramę lokalną i zdalną dla każdego skojarzenia, co jest najszybszym sposobem zauważenia tunelu wynegocjowanego ze źródła, którego się nie spodziewałeś. Potem obserwuj liczniki pakietów na jednostkę na st0.1 i st0.2, przepuszczając ruch; tunel, który nic nie przenosi, zachowuje swoje SA i wygląda zdrowo w widoku podsumowania.

Daj każdemu rodzajowi awarii własny detektor

Żywotność peera, utrata lokalnego uplinku, wycofanie chronionej trasy i awaria aplikacji to cztery różne zdarzenia. DPD odpowiada tylko za pierwsze, więc skonfiguruj go z interwałem i progiem, których możesz bronić, zamiast zostawiać domyślne i zakładać, że pokrywa resztę:

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

Monitorowanie tunelu, które sonduje cel wewnątrz zdalnej podsieci, pokrywa przypadek, którego DPD nie widzi: IKE żyje, brama odpowiada, a chroniony prefiks i tak jest nieosiągalny. Wybierz, które z dwóch ma ciągnąć preferencję, bo jeśli oba zadziałają naraz, powstanie burza zmian zamiast czystego przełączenia.

Nie zapomnij o drugim końcu. Preferowana trasa, która zostaje na zdalnej witrynie, nadal wskazuje tunel, który już porzuciłeś, i żaden lokalny timer tego nie naprawi. Opublikuj tę samą logikę preferencji na obu peerach i zapisz, czy odzyskane łącze może automatycznie odzyskać ruch, czy trzeba je przełączyć ręcznie.

Przeadresuj jedno łącze bez dotykania drugiego

Gdy ISP daje ci nowy blok, zmieniaj jedną relację naraz. Zaktualizuj address lub local-address na obu peerach dla tej pary, zrób commit i wyczyść tylko dotknięte skojarzenia po indeksie, zamiast czyścić wszystkie SA na urządzeniu. Globalne czyszczenie zabiera też zdrowy tunel i zamienia okno serwisowe w awarię.

Zachowaj jeden nieudany przepływ i szczegóły jego sesji jako dowód, zanim cokolwiek posprzątasz, a potem powtórz powyższe kontrole na nowej parze adresów. Przywrócenie łącza to decyzja routingu, więc potraktuj powrót jako osobny sprawdzony krok, zamiast zakładać, że stara preferencja wróci sama.

Zamknij zmianę krótką listą kontrolną

Projekt tunelu dwu-WAN jest gotowy, gdy potrafisz nazwać parę stojącą za każdą sesją, a nie gdy oba SA są podniesione. Przejdź poniższą listę na urządzeniu, które naprawdę zmieniłeś:

  • Każda obiecana para ma bramę, jednostkę st0 i wpis trasy.
  • Każdy tunel był widziany, jak przenosi pakiety, a nie tylko trzyma SA.
  • Oba końce zgadzają się co do wykrywania i co do tego, która strona przywraca preferencję.
  • Ścieżka powrotna każdej pary jest zapisana obok jej ścieżki w przód.

Jeśli któryś wiersz zawiedzie, napraw tę parę, zanim dodasz następną; układanie dwóch na wpół działających tuneli sprawia, że liczniki nic nie znaczą, a zachowanie failoveru jest nieprzewidywalne.

Powiązane artykuły