Przejdz do tresci
Avanet

Konfiguracja i testowanie Multicast na Sophos Firewall przy użyciu trasy statycznej

Sophos Firewall

Statyczna trasa Multicast przekazuje strumień danych ze znanego źródła do stałej grupy Multicast przez wybrane interfejsy. Jest to odpowiednie na przykład dla strumienia wideo, audio lub telemetrii, którego Source, grupa i sieci Receiverów pozostają niezmienne.

Ta procedura dotyczy statycznego IPv4-Multicast Routing. IPv6-Multicast nie jest przedmiotem tej instrukcji.

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

  1. Udokumentować Source-IP, grupę Multicast, port UDP oraz interfejs wejściowy i wyjściowy.
  2. W sekcji Routing > Static routes włączyć Enable multicast forwarding.
  3. W sekcji Manage multicast route > Add wprowadzić Source, grupę i interfejsy.
  4. Utworzyć wąsko ograniczoną i rejestrowaną regułę firewalla IPv4 dla strumienia danych.
  5. Pozwolić rzeczywistemu Receiverowi dołączyć do grupy i uruchomić strumień.
  6. Sprawdzić trasę, Rule ID oraz ruch wejściowy i wyjściowy za pomocą mroute show, Log Viewer i Packet Capture.

⚠️ Static Multicast Forwarding i PIM-SM nie mogą być skonfigurowane jednocześnie na Sophos Firewall. Aby używać Static Multicast Forwarding, PIM musi być wyłączony. Przed przełączeniem należy ustalić, czy PIM-SM lub inna statyczna trasa Multicast jest już używana produkcyjnie.

Jak działają Multicast, IGMP i trasa statyczna

W przypadku Unicast host wysyła dane na pojedynczy adres docelowy. W przypadku Multicast Source wysyła dane jednokrotnie na adres grupy, a wiele Receiverów może subskrybować ten sam strumień. Firewall nie kopiuje strumienia do dowolnych sieci, lecz tylko do Destination Interfaces wpisanych w trasie Multicast.

W przykładzie używana jest stała kombinacja nadawcy 10.10.10.20 i grupy 239.10.10.10. Jest ona często określana jako Source i Group, w skrócie (S,G). Jeśli aplikacja zmieni Source-IP lub grupę, trasa przestanie pasować.

IGMP zgłasza w lokalnym segmencie IPv4, że Receiver chce dołączyć do grupy Multicast lub ją opuścić. Dzięki IGMP Snooping przełącznik może przekazywać strumień tylko do portów, za którymi znajdują się zainteresowani odbiorcy. Statyczna trasa Sophos nie uczy się jednak na tej podstawie nowych Destination Interfaces: Port3 pozostaje skonfigurowany na stałe, nawet jeśli w danym momencie nie nasłuchuje tam żaden Receiver.

PIM-SM rozwiązuje inne zadanie. Dynamicznie buduje ścieżki Multicast między wieloma routerami Multicast i wymaga zaplanowanego projektu Rendezvous Point oraz Unicast Routing. Dla jednego znanego nadawcy i kilku stałych interfejsów Receivera trasa statyczna jest zwykle bardziej przejrzysta. Przy wielu routerach, zmieniających się grupach lub licznych ścieżkach Multicast PIM-SM wymaga osobnego projektu.

Statyczna trasa Multicast nie jest też zwykłą statyczną trasą Unicast. Nie używa klasycznego Next Hop i jest wyświetlana w osobnej sekcji.

mDNS to inny przypadek użycia

mDNS używany przez Bonjour, AirPlay i wiele mechanizmów wyszukiwania Chromecast korzysta z adresu link-local 224.0.0.251. Sophos dopuszcza w statycznej trasie Multicast grupy od 224.0.2.0 do 239.255.255.255; mDNS znajduje się poza tym zakresem i nie jest przekazywany przez routery tak jak zwykły ruch Multicast.

Ta instrukcja nie zastępuje więc mDNS Reflector ani Discovery Gateway. Strumień multimedialny może działać przez Multicast, podczas gdy automatyczne wykrywanie urządzeń między VLANs nadal nie będzie działać.

Planowanie przykładowej topologii

W przykładzie używane są następujące wartości:

  • Sender: 10.10.10.20
  • Source Interface: Port2
  • Source Zone: DMZ
  • Multicast Group: 239.10.10.10
  • Application Service: UDP 5000
  • Destination Interface: Port3
  • Destination Zone: LAN
  • Receiver Network: 10.20.20.0/24
  • Test Receiver: 10.20.20.50

10.10.10.20 i 10.20.20.0/24 są prywatnymi wartościami przykładowymi. 239.10.10.10 należy do administracyjnie ograniczonego zakresu Multicast i nadaje się do kontrolowanego przykładu lokalnego. We własnym środowisku Source, grupę, port i interfejsy należy łącznie zastąpić wartościami wynikającymi z aplikacji i topologii. Grupy nie wolno zmieniać dowolnie: Sender i Receiver muszą używać tego samego adresu i tej samej usługi.

Aplikacja musi również wysyłać z odpowiednią wartością TTL. W normalnym routingu wartość TTL jest zmniejszana o jeden przy każdym przeskoku. Jeśli aplikacja wysyła z TTL 1, strumień nie dotrze do kolejnego segmentu, gdy zmniejszanie TTL jest włączone.

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

  • Firewall działa w Gateway Mode.
  • Sender dociera do Port2, a Receivery znajdują się za Port3.
  • Aplikacja Receivera potrafi rzeczywiście dołączyć do grupy 239.10.10.10 i portu UDP 5000.
  • Istniejące konfiguracje PIM-SM, inne trasy Multicast i ich zależności są udokumentowane.
  • Znane są przełączniki, VLANs i ustawienia IGMP Snooping w sieci Receivera.
  • Dostępna jest kopia zapasowa konfiguracji i niezależny dostęp administracyjny.

Zależności między interfejsami, VLANs i strefami opisano w artykule Konfiguracja stref i interfejsów na Sophos Firewall.

Tworzenie statycznej trasy Multicast

Włączanie Multicast Forwarding

  1. W WebAdmin otworzyć Routing > Static routes.
  2. W sekcji Multicast forwarding setting wybrać Enable multicast forwarding.
  3. Kliknąć Apply, a następnie OK.

Jeśli opcji nie można włączyć, najpierw należy sprawdzić, czy PIM-SM jest aktywny. Obu metod nie można konfigurować równolegle. Nie należy spontanicznie wyłączać PIM-SM, dopóki jego istniejące Neighbors, grupy i Receivery nie zostaną udokumentowane.

Wprowadzanie Source, grupy i interfejsów

  1. W sekcji Manage multicast route kliknąć Add.
  2. W polu Source IPv4 address wpisać 10.10.10.20.
  3. Jako Source interface wybrać Port2.
  4. W polu Multicast IPv4 address wpisać 239.10.10.10.
  5. Jako Destination interface wybrać Port3.
  6. Zapisać, klikając Save.

WebAdmin może zapisać wiele Destination Interfaces w jednej trasie. Każdy dodatkowy interfejs rozszerza jednak obszar, do którego przekazywany jest strumień. Należy go wybierać tylko wtedy, gdy rzeczywiście znajdują się tam Receivery i pozwalają na to również zasady bezpieczeństwa. Source i Destination Interface nie mogą być identyczne.

Wąskie ograniczenie reguły firewalla

Trasa Multicast określa ścieżkę, ale nie zezwala automatycznie na przesyłanie strumienia. Aby przekazywać ruch z DMZ do LAN, należy utworzyć osobną regułę firewalla IPv4:

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

Destination jest grupą Multicast, a nie siecią Receivera 10.20.20.0/24. Reguła jest ograniczona do rzeczywistego Sendera, właściwej grupy i wymaganej usługi. W tym przykładzie nie używa się szerokiej reguły Any ani ogólnego zezwolenia na IGMP lub PIM.

Reguła jest wąskim docelowym układem dla tej przykładowej topologii; jej rzeczywisty Match musi zostać potwierdzony na używanej wersji SFOS za pomocą oczekiwanego Rule ID. Jeśli pojawi się Rule 0, reguły nie należy rozszerzać w niekontrolowany sposób, lecz sprawdzić ją za pomocą Log Viewer i Packet Capture.

W tym przykładzie nie przewidziano SNAT, aby zachować Source i przypisanie (S,G). Istniejące reguły NAT należy mimo to sprawdzić pod kątem nieoczekiwanego Match. Ogólną strukturę reguł wyjaśnia artykuł Bezpieczna konfiguracja reguł Sophos Firewall.

Kontrolowane testowanie strumienia danych

Zapisana trasa nie dowodzi jeszcze, że Receiver odbiera strumień. Test odbiorczy śledzi pakiet od aplikacji do klienta:

  1. Na 10.20.20.50 uruchomić aplikację Receivera i dołączyć do grupy 239.10.10.10 na UDP 5000.

  2. Uruchomić wyraźnie ograniczony strumień testowy z 10.10.10.20 oraz zanotować czas rozpoczęcia i oczekiwany czas trwania.

  3. W Log Viewer sprawdzić, czy używany jest DMZ_to_LAN_Multicast_5000 lub oczekiwany Rule ID.

  4. W sekcji Diagnostics > Packet capture użyć następującego ciągu BPF:

    src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000

  5. Na liście pakietów sprawdzić, czy strumień dociera do Port2 i pojawia się na Port3 ze statusem Forwarded.

  6. Na Receiverze sprawdzić, czy pakiety docierają i aplikacja przetwarza zawartość.

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

W Device Console można dodatkowo wyświetlić statyczną tabelę Multicast Routing w trybie tylko do odczytu. Ścieżka prowadzi przez 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes:

mroute show

Wynik musi pokazywać oczekiwane Source, grupę oraz interfejs wejściowy i wyjściowy. Polecenie nie zmienia konfiguracji.

W celu głębszego Troubleshooting aktualna dokumentacja SFOS 22 wskazuje mrouting.log. W Advanced Shell odczytywane są tylko najnowsze wpisy:

tail -n 200 /log/mrouting.log

Pozostałe pliki i przypisania usług opisano w artykule Pliki usług i logów Sophos Firewall.

Zawężanie błędu według objawu

Trasy nie można aktywować lub zapisać

  • Sprawdzić, czy PIM-SM jest nadal aktywny. Static Multicast Forwarding i PIM-SM nie mogą być skonfigurowane jednocześnie.
  • Sprawdzić Source-IP, zakres grupy i interfejsy. Dozwolone są grupy od 224.0.2.0 do 239.255.255.255.
  • Source i Destination Interface nie mogą być identyczne.
  • W przypadku istniejącej trasy sprawdzić, czy ta sama kombinacja (S,G) nie jest już skonfigurowana.

Strumień dociera do firewalla, ale nie jest przekazywany

  • Czy rzeczywiste Source-IP i grupa dokładnie odpowiadają trasie?
  • Czy mroute show pokazuje oczekiwane interfejsy?
  • Czy pasuje zamierzona reguła firewalla, czy Capture pokazuje inny Rule ID albo Rule 0?
  • Czy Port3 rzeczywiście wybrano jako Destination Interface?
  • Czy reguła NAT nieoczekiwanie zmienia Source?

Strumień opuszcza firewall, ale nie dociera do Receivera

  • Sprawdzić TTL Sendera i globalne ustawienie multicast-decrement-ttl. Nie należy zmieniać tego ustawienia bez konkretnego powodu.
  • Sprawdzić VLAN, Switchport i IGMP Snooping w sieci Receivera.
  • Upewnić się, że 10.20.20.50 dołączył do właściwej grupy i portu UDP.
  • Sprawdzić lokalny host firewall i aplikację na Receiverze.
  • Porównać Capture na Receiverze lub Switchport z timestampami SFOS.

Wykrywanie urządzeń nie działa, ale strumień działa

Protokoły Discovery, takie jak mDNS, są link-local i nie są odzwierciedlane przez tę statyczną trasę. Rzeczywisty strumień danych i wykrywanie urządzeń należy sprawdzać oddzielnie.

Oddzielne podejście do VPN i HA

Sophos nie obsługuje Multicast przez SSL VPN. Statyczne trasy Multicast przez IPsec lub wcześniej zweryfikowany tunel GRE są możliwe i używają własnych form CLI. W przypadku IPsec Sophos wymaga dodatkowo jawnego hosta Unicast z /32 w konfiguracji VPN. Publicznie udokumentowane przykłady zawierają kilka niespójnych zapisów, dlatego nie należy ich bez sprawdzenia używać jako poleceń Copy-and-paste na produkcyjnym firewallu.

W przypadku Multicast przez tunel VPN ważna jest także wersja firmware. Powtarzające się awarie firewalla występujące w związku czasowym z tym ruchem opisano w artykule IPsec Troubleshooting dla NC-180433. Problem został rozwiązany w SFOS 22.0 MR2 Build 546; zwykła utrata pakietów lub brak strumienia nie dowodzi tego konkretnego przypadku.

W klastrze HA ruch Multicast nie jest rozkładany między oba Nodes. Po zaplanowanym Failover należy ponownie sprawdzić trasę, Rule ID, ruch wejściowy i wyjściowy oraz Receiver. Sophos nie dokumentuje gwarancji nieprzerwanego Multicast Failover, dlatego test należy przeprowadzić w Maintenance Window. Logi i Packet Captures zapisuje się na aktualnie aktywnym Node.

Bezpieczne wycofanie zmian

Przed wycofaniem zmian należy udokumentować trasę, nazwę reguły i dotychczasowe wartości testowe. Następnie:

  1. Zatrzymać strumień testowy.
  2. Wyłączyć nową regułę firewalla.
  3. Usunąć statyczną trasę Multicast w WebAdmin.
  4. Wyłączyć Enable multicast forwarding tylko wtedy, gdy nie zależy od niego żadna inna statyczna trasa Multicast.
  5. Ponownie sprawdzić poprzedni stan objętych zmianą aplikacji i sieci.

Do tego Rollback nie jest potrzebny CLI Delete. Dzięki temu wycofanie pozostaje możliwe do prześledzenia i pozwala uniknąć niespójnej, publicznie udokumentowanej składni usuwania.

Często zadawane pytania

Kiedy statyczna trasa Multicast jest lepsza niż PIM-SM?

Gdy Sender, grupa i kilka Destination Interfaces pozostają stale niezmienne, trasa statyczna jest zwykle prostsza. PIM-SM sprawdza się przy wielu routerach Multicast, dynamicznych ścieżkach i licznych zmieniających się grupach.

Czy można w ten sposób wykrywać Bonjour, AirPlay lub Chromecast między VLANs?

Nie za pomocą samej tej trasy. mDNS używa 224.0.0.251, jest link-local i do przekazywania między VLANs wymaga przeznaczonej do tego funkcji Reflection lub Gateway.

Dlaczego potrzebna jest dodatkowa reguła firewalla?

Trasa Multicast opisuje, dokąd ma być przekazywany strumień. Reguła firewalla nadal decyduje, czy dokładnie ten Source, grupa i usługa UDP mogą przechodzić między zaangażowanymi strefami.