Konfiguracja i weryfikacja PIM-SM na Sophos Firewall

PIM-SM sprawdza się, gdy Multicast przebiega przez wiele routerów, a odbiorcy dynamicznie dołączają do grup lub je opuszczają. Zamiast utrzymywać stałą trasę dla każdego źródła i interfejsu wyjściowego, PIM-SM buduje wymaganą ścieżkę Multicast przez Rendezvous Point, w skrócie RP.

Skrócona procedura wygląda następująco:

Przygotować kopię zapasową i niezależny dostęp administracyjny, a następnie udokumentować źródło, grupę, usługę UDP, routery i sieci odbiorców.
Na każdym routerze sprawdzić osiągalność Unicast punktu RP i sieci źródłowej.
Zabezpieczyć istniejące statyczne trasy Multicast i w kontrolowany sposób wyłączyć Enable multicast forwarding.
Sprawdzić Device Access w strefach z rzeczywistymi sąsiadami PIM i zezwolić na Dynamic Routing tylko tam, gdzie jest to potrzebne.
W sekcji Routing > Multicast (PIM-SM) włączyć PIM na uczestniczących interfejsach IPv4.
Na wszystkich routerach PIM wprowadzić ten sam statyczny RP i zakres grup.
Zezwolić na strumień danych Multicast za pomocą wąsko ograniczonych i rejestrowanych reguł firewalla IPv4.
Wspólnie sprawdzić Receiver Join, Neighbor, RP SET, Multicast State, Rule ID i ścieżkę pakietu.

⚠️ PIM-SM i Static Multicast Forwarding nie mogą być skonfigurowane jednocześnie na Sophos Firewall. Przełączenie zmienia produkcyjną ścieżkę Multicast. Wcześniej trzeba udokumentować istniejące trasy, grupy, odbiorców i drogę powrotną.

Ten artykuł dotyczy dynamicznego IPv4-Multicast Routing ze statycznym RP. Bootstrap Router, w skrócie BSR, rozsyła w domenie PIM informację, który RP odpowiada za poszczególne grupy. Candidate RP zostanie omówiony dalej, ale nie jest traktowany jako rzekomo automatyczne rozwiązanie Bootstrap Router.

Kiedy PIM-SM jest właściwym wyborem

PIM-SM jest szczególnie przydatny, gdy uczestniczy wiele routerów Multicast, odbiorcy znajdują się w różnych sieciach lub członkostwo w grupach często się zmienia. Routery tworzą wtedy State tylko tam, gdzie istnieje nadawca lub zainteresowany odbiorca.

Dla jednego znanego nadawcy i kilku stale określonych interfejsów wyjściowych zwykle prostsza pozostaje statyczna trasa Multicast. Nie wymaga ona RP ani sąsiedztwa PIM. PIM-SM nie jest lepszym rozwiązaniem dla tej samej małej topologii, lecz innym modelem działania.

PIM-SM nie zastępuje również Unicast Routing ani reguł firewalla:

Unicast Routing określa kierunek osiągalności źródła i RP.
PIM-SM buduje na tej podstawie drzewo dystrybucji Multicast między routerami.
IGMP zgłasza w lokalnej sieci odbiorców, które hosty chcą otrzymywać daną grupę.
Reguły firewalla zezwalają na właściwy strumień danych Multicast między strefami lub go blokują.

Zrozumienie IGMP, RP i RPF

Odbiorca wysyła w lokalnej sieci IPv4 komunikat członkostwa IGMP dla swojej grupy. Ostatni router Multicast przekształca to zainteresowanie w PIM Join w kierunku RP. RP jest wspólnym punktem spotkania, przez który nadawca i odbiorca początkowo się odnajdują. Zależnie od utworzonego State ścieżka danych może później przełączyć się na krótsze Source Tree, dlatego RP nie musi stale przekazywać każdego pakietu danych.

W tabeli Multicast zapis (*,G) oznacza wspólny State grupy niezależny od konkretnego źródła. (S,G) oznacza natomiast State dla konkretnego źródła S i grupy G. W przykładzie jest to (10.10.10.20, 239.10.10.10).

Kluczowy mechanizm kontroli to Reverse Path Forwarding, w skrócie RPF. Dla pakietu ze źródła 10.10.10.20 firewall sprawdza, przez który interfejs dotarłby do tego źródła zgodnie z tabelą routingu. Jeśli strumień Multicast przychodzi przez inny interfejs, ścieżka wsteczna nie pasuje i utworzenie State lub przepływ danych może się nie udać.

PIM jest niezależny od używanego protokołu routingu Unicast, ale nie od działających tras Unicast. Ścieżkę RPF mogą zapewnić trasy statyczne, OSPF lub BGP. W poniższym przykładzie wystarczą statyczne trasy Unicast, a w większych domenach routingu OSPF może dynamicznie zapewniać tę samą podstawę.

Planowanie przykładowej topologii

Przykład łączy nadawcę za Firewallem A z odbiorcą za Firewallem B:

Sender: 10.10.10.20
Sieć źródłowa na Firewallu A: 10.10.10.0/24, interfejs Port2, strefa DMZ
Firewall A Transit: 10.255.0.1/30, interfejs Port4, strefa PIM-Transit
Firewall B Transit: 10.255.0.2/30, interfejs Port4, strefa PIM-Transit
Sieć odbiorców na Firewallu B: 10.20.20.0/24, interfejs Port3, strefa LAN
Test Receiver: 10.20.20.50
Grupa Multicast: 239.10.10.10
Application Service: UDP 5000
Statyczny RP: 10.255.0.1
Zakres grup RP: 239.10.10.0/24

Adresy są prywatnymi wartościami przykładowymi. Źródło, sieć odbiorców, sieć tranzytową, grupę i usługę należy wspólnie zastąpić wartościami rzeczywistej aplikacji. W tym przykładzie RP 10.255.0.1 znajduje się na Firewallu A i musi być osiągalny przez Unicast ze wszystkich routerów PIM.

Zakres grup 239.10.10.0/24 jest celowo węższy niż *. Gwiazdka przypisuje do RP wszystkie grupy i powinna być używana tylko wtedy, gdy cała domena PIM jest tak zaprojektowana. Sophos dokumentuje maksymalnie osiem wpisów grup lub sieci na jeden RP.

Przed konfiguracją PIM muszą działać trasy Unicast. Firewall A otrzymuje trasę do 10.20.20.0/24 przez 10.255.0.2, a Firewall B trasę do 10.10.10.0/24 przez 10.255.0.1. Dla RPF szczególnie ważna jest ścieżka z Firewalla B z powrotem do źródła. Dlatego zapytanie dla 10.10.10.20 w sekcji Diagnostics > Tools > Route lookup musi wskazywać Port4 i oczekiwany Next Hop. Te trasy Unicast nie zastępują drzewa dystrybucji PIM.

Sposób prawidłowego rozdzielenia interfejsów i stref dla takiego tranzytu opisano w artykule Konfiguracja stref i interfejsów na Sophos Firewall.

Bezpieczne przygotowanie PIM-SM

Przed oknem serwisowym należy ustalić następujące kwestie:

Adresy tranzytowe IP i trasy Unicast zostały przetestowane w obu kierunkach.
Znane są źródło, grupa, port UDP i aplikacja odbiorcza.
Statyczny RP i jego zakres grup są identycznie udokumentowane dla wszystkich routerów.
Istniejące statyczne trasy Multicast i Enable multicast forwarding są zinwentaryzowane.
Dostępna jest kopia zapasowa konfiguracji i niezależny dostęp administracyjny.
Przełączniki w sieci odbiorców używają IGMP Snooping tylko z wyjaśnioną i działającą rolą Querier.

Aktualna dokumentacja Sophos wymienia dla PIM interfejsy fizyczne, RED i interfejsy GRE. Interfejsy Alias, PPPoE i Cellular WAN są wykluczone. Inne typy interfejsów, takie jak XFRM, nie są jednoznacznie potwierdzone na stronie PIM, dlatego nie powinny trafiać do tej podstawowej topologii bez weryfikacji.

Ukierunkowane sprawdzenie Dynamic Routing

Komunikaty PIM należą do Control Plane firewalla. Ogólna pomoc SFOS grupuje protokoły routingu w sekcji Administration > Device access > Dynamic Routing, jednak aktualna strona PIM nie wymienia tej zależności wprost.

Jeśli nie powstaje sąsiedztwo PIM, należy zatem sprawdzić, czy Dynamic Routing musi być dozwolony w strefie rzeczywistego sąsiada. W przykładzie osobna strefa PIM-Transit zawiera tylko sieć tranzytową między oboma firewallami. Jeśli to zezwolenie jest wymagane w tej topologii, włącza się je na obu urządzeniach wyłącznie w tej strefie.

Zezwolenie w macierzy dotyczy całej strefy. Jeśli w tej samej strefie znajdują się inne, niezaufane sieci, pole pozostaje wyłączone, a wąsko ograniczona Local Service ACL Exception zezwala na Dynamic Routing tylko z przewidzianych sąsiadów. Dodatkowy wyjątek nie zawęża już aktywnego zezwolenia dla strefy.

Ta warstwa Device Access jest przeznaczona dla ruchu sterującego routingu. Jeśli zezwolenie dla PIM jest wymagane na używanym buildzie, nie dotyczy przekazywanego strumienia i nie zastępuje jego reguły firewalla. Obie warstwy dostępu opisano w artykule Zabezpieczenie Device Access na Sophos Firewall.

Kontrolowane zastąpienie Static Multicast Forwarding

W sekcji Routing > Static routes należy udokumentować istniejące trasy Multicast, zależne aplikacje i interfejsy docelowe. Enable multicast forwarding wyłącza się dopiero w oknie serwisowym. Dopiero wtedy można włączyć PIM-SM.

Nie usuwać profilaktycznie istniejących statycznych tras Multicast. Pozostają udokumentowanym wzorcem Rollback do czasu pełnej weryfikacji PIM-SM.

Konfiguracja PIM-SM

Poniższe kroki wykonuje się na Firewallu A i Firewallu B.

Włączanie PIM i używanych interfejsów

Otworzyć Routing > Multicast (PIM-SM).
Włączyć Enable PIM.
W sekcji PIM-enabled interface wybrać tylko interfejsy IPv4 uczestniczące w ścieżce Multicast:
- Firewall A: Port2 i Port4
- Firewall B: Port4 i Port3
Nie uznawać jeszcze zmiany za sukces; Neighbor i State są sprawdzane dopiero po pełnej konfiguracji RP.

PIM nie jest włączany ogólnie na wszystkich interfejsach LAN ani WAN. Każdy dodatkowy interfejs rozszerza Control Plane i może umożliwić nowych sąsiadów lub ścieżki Multicast.

Wprowadzanie statycznego RP i zakresu grup

W sekcji RP settings należy włączyć opcję i na obu firewallach wprowadzić to samo statyczne przypisanie:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

RP IP jest adresem Unicast. Musi być osiągalny z obu firewalli przez zaplanowaną ścieżkę PIM. Sam zapis wartości nie wystarcza: w sekcji Routing > Information > PIM-SM > RP SET grupa musi być później rzeczywiście przypisana do tego RP.

Następnie zapisać konfigurację. Jeśli nie można włączyć PIM, najpierw sprawdzić, czy Enable multicast forwarding jest nadal aktywne.

Kiedy Candidate RP ma sens

Candidate RP pasuje do istniejącej domeny PIM, w której rola BSR i procedura wyboru RP są już zaplanowane. SFOS udostępnia w tym celu adres IP interfejsu jako Candidate RP IP, listę grup, priorytet od 1 do 255 i Advertisement Interval od 30 do 180 sekund.

Sama konfiguracja Candidate RP nie czyni jednak firewalla automatycznie działającym BSR ani nie gwarantuje oczekiwanego wyboru RP. Sophos nie dokumentuje w WebAdmin kompletnej konfiguracji Bootstrap Routera. Dlatego Candidate RP używa się dopiero wtedy, gdy znana jest rola BSR i można sprawdzić wynikowe Group-to-RP Mapping w sekcji RP SET. Dla tego przejrzystego przykładu łatwiejszy do prześledzenia pozostaje Static RP.

Tworzenie reguł firewalla dla strumienia danych

Sąsiedztwo PIM nie zapewnia ogólnego zezwolenia bezpieczeństwa. Strumień wymaga na każdym routerze wąsko ograniczonej reguły firewalla IPv4 dla danego przejścia między strefami.

Na Firewallu A docelowa konfiguracja wygląda następująco:

Rule name: DMZ_to_PIM_Multicast_5000
Source zone: DMZ
Source network: Host 10.10.10.20
Destination zone: PIM-Transit
Destination network: Host 239.10.10.10
Services: własna usługa UDP z Destination Port 5000
Action: Accept
Log firewall traffic: włączone

Na Firewallu B tworzy się drugą regułę z PIM-Transit do LAN, z tym samym źródłem, grupą i usługą UDP. W teście nie przewidziano SNAT, aby zachować źródło i (S,G).

Reguły dotyczą strumienia danych Multicast. PIM-Hello i komunikaty członkostwa IGMP nie są łączone z szeroką regułą Any. Zgodność obiektu grupy na używanym buildzie należy potwierdzić za pomocą Rule ID. Jeśli pojawi się Rule 0, reguły nie należy rozszerzać bez kontroli, lecz przeanalizować ścieżkę pakietu.

Ogólną konfigurację opisano w artykule Bezpieczna konfiguracja reguł Sophos Firewall.

Weryfikacja PIM-SM od sąsiada do odbiorcy

Widoczne sąsiedztwo PIM to tylko pierwszy etap weryfikacji:

W sekcji Routing > Information > PIM-SM > Interface table na interfejsie tranzytowym musi być widoczny drugi firewall jako Neighbor.
W sekcji RP SET wpis 239.10.10.0/24 musi wskazywać 10.255.0.1.
Na 10.20.20.50 uruchomić aplikację odbiorczą i dołączyć do 239.10.10.10 na UDP 5000.
Uruchomić ograniczony czasowo strumień testowy z 10.10.10.20.
W sekcji Multicasting routing table znaleźć dla grupy State (*,G) lub (S,G). Incoming i Outgoing Interfaces muszą odpowiadać topologii.
W Log Viewer na obu firewallach sprawdzić oczekiwany Rule ID.
W sekcji Diagnostics > Packet capture sprawdzić za pomocą następującego filtra BPF:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
Strumień musi wejść na Firewall A przez Port2 i wyjść przez Port4. Firewall B odbiera go przez Port4 i przekazuje przez Port3. Następnie trzeba sprawdzić rzeczywistą zawartość po stronie odbiorcy.

Procedurę Packet Capture z interfejsem, Rule ID, Status i Reason opisano w artykule Korzystanie z Packet Capture na Sophos Firewall.

Podczas ograniczonego testu można dodatkowo użyć następujących filtrów BPF dla ruchu sterującego:

ip proto 103

103 oznacza PIM. IGMP używa protokołu IP 2:

ip proto 2

Filtry pokazują obecność pakietów PIM i IGMP. Same w sobie nie potwierdzają ani prawidłowego RP, ani działającego strumienia danych.

W Advanced Shell dodatkowy kontekst zawiera pimd.log. Poniższe polecenia tylko odczytują dane:

tail -n 200 /log/pimd.log
grep '239.10.10.10' /log/pimd.log | tail -n 100

Brak wyniku grep nie dowodzi błędu; decydujące pozostają aktualny State w WebAdmin i rzeczywista ścieżka pakietu. Inne pliki routingu i dzienników opisano w artykule Pliki usług i dzienników Sophos Firewall.

Ograniczanie błędu według objawu

Nie pojawia się PIM Neighbor

Sprawdzić bezpośrednią osiągalność adresów tranzytowych 10.255.0.1 i 10.255.0.2.
Sprawdzić, czy Port4 na obu firewallach wybrano jako PIM-enabled interface.
Sprawdzić Dynamic Routing we właściwej strefie tranzytowej lub odpowiedniej Local Service ACL Exception.
Za pomocą ip proto 103 sprawdzić, czy pakiety PIM docierają do interfejsu tranzytowego i go opuszczają.
Upewnić się, że używany jest typ interfejsu udokumentowany przez Sophos dla PIM.

Neighbor jest widoczny, ale RP SET nie istnieje lub jest błędny

Na wszystkich routerach porównać znak po znaku RP IP i zakres grup.
Sprawdzić osiągalność Unicast adresu 10.255.0.1.
W przypadku Candidate RP najpierw wyjaśnić rzeczywistą rolę BSR. Sama skonfigurowana kandydatura nie wystarcza.
Nie rozszerzać zakresu do *, zanim nie będzie jasne, dlaczego konkretna grupa nie jest przypisywana.

RP SET jest poprawny, ale nie powstaje Multicast State

Sprawdzić, czy odbiorca rzeczywiście dołączył do właściwej grupy i portu UDP.
Za pomocą ip proto 2 wyszukać IGMP Reports i Queries w sieci odbiorców.
W przypadku IGMP Snooping sprawdzić rolę Querier w VLAN. Nie zmieniać timerów IGMP na próbę; podstawowa procedura nie wymaga zmiany timerów.
Sprawdzić, czy nadawca rzeczywiście wysyła do 239.10.10.10:5000.

State istnieje, ale Incoming Interface jest błędny

Na każdym firewallu wykonać Route Lookup do źródła 10.10.10.20 i RP 10.255.0.1.
Sprawdzić trasy statyczne, OSPF, SD-WAN i VPN pod kątem nieoczekiwanie lepszej ścieżki.
Nie zmieniać globalnej Route Precedence, dopóki błędna ścieżka RPF nie zostanie potwierdzona tabelą routingu i Capture.
Oddzielnie udokumentować asymetryczne drogi powrotne i połączenia równoległe.

Strumień opuszcza firewall, ale nie dociera do odbiorcy

Na obu firewallach sprawdzić Rule ID, Status i Outgoing Interface.
Sprawdzić port przełącznika, VLAN i IGMP Snooping w sieci odbiorców.
Sprawdzić lokalny firewall hosta i aplikację odbiorczą.
Porównać Capture na odbiorcy lub porcie przełącznika ze znacznikami czasu SFOS.

Uwzględnienie ograniczeń HA i interfejsów

W Active-Active HA ruch Multicast nie jest rozdzielany między oba węzły. Sesje UDP, Broadcast i Multicast nie są przejmowane podczas Failover. Kontrolowana zmiana ról może więc przerwać strumień; następnie trzeba ponownie sprawdzić Neighbor, RP SET, RPF, Multicast State, reguły i odbiorcę.

Dzienniki są przechowywane lokalnie na każdym węźle. Przy problemie HA należy zabezpieczyć dane węzła aktywnego przed przełączeniem. Nie zakłada się bezprzerwowej synchronizacji PIM State.

Ten artykuł bazowy używa interfejsów fizycznych. Sophos wymienia dodatkowo RED i GRE jako obsługujące PIM. Nie potwierdza to PIM bezpośrednio na interfejsach XFRM, IPsec ani SSL VPN. Szyfrowany lub zależny od operatora projekt Multicast wymaga więc osobnej, przetestowanej architektury.

Bezpieczne wycofanie zmian

Wycofanie wykonuje się w oknie serwisowym:

Zatrzymać strumień testowy i udokumentować ostatni działający lub błędny State.
Wyłączyć nowo utworzone reguły firewalla Multicast.
Wyłączyć PIM na obu firewallach.
Usunąć Dynamic Routing ze strefy tranzytowej tylko wtedy, gdy nie zależy od niego żaden inny protokół routingu.
Ponownie włączyć Static Multicast Forwarding tylko wtedy, gdy wcześniejszy stan i jego trasy są w pełni udokumentowane.
Ponownie sprawdzić dostęp administracyjny, trasy Unicast i wcześniej używane aplikacje produkcyjne.

Ten Rollback nie wymaga restartowania usług PIM, przełączników Debug ani nieudokumentowanych poleceń Advanced Shell.

Często zadawane pytania

Czy PIM-SM zastępuje IGMP lub regułę firewalla?

Nie. IGMP zgłasza zainteresowanie odbiorców w sieci lokalnej, PIM-SM łączy uczestniczące routery Multicast, a reguła firewalla zezwala na konkretny strumień danych między strefami. Wszystkie trzy warstwy muszą odpowiadać temu samemu projektowi.

Dlaczego trasa Unicast wpływa na ścieżkę Multicast?

PIM-SM używa RPF. Firewall sprawdza na podstawie informacji routingu, przez który interfejs byłyby osiągalne źródło lub RP. Jeśli trasa wskazuje niewłaściwy interfejs, oczekiwana ścieżka wsteczna nie pasuje, a Multicast State może pozostać błędny lub niepełny.