SFOS 22: redistribute kernel nie rozgłasza już tras IPsec

Po aktualizacji do SFOS 22 tunel IPsec może nadal być aktywny, a sąsiad OSPF lub BGP może wyglądać na sprawnego. Mimo to na sąsiednich routerach nagle brakuje sieci znajdujących się za tunelem policy-based IPsec.

Typową przyczyną jest redistribute kernel: Do SFOS 21.5 trasy policy-based VPN używane w tym rozwiązaniu można było pobierać z tablicy routingu kernela. Od SFOS 22.0 GA firewall przetwarza te trasy wewnętrznie w backendzie VPN. Dlatego redistribute kernel już ich nie znajduje.

⚠️ Nie należy tworzyć statycznej trasy dummy, null ani blackhole tylko po to, aby prefiks ponownie pojawił się w OSPF lub BGP. Zależnie od Route Precedence taka trasa może sama przejąć ścieżkę danych i skierować ruch produkcyjny poza tunel albo go odrzucić.

Krótka odpowiedź: co teraz zrobić

Jeśli po aktualizacji brakuje wcześniej rozgłaszanej sieci VPN, najpierw sprawdza się, czy spełnione są wszystkie poniższe warunki:

1. Firewall został zaktualizowany z SFOS 21.5 lub starszego do SFOS 22.
2. Dany tunel jest typu policy-based.
3. OSPF lub BGP przejmował dotąd sieci VPN przez redistribute kernel.
4. Sąsiad nadal ma stan Full albo Established, ale po stronie odbierającej brakuje oczekiwanego prefiksu.

Jeśli tak jest, nowy wpis ipsec_route nie rozwiąże problemu: w SFOS 22 również nie tworzy on zwykłej trasy kernela. Trwałym i przejrzystym rozwiązaniem jest route-based Any-to-Any IPsec z zaadresowanymi interfejsami XFRM oraz jawną konfiguracją OSPF lub BGP.

Kontrola przed aktualizacją do SFOS 22 pomaga w przygotowaniu. Właściwą konfigurację tunelu opisano w artykule Konfiguracja Site-to-Site IPsec VPN.

Dlaczego po aktualizacji brakuje trasy

Trasa kernela jest wpisem w zwykłej tablicy routingu systemu operacyjnego. Usługi routingu mogą przejąć takie wpisy jako źródło i na przykład przekazać je sąsiadom za pomocą redistribute kernel.

SFOS 22 inaczej obsługuje policy-based IPsec: ścieżkę pakietu określa wewnętrzne wyszukiwanie backendu przy użyciu znaczników, stref i flag. Tunel może zatem prawidłowo przekazywać ruch, mimo że powiązana sieć VPN nie jest widoczna jako zwykła trasa kernela.

Wyjaśnia to pozornie sprzeczny obraz błędu:

• Tunel IPsec jest aktywny.
• OSPF ma stan Full lub BGP Established.
• Bezpośredni ruch przez tunel może nadal działać.
• Zdalny prefiks VPN nie jest jednak już pobierany z tablicy routingu kernela do OSPF lub BGP.

Zmiana nie dotyczy ogólnie OSPF ani BGP. Dotyczy wyłącznie projektu, który zakładał, że trasy policy-based IPsec są trasami kernela.

Rozpoznanie zależności przed aktualizacją

Przed aktualizacją w istniejącym środowisku nie wystarczy sprawdzić zielonego statusu tunelu. Kluczowe jest ustalenie, skąd OSPF lub BGP pobiera rozgłaszany prefiks.

W przykładzie używana jest zdalna sieć VPN 10.60.0.0/16. Jest to wartość przykładowa, którą należy zastąpić rzeczywiście rozgłaszaną siecią.

Zapis stanu firewalla i VPN

Najpierw w 4. Device Console dokumentuje się Route Precedence i ręczne trasy IPsec:

system route_precedence show
system ipsec_route show

Wyniki odpowiadają na dwa różne pytania: Route Precedence pokazuje globalną kolejność klas routingu. system ipsec_route show pokazuje ręczne przypisania do tuneli policy-based. Żadne z tych poleceń samo w sobie nie dowodzi, że OSPF lub BGP rzeczywiście rozgłasza prefiks.

W SFOS 21.5 można dodatkowo zapisać w Advanced Shell, czy przykładowa sieć znajduje się w tablicy routingu używanej dla policy-based IPsec:

ip route show table 220 | grep '10.60.0.0/16'

Polecenie jest tylko do odczytu; wyszukiwany prefiks należy dostosować do rzeczywistej sieci. W SFOS 22 brak wyniku dla policy-based IPsec jest spodziewany i nie dowodzi awarii samego tunelu.

Oddzielne udokumentowanie OSPF lub BGP

W odpowiednim CLI routingu zapisuje się bieżącą konfigurację. Dla OSPF pomocne są również następujące polecenia tylko do odczytu:

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

Dla BGP zapisuje się konfigurację razem ze znanymi prefiksami BGP:

show running-config
show ip bgp

Na routerze odbierającym również należy zapisać, czy 10.60.0.0/16 jest uczone i jaki Next Hop jest używany. Tylko w ten sposób po aktualizacji można ustalić, czy problem dotyczy tunelu, sąsiedztwa routingu czy rozgłaszania prefiksu.

Pełne procedury kontrolne opisano w artykułach Konfiguracja i weryfikacja OSPF oraz Konfiguracja i diagnostyka BGP.

Wybór bezpiecznego projektu docelowego

Routing dynamiczny przez interfejs XFRM

Jeśli zdalne sieci mają być uczone dynamicznie lub dalej redystrybuowane, przejrzystym projektem docelowym jest route-based Any-to-Any IPsec:

1. Oba końce tunelu używają Route-based (Tunnel interface) z podsieciami Any-to-Any.
2. Automatycznie utworzone interfejsy XFRM otrzymują unikalne adresy IP z osobnej sieci tranzytowej.
3. OSPF lub BGP zestawia sąsiedztwo przez te adresy tranzytowe.
4. Przeznaczone do tego sieci są jawnie rozgłaszane w protokole routingu albo redystrybuowane przez ściśle filtrowaną, rzeczywiście istniejącą trasę.
5. Reguły firewalla zezwalają na ruch użytkowy między strefami LAN i VPN.

Dzięki temu trasa nie jest już produktem ubocznym tunelu policy-based. XFRM, protokół routingu i rozgłaszane prefiksy można oddzielnie sprawdzać i zmieniać.

Migrację przygotowuje się w oknie serwisowym. Połączenia policy-based i route-based z tymi samymi prefiksami nie mogą działać jednocześnie bez kontroli, ponieważ nakładające się selektory i trasy mogą zafałszować test.

Tymczasowe pozostawienie policy-based IPsec

Nie każde istniejące połączenie trzeba natychmiast migrować. Jeśli tunel pozostaje policy-based, rozgłaszanie prefiksów wymaga jednak świadomie zaplanowanego projektu właściwego dla danej topologii. Publicznie udokumentowane procedury SFOS 22 nie zawierają uniwersalnego polecenia zastępczego, które ponownie udostępniłoby backendowe trasy VPN jako trasy kernela dla OSPF lub BGP.

redistribute static ma sens tylko wtedy, gdy sama trasa statyczna jest rzeczywistą oczekiwaną ścieżką danych, a ACL lub Route Map ogranicza ją do zamierzonych prefiksów. Dodatkowa trasa służąca wyłącznie jako źródło redystrybucji nie jest bezpiecznym rozwiązaniem standardowym.

Zmiana system route_precedence również nie przywróci brakującej trasy kernela. Kolejność obowiązuje globalnie i może zmienić inne ścieżki statyczne, SD-WAN i VPN. Jeśli trzeba ją dostosować z powodu konkretnego konfliktu routingu, artykuł Bezpieczna zmiana Route Precedence wyjaśnia kontrolę i drogę powrotną.

Odbiór migracji i działania

Udany test obejmuje kilka oddzielnych poziomów:

1. Interfejs XFRM jest aktywny i ma zaplanowany tranzytowy adres IP.
2. OSPF osiąga stan Full lub BGP Established.
3. Rozgłaszane są tylko zamierzone prefiksy, a druga strona je odbiera.
4. Route Lookup i Routing Information pokazują zaplanowaną ścieżkę dla konkretnego celu.
5. Log Viewer i Packet Capture pokazują oczekiwaną regułę firewalla oraz interfejs wejściowy i wyjściowy.
6. Rzeczywista usługa działa w obu kierunkach i używa prawidłowej trasy zwrotnej.
7. Przy redundantnych łączach WAN lub HA oddzielnie testuje się kontrolowany failover.

Route Lookup sprawdza lokalną ścieżkę przekazywania, ale nie rozgłaszanie prefiksu do sąsiada OSPF lub BGP. Dlatego łącznie decydujące są Route Lookup, odebrany prefiks, sąsiad routingu, przepływ pakietów oraz rzeczywisty test aplikacji.

Systematyczne zawężanie błędu

Sąsiad jest zestawiony, ale brakuje prefiksu VPN

Najpierw w show running-config należy sprawdzić, czy sieć trafiała dotąd do OSPF lub BGP wyłącznie przez redistribute kernel. Następnie trzeba ustalić typ tunelu i build SFOS. Jeśli chodzi o policy-based IPsec w SFOS 22, brak wpisu kernela jest najbardziej prawdopodobnym wyjaśnieniem; sąsiad nie musi przy tym przestać działać.

Prefiks jest rozgłaszany, ale ruch nie działa

Wtedy brak redystrybucji kernela nie jest już bezpośrednią przyczyną. Należy oddzielnie sprawdzić Route Lookup, reguły firewalla, NAT, drogę powrotną, adres XFRM i Traffic Selector. Rozgłaszany prefiks nie dowodzi, że ścieżka w obu kierunkach jest prawidłowa.

ipsec_route istnieje, ale OSPF lub BGP nie przejmuje sieci

W SFOS 22 jest to oczekiwane. system ipsec_route show pokazuje skonfigurowane ręczne przypisanie tunelu, ale nie potwierdza ani zwykłej trasy kernela, ani działającej ścieżki danych. Dodatkowa ipsec_route dla tej samej sieci nie przywróci więc redistribute kernel. Dokładne wyjaśnienie oraz bezpieczna składnia Add/Delete znajdują się w artykule Tworzenie trasy IPsec na Sophos Firewall.

Po dodaniu statycznej trasy zastępczej ruch przestaje działać

Nowo utworzona trasa może zastąpić rzeczywistą ścieżkę VPN. Należy wycofać zmianę zgodnie z wcześniej udokumentowanym poleceniem i planem prac, sprawdzić Route Precedence oraz powtórzyć ostatni działający test. Nie należy jednocześnie zmieniać kolejnych ustawień routingu, NAT i VPN.

Bezpieczne wycofanie

Przed migracją zapisuje się połączenie policy-based, konfigurację routingu, Route Precedence, reguły i odebrane prefiksy. Podczas rollbacku wycofuje się tylko wcześniej zmienioną ścieżkę:

• w kontrolowany sposób usunąć nowe ogłoszenia i filtry OSPF/BGP,
• usunąć trasy XFRM tylko wtedy, gdy stara ścieżka danych znów jest aktywna i sprawdzona,
• dokładnie przywrócić pierwotne Route Precedence, jeśli zostało zmienione,
• całkowicie usunąć sztuczne trasy pomocnicze,
• ponownie sprawdzić tunel, stan sąsiada, prefiksy i rzeczywisty ruch.

Rollback kończy się dopiero wtedy, gdy dostęp administracyjny i połączenia produkcyjne ponownie działają przez udokumentowaną pierwotną ścieżkę.

FAQ