SFOS 22: trasy policy-based IPsec w OSPF i BGP

Po aktualizacji do SFOS 22 tunel policy-based IPsec może nadal działać, mimo że brakuje prefiksu VPN wcześniej rozgłaszanego przez OSPF lub BGP. Sąsiedztwo routingu może również pozostać w stanie Full lub Established.

Sophos dokumentuje, że SFOS 22 nie tworzy już wcześniejszych tras VPN dla policy-based IPsec i nie używa już ipsec0 na ścieżce wysyłania. Jeśli jednocześnie znika prefiks OSPF lub BGP, związek z redystrybucją należy traktować jako zaobserwowany wniosek operacyjny: KBA nie opisuje redistribute kernel, OSPF ani BGP. Brak prefiksu nie oznacza więc automatycznie awarii tunelu.

⚠️ Nie twórz trasy dummy, null, blackhole ani innej trasy pomocniczej wyłącznie w celu rozgłaszania prefiksu. Może ona zmienić ścieżkę danych. Przed zmianą środowiska produkcyjnego uzgodnij konkretny projekt z Sophos Support lub podczas zaplanowanego okna projektowego i serwisowego.

Szybka diagnoza

Zbadaj ten wzorzec po aktualizacji do SFOS 22, jeśli spełnione są wszystkie warunki:

1. Problem rozpoczął się wraz z aktualizacją do SFOS 22.
2. Tunel jest typu policy-based.
3. OSPF lub BGP wcześniej używał redistribute kernel dla prefiksu VPN.
4. Tunel i sąsiad są aktywne, ale router odbierający nie ma prefiksu.

W przypadku tunelu route-based lub niedziałającego sąsiedztwa należy zamiast tego zbadać odpowiednią awarię tunelu albo routingu.

Dlaczego zwykłe widoki routingu nie wystarczają

KBA stwierdza, że SFOS 22 nie tworzy już wcześniejszych tras policy-based VPN. Oddzielnie opisuje trasy ipsec_route jako należące w SFOS 22 do klasy pierwszeństwa vpn i niewidoczne w tabeli routingu. Nie podaje, jak redystrybucja OSPF lub BGP traktuje którykolwiek z tych przypadków.

Oceń oddzielnie trzy stany:

• VPN: Czy połączenie IPsec jest aktywne i czy przepływa ruch?
• Protokół routingu: Czy sąsiad OSPF lub BGP jest aktywny?
• Rozgłaszanie: Czy zdalny router uczy się dokładnie oczekiwanego prefiksu?

Zielony status VPN nie dowodzi rozgłaszania trasy. Z drugiej strony brak trasy w zwykłym widoku routingu w SFOS 22 nie dowodzi awarii tunelu policy-based.

Rozpoznawanie przepływu VPN w danych wyjściowych conntrack

SFOS 22 nie używa już ipsec0 w ścieżce wysyłania i nie tworzy wcześniejszych tras VPN. Dla konkretnego testowanego połączenia należy zamiast tego użyć wartości conntrack: ruch do VPN ma mark=0x0, outzone=5 i flagę 74; ruch z VPN ma mark=0x0, inzone=5 i flagę 75. Strefa 5 to strefa VPN, a flaga może występować z innymi wartościami w flagvalues.

Wartości te określają kierunek obserwowanego połączenia VPN, lecz nie dowodzą rozgłaszania OSPF ani BGP. W SFOS 22 oczekiwane jest również, że Packet Capture nie pokazuje ipsec0 w ścieżce wysyłania, a Route Lookup w Diagnostics > Tools może pokazać interfejs WAN. Skoreluj ściśle ograniczony przepływ testowy w conntrack i Packet Capture zamiast traktować pojedynczy widok jako dowód usterki.

Bezpieczne kontrole tylko do odczytu

Zapis danych firewalla i VPN

1. Zapisz wersję i build SFOS.
2. W Site-to-site VPN > IPsec zapisz stan połączenia, typ tunelu oraz skonfigurowane podsieci lokalne i zdalne.
3. W Routing > Routing information wykonaj Route Lookup dla konkretnego celu, uwzględniając ograniczenie wyświetlania tras policy-based VPN i ipsec_route.
4. W 4. Device Console wyświetl udokumentowaną konfigurację:

system route_precedence show
system ipsec_route show

Te polecenia nie wprowadzają zmian. Route Precedence pokazuje globalną kolejność klas tras; system ipsec_route show wyświetla ręczne trasy IPsec. Żadne z tych poleceń samo w sobie nie dowodzi, że OSPF lub BGP rozgłasza prefiks.

Przy dostępie tylko do odczytu do Advanced Shell zapisz także widoki tras i połączeń używane w KBA:

route -n
ip route show
conntrack -L

Ogranicz analizę conntrack do punktów końcowych i przedziału czasowego testu. Dane te mogą potwierdzić brak starej trasy lub ipsec0 i zidentyfikować testowany przepływ VPN; nie dowodzą redystrybucji ani rozgłoszenia.

Kontrola priorytetu ipsec_route przed zmianą

W SFOS 21.5 trasa dodana przez ipsec_route należała do klasy static; w SFOS 22 należy do klasy vpn. Przy kolejności static sdwan_policyroute vpn trasa polityki SD-WAN zgodna z selektorami VPN może więc przejąć ruch po aktualizacji. Jeśli zweryfikowany projekt wymaga pierwszeństwa VPN, Sophos dokumentuje static vpn sdwan_policyroute jako kolejność docelową, a system route_precedence set static vpn sdwan_policyroute jako polecenie wprowadzające zmianę.

Nie wykonuj tego polecenia wyłącznie na podstawie tej diagnozy: Route Precedence działa globalnie i może wpłynąć na inny ruch. Najpierw zapisz system route_precedence show, zgodne polityki SD-WAN, ścieżki w obu kierunkach oraz punkt wycofania. Następnie użyj instrukcji Bezpieczna zmiana Route Precedence, która obejmuje kontrole wstępne, kontrolowaną zmianę, walidację i wycofanie.

Oddzielna kontrola OSPF lub BGP

Użyj udokumentowanych przez Sophos poleceń wyświetlających w odpowiednim CLI routingu:

show running-config
show ip ospf neighbor
show ip ospf route
show ip bgp

Wykonuj tylko polecenia dotyczące używanego protokołu. Zapisz również prefiks i Next Hop na routerze odbierającym. Pełne kontrole opisano w artykułach Konfiguracja i weryfikacja OSPF oraz Konfiguracja i diagnostyka BGP.

Podjęcie decyzji projektowej

Routing dynamiczny jest wymagany

Dla routingu dynamicznego Sophos dokumentuje route-based Any-to-Any IPsec. W tym projekcie powstają interfejsy XFRM, którym można przypisać adresy i używać ich dla OSPF lub BGP. Sąsiedztwo i rozgłaszane prefiksy stają się wtedy jawnymi elementami projektu, a nie skutkami ubocznymi trasy policy-based VPN.

Jest to kierunek projektu, a nie uniwersalna procedura migracji. Adresowanie, filtry routingu, reguły firewalla, NAT, ścieżka powrotna, redundancja i peer zależą od topologii. Przed zmianą środowiska produkcyjnego zaplanuj ją z Sophos Support lub podczas okna projektowego i serwisowego. Podstawy tunelu opisano w artykule Konfiguracja Site-to-Site IPsec VPN.

Policy-based IPsec musi pozostać

KBA nie dokumentuje redystrybucji OSPF ani BGP ani polecenia, które udostępniałoby wcześniejszą trasę VPN któremukolwiek z tych protokołów. Kolejna ipsec_route, zmiana Route Precedence ani sztuczna trasa statyczna nie zastępuje zweryfikowanego projektu routingu.

Jeśli policy-based IPsec musi pozostać, zaprojektuj z Sophos Support właściwą dla topologii ścieżkę rozgłaszania. Kontrola przed aktualizacją do SFOS 22 oraz Tworzenie trasy IPsec na Sophos Firewall zapewniają przydatny kontekst.

Przed zmianą produkcyjną

Na sesję wsparcia lub projektową przygotuj co najmniej:

• wersję i build SFOS, typ tunelu oraz stan HA;
• zanonimizowane prefiksy lokalne i zdalne;
• wcześniejszą konfigurację OSPF lub BGP oraz stan sąsiada;
• oczekiwane i odebrane prefiksy wraz z ich Next Hop;
• odpowiednie wyniki Route Lookup, Log Viewer i Packet Capture;
• wymagania dotyczące ścieżki powrotnej, NAT, failoveru i okna serwisowego.

Nie zmieniaj jednocześnie VPN, routingu, NAT i reguł firewalla bez zdefiniowanych punktów testowania i przywracania. Po zatwierdzeniu projektu sprawdź oddzielnie każdą planowaną warstwę: tunel/XFRM, sąsiada, rozgłaszane prefiksy, ścieżki w obu kierunkach i rzeczywistą usługę.

Rozróżnianie objawów

Sąsiad aktywny, brak prefiksu

Porównaj typ tunelu, build SFOS i show running-config. Brak wcześniejszej trasy VPN, aktywne sąsiedztwo i brak odebranego prefiksu to odrębne obserwacje. Sprawdź w konfiguracji routingu i na routerze odbierającym, czy redystrybucja zależała od tej trasy.

Prefiks obecny, ruch zakłócony

Brak redystrybucji nie jest wtedy bezpośrednią przyczyną. Zbadaj oddzielnie Route Lookup, reguły, NAT i ścieżkę powrotną.

ipsec_route obecna, brak prefiksu

system ipsec_route show potwierdza wyłącznie ręczne przypisanie. Nie potwierdza ani zwykłej trasy kernela, ani rozgłoszenia OSPF lub BGP.

Brak uniwersalnej sekwencji wycofania

Bez konkretnej topologii nie istnieje bezpieczna sekwencja współistnienia, przełączenia, wycofania ani failoveru. Kroki te należą do planu zmiany uzgodnionego z Sophos Support; ten artykuł celowo nie podaje sekwencji poleceń.

FAQ