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. Pozwolić rzeczywistemu Receiverowi dołączyć do grupy i uruchomić strumień.
  5. Sprawdzić trasę oraz ruch wejściowy i wyjściowy za pomocą mroute show i Packet Capture.

⚠️ Enable multicast forwarding jest ustawieniem globalnym. Przed jego włączeniem należy zinwentaryzować istniejące konfiguracje PIM-SM, statyczne trasy Multicast i zależne od nich strumienie. Zmianę najpierw sprawdza się za pomocą ograniczonego strumienia testowego; w razie nieoczekiwanego działania należy ją wycofać przed dodaniem kolejnych Destination Interfaces.

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ć.

Od SFOS 23 to osobne zadanie wykrywania konfiguruje się za pomocą reflektora mDNS w sekcji Network > mDNS. Wybór interfejsów wewnętrznych i kategorii usług oraz osobne zezwolenie na ruch aplikacji stanowią część tej odrębnej procedury; nie zastępuje ona opisanej tutaj statycznej trasy Multicast.

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ć, należy sprawdzić istniejącą konfigurację Multicast. Nie należy spontanicznie zmieniać istniejącej konfiguracji PIM-SM: aktualna pomoc SFOS 22 nie dokumentuje na odpowiednich stronach ogólnej zasady współistnienia, dlatego rozstrzygające są zachowanie zainstalowanego buildu i zatwierdzony projekt sieci.

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 odpowiednia jest również autoryzacja zabezpieczeń. Source i Destination Interface nie mogą być identyczne.

Użycie CLI jako kontrolowanej ścieżki alternatywnej

W Device Console ścieżka prowadzi przez 3. Route Configuration > 2. Configure Multicast Routing. Multicast Forwarding musi być aktywny przed dodaniem pierwszej trasy. Można go włączyć w Gateway Mode i Transparent Mode, ale statyczne trasy Multicast można konfigurować tylko w Gateway Mode. W opcji 1 następujące polecenie włącza globalne przekazywanie:

enable multicast-forwarding

⚠️ Według Sophos niekompletne polecenia Device Console mogą spowodować, że access_server przestanie odpowiadać. Dlatego należy uzupełnić składnię za pomocą ? lub klawisza Tab zgodnie z zainstalowanym buildem i dopiero wtedy wykonać pełne polecenie.

W 2. Configure Static-routes można dodać trasę między dwoma statycznymi interfejsami i od razu ją sprawdzić:

mroute add input-interface Port2 source-ip 10.10.10.20 dest-ip 239.10.10.10 output-interface Port3
mroute show

CLI wymaga osobnego wpisu mroute add dla każdego interfejsu wyjściowego. Oferuje tylko interfejsy statyczne, podczas gdy WebAdmin może również wyświetlać interfejsy dynamiczne, takie jak DHCP i PPPoE. Interfejs wejściowy i wyjściowy muszą być różne; interfejs nieoparty na Ethernet, taki jak IPsec0, nie należy do tej formy portowej.

W celu precyzyjnego usunięcia fizycznej trasy Sophos podaje wartości pozycyjnie. Najpierw należy sprawdzić nazwy interfejsów za pomocą mroute show:

mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show

Sophos publikuje osobne formy input-tunnel i output-tunnel dla tras IPsec i GRE, ale przykłady nie używają wszędzie jednolitej pisowni. Referencją jest uzupełnianie poleceń zainstalowanej wersji SFOS; publicznego przykładu nie należy wklejać bez weryfikacji.

Nie zakładać autoryzacji zabezpieczeń

Oficjalna instrukcja SFOS 22 dotycząca tworzenia statycznej trasy Multicast nie wymienia dodatkowej reguły firewalla ani NAT. Dlatego w tym przykładzie nie tworzy się zapobiegawczo szerokiej reguły Any. To, czy zainstalowany build lub istniejąca policy wymaga mimo wszystko dodatkowego dopasowania, sprawdza się w Packet Capture na podstawie rzeczywistego statusu pakietu.

Jeśli firewall pokazuje odrzucenie wynikające z policy, nie należy zgadywać: najpierw zapisuje się Source 10.10.10.20, grupę 239.10.10.10, UDP 5000, zaangażowane strefy i wyświetlony kontekst reguły. Dopiero po potwierdzeniu dla używanego buildu autoryzację ogranicza się dokładnie do tych wartości i włącza jej rejestrowanie. 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 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

  4. Na liście pakietów sprawdzić, czy strumień dociera do Port2 i pojawia się na Port3 ze statusem Forwarded. W przypadku odrzucenia należy zanotować wyświetlony status i kontekst reguły, nie rozszerzając reguły na podstawie przypuszczeń.

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

Procedurę Packet Capture z interfejsem, kontekstem reguły 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ć 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.
  • Jeśli kombinacja (S,G) już istnieje, należy porównać również Destination Interface. W przypadku wielu wyjść CLI wymaga osobnego wpisu dla każdego z nich z tym samym Source i grupą.

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 Capture pokazuje Forwarded, czy odrzucenie z użytecznym kontekstem reguły?
  • Czy Port3 rzeczywiście wybrano jako Destination Interface?

Strumień opuszcza firewall, ale nie dociera do Receivera

  • Sprawdzić TTL Sendera. Nie należy zmieniać globalnych parametrów routingu na podstawie przypuszczeń.
  • 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 Active-Active HA ruch Multicast nie jest rozkładany między oba Nodes. Sophos wyklucza ponadto Multicast z Session Failover. Przy zmianie ról należy więc liczyć się z przerwą w strumieniu. Przed Failover zapisuje się Capture i timestampy na dotychczas aktywnym Node; następnie ponownie sprawdza się trasę, ruch wejściowy, ruch wyjściowy i Receiver na nowym aktywnym Node.

Bezpieczne wycofanie zmian

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

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

Jeśli przykładową trasę utworzono za pomocą CLI, można ją usunąć pokazanym powyżej, oficjalnie udokumentowanym dla interfejsów fizycznych poleceniem mroute del, a następnie sprawdzić za pomocą mroute show. W przypadku tras tunelowych nie zamieszcza się niepotwierdzonego przykładu 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.