Konfiguracja i weryfikacja RIP na Sophos Firewall

RIP automatycznie rozgłasza trasy IPv4 między routerami. Na Sophos Firewall protokół ten sprawdza się przede wszystkim w małych lub istniejących domenach routingu, w których kilka routerów ma wymieniać informacje o sieciach bez złożonego wyboru ścieżki.

Bezpieczna skrócona procedura wygląda następująco:

1. Udokumentować sieć tranzytową, lokalne sieci LAN, peera, oczekiwane prefiksy i trasę powrotną.
2. Przygotować kopię zapasową konfiguracji i niezależny dostęp administracyjny.
3. Sprawdzić bezpośrednią osiągalność IP między adresami tranzytowymi.
4. W Administration > Device access zezwolić na Dynamic Routing tylko dla strefy peera lub przez ściśle ograniczony wyjątek.
5. W Routing > RIP wybrać RIPv2 i początkowo pozostawić globalne timery bez zmian.
6. Dodać sieć tranzytową i lokalne sieci LAN w RIP Networks.
7. Ustawić interfejsy LAN w tryb Passive mode za pomocą Override interface configuration.
8. Uzgodnić z peerem wersję i uwierzytelnianie na interfejsie tranzytowym.
9. W Routing > Information > RIP sprawdzić stan i poznane trasy.
10. Przetestować Route Lookup, Firewall Rule ID i rzeczywistą usługę dwukierunkową.

⚠️ Default information originate oraz redystrybucja Connected, Static, OSPF lub BGP pozostają wyłączone, dopóki nie są znane wszystkie rozgłaszane prefiksy i ich trasy powrotne. Szeroka redystrybucja może nieoczekiwanie rozgłosić trasy zarządzające, tranzytowe, blackhole lub inne trasy wewnętrzne w całej domenie RIP.

Ta procedura dotyczy RIPv2 dla IPv4 w Gateway Mode. RIPv1 opisano jedynie jako starszy przypadek interoperacyjności. Sophos Firewall nie obsługuje RIP w Transparent Mode.

Kiedy RIP jest odpowiedni, a kiedy nie

RIP jest protokołem wektora odległości. Ocenia ścieżkę na podstawie liczby przeskoków przez routery. Preferowana jest trasa z niższą metryką. Osiągalnych jest maksymalnie 15 przeskoków; metryka 16 oznacza brak osiągalności.

Ten prosty model jest zaletą, gdy:

• uczestniczy tylko kilka routerów,
• topologia jest mała i w dużej mierze stabilna,
• istniejący peer obsługuje tylko RIP,
• automatyczne utrzymanie tras jest ważniejsze niż szybka konwergencja i złożone reguły routingu.

Dla jednej stałej ścieżki trasa statyczna jest często prostsza. Przy wielu redundantnych ścieżkach, szybkiej konwergencji lub większych sieciach wewnętrznych OSPF jest zazwyczaj lepszym protokołem. BGP należy do projektów z systemami autonomicznymi, operatorami lub świadomie ustaloną polityką routingu.

RIP nie zastępuje reguły zapory i nie monitoruje jakości aplikacji. Trasa SD-WAN jest właściwą warstwą do wyboru na podstawie źródła, usługi, aplikacji, opóźnienia, jittera lub utraty pakietów.

Rozróżnienie RIPv1 i RIPv2

W nowych konfiguracjach należy używać RIPv2. Przenosi on maski podsieci i obsługuje uwierzytelnianie. RIPv1 jest protokołem classful, nie przenosi masek podsieci i nie obsługuje uwierzytelniania na Sophos Firewall.

SFOS udostępnia między innymi następujące opcje globalne:

• Send V2 and receive both: wysyłanie RIPv2 oraz odbieranie RIPv1 i RIPv2
• V1: wysyłanie i odbieranie RIPv1
• V2: wysyłanie i odbieranie RIPv2

W przykładzie oba peery korzystają z RIPv2. Send V2 and receive both może ułatwić kontrolowany okres przejściowy, ale rozszerza zakres akceptowanych danych. Gdy wszystkie peery obsługują RIPv2, zarówno wysyłanie, jak i odbieranie należy ograniczyć do V2.

Jak działają RIP Networks i Passive Mode

RIP Network nie jest zdalną siecią docelową. Wpis aktywuje RIP na lokalnych interfejsach, których adres IP pasuje do podanej sieci. Bezpośrednio podłączona sieć zostaje w ten sposób włączona do procesu RIP i może być rozgłaszana.

W przykładzie na Firewall A wprowadza się zarówno sieć tranzytową 198.51.100.0/30, jak i lokalną sieć LAN 10.10.10.0/24:

• Sieć tranzytowa aktywuje RIP na interfejsie skierowanym do peera.
• Sieć LAN jest rozgłaszana jako osiągalna sieć lokalna.
• Passive mode na interfejsie LAN zapobiega wysyłaniu tam aktualizacji RIP przez zaporę.

Passive Mode nie usuwa sieci LAN z procesu routingu. Zapobiega jedynie wysyłaniu ogłoszeń RIP przez ten interfejs. Dodatkowo Dynamic Routing pozostaje wyłączony w strefie klientów, aby klienci nie mogli wysyłać aktualizacji routingu do zapory.

Globalna Default metric jest początkową metryką dla redystrybuowanych tras. Wartość domyślna to 1. Administrative distance rozstrzyga między konkurującymi źródłami routingu; Sophos domyślnie używa dla RIP wartości 120. Wartości te nie są zmieniane bez udokumentowanego powodu.

Domyślne timery to:

• Update: 30 sekund
• Timeout: 180 sekund
• Garbage: 120 sekund

Timery należy uzgodnić na wszystkich peerach. Agresywne skrócenie wartości może powodować niepotrzebne usuwanie i ponowne poznawanie tras przy utracie pakietów lub dużym obciążeniu.

Planowanie przykładowej topologii

Spójny przykład łączy dwie sieci LAN:

• Firewall A: adres tranzytowy 198.51.100.1/30, lokalna sieć LAN 10.10.10.0/24
• Router lub Firewall B: adres tranzytowy 198.51.100.2/30, lokalna sieć LAN 10.20.20.0/24
• Sieć tranzytowa: 198.51.100.0/30
• Klient testowy A: 10.10.10.10
• Serwer testowy B: 10.20.20.10

198.51.100.0/24 jest zarezerwowana do celów dokumentacyjnych. W rzeczywistym środowisku należy wspólnie zastąpić adresy tranzytowe, interfejsy, strefy i prefiksy LAN. Oba adresy tranzytowe muszą być bezpośrednio osiągalne.

Firewall A ma poznać 10.20.20.0/24 przez 198.51.100.2. Peer ma poznać 10.10.10.0/24 przez 198.51.100.1. Dopiero ta ścieżka w obu kierunkach umożliwia routing ruchu bez source NAT.

Przed zmianą należy udokumentować interfejs, strefę, istniejące trasy, Route Precedence, oczekiwaną metrykę i osiągalny host testowy. Aktualna kopia zapasowa konfiguracji oraz ścieżka zarządzania niezależna od nowego routingu ułatwiają odzyskanie dostępu.

Ograniczone zezwolenie na Dynamic Routing

W Administration > Device access opcja Dynamic Routing jest domyślnie wyłączona dla wszystkich stref. W przykładzie zostaje dozwolona tylko w strefie interfejsu tranzytowego.

Macierz Device Access dotyczy całej strefy. Jeżeli w tej samej strefie znajdują się inne niezaufane interfejsy, lepszym rozwiązaniem jest ściśle ograniczony Local Service ACL Exception dla sieci tranzytowej i przewidzianego peera. Device Access i Local Service ACL wyjaśnia ten podział.

To zezwolenie dotyczy pakietów RIP kierowanych do zapory. Strumień danych między 10.10.10.0/24 i 10.20.20.0/24 nadal wymaga zwykłych reguł zapory. Dynamic Routing nie jest włączany w strefie LAN tylko dlatego, że LAN jest rozgłaszany jako RIP Network.

Konfiguracja RIPv2 w WebAdmin

Konfigurację należy odtworzyć na obu peerach. Różnią się tylko adres tranzytowy i lokalna sieć LAN.

1. Ustawienie wartości globalnych

Otworzyć ustawienia globalne w Routing > RIP:

1. Ustawić RIP version na V2.
2. Pozostawić Default metric z istniejącą wartością domyślną 1.
3. Pozostawić Administrative distance z istniejącą wartością domyślną 120.
4. Początkowo pozostawić Update, Timeout i Garbage na 30, 180 i 120 sekund.
5. Pozostawić Default information originate wyłączone.
6. Nie włączać redystrybucji.
7. Zapisać zmiany.

Default information originate ogłasza trasę domyślną w domenie RIP. Jest to właściwe tylko wtedy, gdy ta zapora ma świadomie pełnić funkcję wyjścia dla wszystkich nieznanych miejsc docelowych oraz zaplanowano ścieżkę powrotną i zachowanie w razie awarii.

2. Dodanie RIP Networks

W Routing > RIP > RIP Networks > Add wprowadzić na Firewall A następujące sieci lokalne:

1. 198.51.100.0 z maską podsieci 255.255.255.252
2. 10.10.10.0 z maską podsieci 255.255.255.0

Na peerze B wprowadzić tę samą sieć tranzytową oraz 10.20.20.0/24.

Przed zapisaniem sprawdzić, do którego lokalnego interfejsu pasuje każdy Network. Zbyt szeroki Network może aktywować RIP na dodatkowych interfejsach i włączyć do procesu więcej bezpośrednio podłączonych sieci.

3. Ustawienie Interface Overrides

W Routing > RIP > Override interface configuration wybrać uczestniczące interfejsy.

Dla interfejsu tranzytowego:

• Send version: V2
• Receive version: V2
• Passive mode: wyłączony
• Split horizon: odpowiedni do projektu peer i hub
• Authentication: identyczne po obu stronach, jeżeli jest używane

Dla interfejsu LAN:

• Send version: V2
• Receive version: V2
• Passive mode: włączony

RIPv2 obsługuje uwierzytelnianie tekstem jawnym i MD5. Tekst jawny nie chroni hasła. MD5 uwierzytelnia aktualizacje routingu, ale nie szyfruje ani prefiksów, ani metryk. Segmenty tranzytowe pozostają więc ograniczone do przewidzianych routerów. W nowych, silniej chronionych lub większych projektach zwykle lepiej sprawdza się nowocześniejszy protokół routingu przez kontrolowany transport.

Split horizon zwykle zapobiega ponownemu ogłaszaniu przez ten sam interfejs trasy poznanej na tym interfejsie. Poisoned reverse może jawnie ogłosić ją tam z metryką 16 jako nieosiągalną. Opcje te należy zmieniać tylko wtedy, gdy wymaga tego topologia hub, spoke lub multi-access, i testować wspólnie z peerem.

4. Odzwierciedlenie konfiguracji na peerze

Na Router lub Firewall B należy ustawić tę samą wersję, timery i uwierzytelnianie. Jako Networks wykorzystuje się 198.51.100.0/30 i 10.20.20.0/24, a interfejs do sieci LAN odbiorcy ustawia się jako pasywny.

Konfiguracja jednostronna nie wystarcza. Bez ogłoszenia sieci powrotnej Firewall A może poznać zdalną sieć LAN, lecz odpowiedzi nie znajdą drogi powrotnej.

Reguły zapory, NAT i Route Precedence

Do testu obie zapory potrzebują ściśle ograniczonych, rejestrowanych reguł dla usług rzeczywiście wymaganych między 10.10.10.0/24 i 10.20.20.0/24. Prawidłowe tworzenie reguł zapory wyjaśnia mechanizm reguł.

W normalnie routowanej sieci oddziałów source NAT pozostaje wyłączony. Obie strony powinny widzieć rzeczywisty adres źródłowy i znać trasę powrotną przez RIP. SNAT może ukrywać brakujące trasy powrotne oraz utrudniać późniejszą analizę i kontrolę dostępu.

Poznana trasa RIP nie musi automatycznie wygrać. Dłuższe prefiksy mają pierwszeństwo; następnie znaczenie mają także źródło routingu, Administrative Distance i globalna Route Precedence. Gdy konkurują trasy statyczne, SD-WAN lub VPN, Diagnostics > Tools > Route lookup pokazuje faktycznie wybraną ścieżkę. Route Precedence nie jest zmieniana globalnie dla pojedynczego testu RIP.

Weryfikacja RIP i rzeczywistej ścieżki danych

Weryfikacja rozdziela wymianę informacji routingu, wybraną trasę i przepływ danych.

Sprawdzenie Routes i Status

W Routing > Information > RIP > Routes Firewall A musi wyświetlać sieć 10.20.20.0/24 z next hop 198.51.100.2 i wiarygodną metryką. Peer B musi znać 10.10.10.0/24 przez 198.51.100.1.

W Routing > Information > RIP > Status należy porównać:

• uczestniczące interfejsy
• wysyłane i odbierane wersje RIP
• timery Update, Timeout i Garbage
• źródła routingu i redystrybucję
• Bad Packets i Bad Routes
• używane uwierzytelnianie lub Key Chain

Widoczny wpis potwierdza wymianę RIP, ale jeszcze nie wybór tej trasy ani przepływ danych.

Test Route Lookup i ruchu

1. Na Firewall A sprawdzić cel 10.20.20.10 w Diagnostics > Tools > Route lookup. Next hop i interfejs muszą odpowiadać ścieżce tranzytowej.
2. Na peerze B sprawdzić cel 10.10.10.10.
3. Z klienta 10.10.10.10 uruchomić rzeczywiste dozwolone połączenie z serwerem 10.20.20.10.
4. W Log viewer sprawdzić źródło, cel, usługę, Firewall Rule ID, Action i ewentualny NAT Rule ID.
5. W Diagnostics > Packet capture potwierdzić, że żądanie i odpowiedź przechodzą przez oczekiwane interfejsy.

Pełną procedurę opisuje artykuł Testowanie reguły zapory za pomocą Log Viewer i Packet Capture.

W ramach testu control plane tylko do odczytu można krótko filtrować pakiety RIP w Device Console:

tcpdump 'udp port 520'

Zakończyć wyświetlanie za pomocą Ctrl+C. Oczekiwane są aktualizacje między dwoma adresami tranzytowymi. Pakiety RIP z sieci LAN klientów wskazują natomiast w tym przykładzie na niewłaściwą granicę interfejsu lub Device Access.

W Advanced Shell logi dostarczają dodatkowego kontekstu:

cd /log
tail -f ripd.log

ripd.log pokazuje zdarzenia specyficzne dla protokołu. zebra.log pomaga ustalić, czy dynamicznie poznana trasa została zainstalowana w stosie routingu. Wyświetlanie na żywo kończy się przez Ctrl+C; następnie można użyć tail -f zebra.log. Pliki usług i logów Sophos Firewall porządkuje pozostałe pliki.

Systematyczne zawężanie przyczyn błędów

Nie pojawia się żadna trasa RIP

Najpierw sprawdzić bezpośrednią osiągalność między adresami tranzytowymi. Następnie Dynamic Routing musi być aktywny we właściwej strefie peera, RIP Network musi pasować do lokalnego interfejsu, a wersje wysyłania i odbierania muszą być zgodne. Przy uwierzytelnianiu metoda i sekret muszą być zgodne.

tcpdump 'udp port 520' odróżnia brak pakietów od odrzuconych lub nieprzydatnych aktualizacji. Jeśli w Status rosną liczniki Bad Packets lub Bad Routes, należy porównać wersję, uwierzytelnianie, podsieć i konfigurację peera.

Trasa jest widoczna w RIP, ale nie jest używana

Wymiana protokołu działa. Route Lookup pokazuje, czy wygrywa bardziej szczegółowy prefiks, trasa statyczna, SD-WAN, VPN lub inna wartość Administrative Distance. Sama metryka RIP nie rozstrzyga między wszystkimi źródłami routingu.

Nie usuwać globalnej Route Precedence ani istniejącej trasy produkcyjnej przed udokumentowaniem jej wpływu na inne sieci.

Ruch działa tylko w jednym kierunku

Peer potrzebuje trasy powrotnej, a obie zapory odpowiednich reguł. Dodatkowo należy sprawdzić NAT, ścieżki asymetryczne i bramę hosta. Istniejąca ścieżka w jedną stronę nie potwierdza ścieżki powrotnej.

Trasa znika i pojawia się ponownie

Niestabilne połączenie tranzytowe, utrata pakietów, restarty peera, różne timery lub błędy uwierzytelniania mogą wyzwalać timeout. Należy porównać wartości Update, Timeout i Garbage po obu stronach. Nie skracać timerów na podstawie przypuszczeń; najpierw potwierdzić ścieżkę pakietów i stan peera.

Rozgłaszane są nieoczekiwane sieci

Sprawdzić oddzielnie RIP Networks, Default information originate i każdą opcję redystrybucji. Redistribute connected może objąć więcej interfejsów niż tylko planowana sieć LAN. Redistribute static może również rozgłosić trasy blackhole lub zarządzające. Funkcja pozostaje wyłączona do czasu przygotowania kompletnej listy prefiksów i strategii filtrowania.

Kontrolowany test HA i failover

W klastrze HA po zaplanowanym failover należy ponownie sprawdzić na aktualnym Primary:

• RIP Status i uczestniczące interfejsy
• poznane trasy i ich wiek
• Route Lookup dla obu sieci LAN
• ripd.log i zebra.log na węźle, który przetworzył zdarzenie
• nowe dwukierunkowe połączenie testowe

Test wykonuje się w oknie serwisowym. Artykuł nie gwarantuje ani nieprzerwanej konwergencji RIP, ani zachowania istniejących sesji. Logi są przechowywane na węźle przetwarzającym, dlatego w razie potrzeby są zbierane z obu urządzeń.

Bezpieczne wycofanie zmiany

Przed usunięciem RIP dla każdej poznanej sieci docelowej musi istnieć ścieżka alternatywna lub zaplanowane okno serwisowe.

Zmiany wycofuje się w odwrotnej kolejności:

1. Wyłączyć nowo aktywowaną redystrybucję i Default information originate, jeśli świadomie należały do testu.
2. Usunąć lokalne RIP Networks.
3. Przywrócić Interface Overrides do udokumentowanego wcześniejszego stanu.
4. Wycofać globalne ustawienia RIP.
5. Usunąć Dynamic Routing ze strefy tranzytowej lub wyjątek ACL tylko wtedy, gdy nie wymaga go również żaden neighbor OSPF, BGP lub PIM.
6. W kontrolowany sposób aktywować alternatywną trasę statyczną lub dynamiczną.
7. Ponownie sprawdzić Route Lookup, reguły, dostęp administracyjny i rzeczywisty ruch.

Nie usuwać jednocześnie RIP i ścieżki zastępczej. Istniejącą sesję administratora należy pozostawić otwartą do czasu potwierdzenia trasy powrotnej.

Lista kontrolna

• Gateway Mode, interfejsy, strefy i adresy tranzytowe są udokumentowane.
• Dostępne są kopia zapasowa i niezależny dostęp administracyjny.
• Oba adresy tranzytowe mogą osiągnąć się bezpośrednio.
• Dynamic Routing jest dozwolony tylko dla strefy peera lub ściśle ograniczonego wyjątku.
• Obie strony używają zgodnych wartości RIPv2 i uwierzytelniania.
• RIP Networks pasują tylko do zamierzonych interfejsów lokalnych.
• Interfejsy LAN klientów używają Passive Mode.
• Default Route Origination i redystrybucja są włączone wyłącznie świadomie.
• Routes i Status pokazują oczekiwane prefiksy, next hops i timery.
• Route Lookup potwierdza wybrane ścieżki w obu kierunkach.
• Reguły zapory są ograniczone, rejestrowane i bez niezamierzonego SNAT.
• Rzeczywista usługa działa dwukierunkowo.
• Rollback i test HA są udokumentowane.

FAQ