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.
Zinwentaryzować istniejące statyczne trasy Multicast i zaplanować migrację w oknie serwisowym.
W sekcji Routing > Multicast (PIM-SM) włączyć PIM na uczestniczących interfejsach IPv4.
Na wszystkich routerach PIM wprowadzić planowany statyczny RP i zakres grup.
Sterować strumieniem danych Multicast za pomocą wąsko ograniczonych i rejestrowanych reguł firewalla IPv4.
Wspólnie sprawdzić dołączenie do grupy, aplikację UDP, sąsiada PIM, RP SET, Multicast State, Rule ID i ścieżkę pakietu.

⚠️ Przejście ze statycznych tras Multicast na PIM-SM zmienia produkcyjną ścieżkę Multicast. Dlatego trzeba udokumentować istniejące trasy, grupy, odbiorców i plan Rollback. Pomoc SFOS 22 opisuje Static Multicast Forwarding i PIM-SM oddzielnie, ale nie podaje ogólnej zasady ich współistnienia ani wzajemnego wykluczania. Zamiast zakładać pracę równoległą, należy sprawdzić faktycznie używany build w oknie serwisowym.

Ten artykuł dotyczy dynamicznego IPv4-Multicast Routing ze statycznym RP. SFOS 22 obsługuje PIM w wersji 2 oraz PIM-SM; Sophos dokumentuje BSR na potrzeby dynamicznego wyboru RP. Przykład celowo pozostaje przy statycznym RP. Candidate RP i BSR są jedynie omawiane dalej w odpowiednim kontekście.

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 wymaga co najmniej jednego interfejsu PIM z adresem IPv4. Jako obsługiwane wymienia 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ć bez testów do tej podstawowej topologii.

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.

Inwentaryzacja istniejącego Static Multicast Forwarding

W sekcji Routing > Static routes należy udokumentować istniejące trasy Multicast, zależne aplikacje i interfejsy docelowe. Pomoc SFOS 22 nie potwierdza, czy Enable multicast forwarding i PIM-SM można konfigurować równolegle w każdym buildzie. Dlatego istniejący stan należy zmieniać dopiero w oknie serwisowym i odnotować reakcję interfejsu.

Nie usuwać profilaktycznie istniejących statycznych tras Multicast. Pozostają udokumentowanym wzorcem Rollback do czasu pełnej weryfikacji PIM-SM. Jeśli SFOS wymaga wyłączenia statycznego forwardingu przed włączeniem PIM, krok ten jest częścią planowanej migracji, a nie przyjętą bez potwierdzenia ogólną regułą produktu.

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
Zapisać. Dopiero po pełnej konfiguracji sąsiad PIM, przypisanie RP i Multicast State pokażą, czy topologia działa.

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

W przypadku wielu grup adresy IP grup Multicast lub adresy sieci należy oddzielić przecinkami w polu Multicast group. Przykład nadal wykorzystuje jedną sieć o wąskim zakresie.

Nie mylić limitu adresów IP punktów RP z limitem grup: Pomoc SFOS 22 i SFOS 23 podaje oddzielnie w polu RP IP: „Maximum eight RP IP addresses per RP are allowed.” Zgodnie z tym sformułowaniem dozwolonych jest maksymalnie osiem adresów IP punktów RP „na jeden RP”, ale zakres określenia „na jeden RP” pozostaje niejasny. Nie oznacza to niezależnego potwierdzenia limitu ośmiu punktów RP dla całego urządzenia. Ten przykład używa jednego RP. Przed zaprojektowaniem konfiguracji z wieloma RP należy sprawdzić zakres limitu dla używanego buildu lub wyjaśnić go z Sophos Support.

RP IP jest adresem Unicast. Na Firewallu B tabela routingu Unicast musi wskazywać Port4 i 10.255.0.1 jako oczekiwaną ścieżkę; na Firewallu A RP IP jest adresem własnego interfejsu. 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.

Zapisać konfigurację. Jeśli SFOS nie pozwala włączyć PIM, sprawdzić komunikat interfejsu i bieżący stan Enable multicast forwarding. Zmienić tę opcję tylko wtedy, gdy interfejs faktycznie potwierdzi konflikt w używanym buildzie i udokumentowana jest droga wycofania.

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. Pola SFOS mają następujące znaczenie:

Candidate RP IP: Wybrany adres IP interfejsu jest używany jako adres IP punktu RP, jeśli router zostanie wybrany jako Candidate RP.
Multicast group list: Maksymalnie osiem adresów IP grup Multicast lub adresów sieci, które ma obsługiwać ten RP; wiele wpisów należy oddzielić przecinkami.
Candidate RP priority: Priorytet routera PIM w wyborze RP, od 1 do 255, z wartością domyślną 1.
Timer: Odstęp między generowanymi komunikatami kandydatury RP, od 30 do 180 sekund, z wartością domyślną 60.

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. Ogólne reguły firewalla SFOS sterują ruchem między strefami i sieciami. Poniższy model dwóch reguł jest więc wąsko ograniczoną konfiguracją Avanet dla tej topologii, a nie obowiązkowym wzorcem PIM udokumentowanym przez Sophos.

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. W Packet Capture należy oceniać łącznie Rule ID, Status, Reason oraz interfejs wejściowy i wyjściowy. Pomoc SFOS 22 nie dokumentuje ogólnego znaczenia Rule ID 0; sama ta wartość nie dowodzi zatem braku dopasowania reguły.

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ą. System operacyjny musi dołączyć do grupy 239.10.10.10, a aplikacja musi dodatkowo nasłuchiwać 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; PIM timers i flag bits dostarczają dodatkowego kontekstu diagnostycznego.
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 system operacyjny odbiorcy dołączył do właściwej grupy i czy aplikacja nasłuchuje na UDP 5000.
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 i raporty nie są synchronizowane między węzłami HA. Przy problemie HA należy więc zabezpieczyć dane węzła, który przetwarzał ruch przed przełączeniem. Oficjalna pomoc HA nie dokumentuje transferu stanu specyficznego dla PIM; artykuł nie wyprowadza z tego żadnego szerszego twierdzenia o synchronizacji.

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.
Jeśli podczas migracji wyłączono Static Multicast Forwarding, przywrócić udokumentowany wcześniejszy stan wraz z trasami.
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.