Hoppa till innehållet
Avanet

Konfigurera och testa Multicast på Sophos Firewall med en statisk route

Sophos Firewall

En statisk Multicast-route vidarebefordrar dataströmmen från en känd avsändare till en fast Multicast-grupp via valda interfaces. Det passar exempelvis för en video-, ljud- eller telemetristream där Source, grupp och Receiver-nätverk är permanent fastställda.

Den här proceduren behandlar statisk IPv4-Multicast Routing. IPv6-Multicast ingår inte i den här guiden.

Den korta proceduren är:

  1. Dokumentera Source-IP, Multicast-grupp, UDP-port samt inkommande och utgående interface.
  2. Aktivera Enable multicast forwarding under Routing > Static routes.
  3. Ange Source, grupp och interfaces under Manage multicast route > Add.
  4. Låt en verklig Receiver ansluta till gruppen och starta streamen.
  5. Kontrollera routen samt inkommande och utgående trafik med mroute show och Packet Capture.

⚠️ Enable multicast forwarding är en global inställning. Innan den aktiveras måste befintliga PIM-SM-konfigurationer, statiska Multicast-routes och beroende streams inventeras. Ändringen testas först med en begränsad teststream. Vid oväntat beteende återställs den innan fler Destination Interfaces läggs till.

Förstå Multicast, IGMP och den statiska routen

Med Unicast skickar en host data till en enskild destinationsadress. Med Multicast skickar Source en gång till en gruppadress, och flera Receivers kan prenumerera på samma dataström. Firewall kopierar inte streamen till godtyckliga nätverk utan endast till de Destination Interfaces som har angetts i Multicast-routen.

Exemplet använder den fasta kombinationen av avsändaren 10.10.10.20 och gruppen 239.10.10.10. Kombinationen benämns ofta Source och Group, förkortat (S,G). Om applikationen ändrar Source-IP eller grupp matchar routen inte längre.

IGMP meddelar i det lokala IPv4-segmentet att en Receiver vill ansluta till eller lämna en Multicast-grupp. Med IGMP Snooping kan en switch därför endast vidarebefordra streamen till portar med intresserade mottagare. Den statiska Sophos-routen lär sig dock inga nya Destination Interfaces av detta: Port3 förblir fast konfigurerad även om ingen Receiver lyssnar där för tillfället.

PIM-SM har en annan uppgift. Det bygger dynamiskt Multicast-vägar mellan flera Multicast-routrar och kräver en planerad design för Rendezvous Point och Unicast Routing. För en enda känd avsändare och ett fåtal fasta Receiver-interfaces är den statiska routen oftast mer överskådlig. Med flera routrar, varierande grupper eller många Multicast-vägar kräver PIM-SM en separat design.

En statisk Multicast-route är dessutom inte en vanlig statisk Unicast-route. Den använder ingen klassisk Next Hop och visas i ett separat område.

mDNS är ett annat användningsfall

mDNS för Bonjour, AirPlay och många Chromecast-sökningar använder den link-local adressen 224.0.0.251. Sophos tillåter grupper från 224.0.2.0 till 239.255.255.255 i den statiska Multicast-routen. mDNS ligger utanför detta intervall och vidarebefordras inte av routrar som vanlig Multicast-trafik.

Den här guiden ersätter därför inte en mDNS Reflector eller Discovery Gateway. En mediaström kan fungera via Multicast medan automatisk enhetsidentifiering mellan VLANs fortfarande inte fungerar.

Planera exempeltopologin

Exemplet använder följande värden:

  • 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 och 10.20.20.0/24 är privata exempelvärden. 239.10.10.10 ligger i det administrativt avgränsade Multicast-intervallet och lämpar sig för ett kontrollerat lokalt exempel. I den egna miljön ersätts Source, grupp, port och interfaces tillsammans med värdena från applikationen och topologin. Gruppen får inte ändras godtyckligt: Sender och Receiver måste använda samma adress och samma tjänst.

Applikationen måste dessutom skicka med tillräcklig TTL. Vid normal routing minskas TTL med ett för varje hopp. Om applikationen skickar med TTL 1 når streamen inget ytterligare segment när TTL-minskning är aktiverad.

Följande punkter ska vara fastställda före ändringen:

  • Firewall körs i Gateway Mode.
  • Sender når Port2, och Receivers finns bakom Port3.
  • Receiver-applikationen kan faktiskt ansluta till gruppen 239.10.10.10 på UDP 5000.
  • Befintliga PIM-SM-konfigurationer, andra Multicast-routes och deras beroenden är dokumenterade.
  • Switchar, VLANs och IGMP Snooping-inställningar i Receiver-nätverket är kända.
  • En konfigurationsbackup och oberoende managementåtkomst finns tillgängliga.

Sambandet mellan interfaces, VLANs och zoner förklaras i Konfigurera zoner och interfaces på Sophos Firewall.

Skapa en statisk Multicast-route

Aktivera Multicast Forwarding

  1. Öppna Routing > Static routes i WebAdmin.
  2. Välj Enable multicast forwarding under Multicast forwarding setting.
  3. Klicka på Apply och därefter på OK.

Om alternativet inte kan aktiveras ska den befintliga Multicast-konfigurationen kontrolleras. Ändra inte spontant en befintlig PIM-SM-konfiguration: den aktuella SFOS 22-hjälpen dokumenterar ingen generell regel om samexistens på de berörda sidorna. Därför avgör beteendet i den installerade builden och den godkända nätverksdesignen.

Ange Source, grupp och interfaces

  1. Klicka på Add under Manage multicast route.
  2. Ange 10.10.10.20 under Source IPv4 address.
  3. Välj Port2 som Source interface.
  4. Ange 239.10.10.10 under Multicast IPv4 address.
  5. Välj Port3 som Destination interface.
  6. Spara med Save.

WebAdmin kan spara flera Destination Interfaces i en route. Varje ytterligare interface utökar dock området som streamen vidarebefordras till. Det ska bara väljas om Receivers verkligen finns där och säkerhetsregeln också tillåter det. Source och Destination Interface får inte vara identiska.

Använd CLI som en kontrollerad reservväg

I Device Console går sökvägen via 3. Route Configuration > 2. Configure Multicast Routing. Multicast Forwarding måste vara aktivt innan den första routen läggs till. Det kan aktiveras i Gateway Mode och Transparent Mode, men statiska Multicast-routes kan endast konfigureras i Gateway Mode. Under alternativ 1 aktiverar följande kommando den globala vidarebefordringen:

enable multicast-forwarding

⚠️ Enligt Sophos kan ofullständiga Device Console-kommandon medföra att access_server slutar svara. Komplettera därför syntaxen med ? eller Tab mot den installerade builden och kör det fullständiga kommandot först därefter.

Under 2. Configure Static-routes kan en route mellan två statiska interfaces läggas till och kontrolleras direkt:

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

CLI kräver en separat mroute add-post för varje utgående interface. Den erbjuder endast statiska interfaces, medan WebAdmin även kan visa dynamiska interfaces som DHCP och PPPoE. In- och utgående interface måste vara olika; ett icke-Ethernet-baserat interface som IPsec0 hör inte hemma i denna portform.

För att ta bort en fysisk route på ett kontrollerat sätt anger Sophos värdena positionsbaserat. Kontrollera först interfacenamnen med mroute show:

mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show

Sophos publicerar separata input-tunnel- och output-tunnel-former för IPsec- och GRE-routes, men exemplen använder inte konsekvent samma skrivsätt. Kommandokompletteringen i den installerade SFOS-versionen är referensen; klistra inte in ett offentligt exempel utan verifiering.

Förutsätt inte säkerhetsregler

Den officiella SFOS 22-guiden för att skapa en statisk Multicast-route anger ingen ytterligare firewall- eller NAT-regel. Därför skapas ingen bred Any-regel i förebyggande syfte i det här exemplet. Om den installerade builden eller en befintlig policy ändå kräver ytterligare en Match kontrolleras detta i Packet Capture utifrån paketets faktiska status.

Om firewallen visar en policyorsakad Drop ska du inte gissa: dokumentera först Source 10.10.10.20, gruppen 239.10.10.10, UDP 5000, de berörda zonerna och den regelkontext som visas. Först efter bekräftelse för den build som används begränsas och loggas en tillåtelse för exakt dessa värden. Den allmänna regelstrukturen förklaras i Konfigurera Sophos Firewall-regler säkert.

Testa dataströmmen kontrollerat

En sparad route bevisar ännu inte att Receiver tar emot streamen. Acceptanstestet följer paketet från applikationen till klienten:

  1. Starta Receiver-applikationen på 10.20.20.50 och anslut till gruppen 239.10.10.10 på UDP 5000.

  2. Starta en tydligt begränsad teststream från 10.10.10.20 och notera tidpunkt och förväntad varaktighet.

  3. Filtrera under Diagnostics > Packet capture med den här BPF-strängen:

    src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000

  4. Kontrollera i paketlistan om streamen kommer in på Port2 och visas på Port3 med Status Forwarded. Vid en Drop dokumenteras visad Status och regelkontext utan att en regel utökas på måfå.

  5. Kontrollera på Receiver om paketen kommer fram och applikationen bearbetar innehållet.

Packet Capture-proceduren med interface, regelkontext och Status beskrivs i Använd Packet Capture på Sophos Firewall.

I Device Console kan den statiska Multicast Routing Table dessutom visas read-only. Sökvägen går via 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes:

mroute show

Utdata måste visa förväntad Source, grupp samt inkommande och utgående interfaces. Kommandot ändrar inte konfigurationen.

För djupare Troubleshooting anger den aktuella SFOS 22-dokumentationen mrouting.log. I Advanced Shell läses endast de senaste posterna:

tail -n 200 /log/mrouting.log

Ytterligare filer och tjänstetilldelningar beskrivs i Sophos Firewall service- och loggfiler.

Begränsa felet efter symptom

Routen kan inte aktiveras eller sparas

  • Kontrollera Source-IP, gruppintervall och interfaces. Grupper från 224.0.2.0 till 239.255.255.255 är tillåtna.
  • Source och Destination Interface får inte vara identiska.
  • Om en (S,G)-kombination redan finns ska även Destination Interface jämföras. För flera utgångar kräver CLI en egen post med samma Source och grupp för varje utgång.

Streamen kommer in men vidarebefordras inte

  • Matchar den verkliga Source-IP-adressen och gruppen exakt routen?
  • Visar mroute show förväntade interfaces?
  • Visar Capture Forwarded eller en Drop med användbar regelkontext?
  • Har Port3 verkligen valts som Destination Interface?

Streamen lämnar firewall men når inte Receiver

  • Kontrollera Senderns TTL. Ändra inte globala routingparametrar på måfå.
  • Kontrollera VLAN, Switchport och IGMP Snooping i Receiver-nätverket.
  • Säkerställ att 10.20.20.50 har anslutit till rätt grupp och UDP-port.
  • Kontrollera den lokala host-firewallen och applikationen på Receiver.
  • Jämför en Capture på Receiver eller Switchport med SFOS-timestamps.

Enhetsidentifieringen fungerar inte men streamen fungerar

Discovery-protokoll som mDNS är link-local och reflekteras inte av den här statiska routen. Den faktiska dataströmmen och enhetsidentifieringen måste kontrolleras separat.

Hantera VPN och HA separat

Multicast via SSL VPN stöds inte av Sophos. Statiska Multicast-routes via IPsec eller en tidigare validerad GRE-tunnel är möjliga och använder egna CLI-former. För IPsec kräver Sophos dessutom en explicit Unicast-host med /32 i VPN-konfigurationen. De offentligt dokumenterade exemplen innehåller flera inkonsekventa skrivsätt och ska därför inte användas okontrollerat som Copy-and-paste-kommandon i en produktionsfirewall.

För Multicast via en VPN-tunnel är firmwareversionen också viktig. Upprepade firewallcrasher i tidsmässigt samband med den här trafiken behandlas i IPsec Troubleshooting för NC-180433. Felet är löst i SFOS 22.0 MR2 Build 546. Normal paketförlust eller en stream som saknas bevisar inte detta särskilda fall.

I Active-Active HA lastbalanseras inte Multicast mellan de båda Nodes. Sophos undantar dessutom Multicast från Session Failover. Vid ett rollbyte måste man därför räkna med ett avbrott i streamen. Före Failover sparas Capture och timestamps på den tidigare aktiva Noden. Därefter kontrolleras route, inkommande och utgående trafik samt Receiver på nytt på den nya aktiva Noden.

Återställ säkert

Före återställningen dokumenteras route, interfaces och hittillsvarande testvärden. Därefter:

  1. Stoppa teststreamen.
  2. Ta bort den statiska Multicast-routen i WebAdmin.
  3. Avaktivera Enable multicast forwarding endast om ingen annan statisk Multicast-route är beroende av inställningen.
  4. Kontrollera det tidigare tillståndet för berörda applikationer och nätverk på nytt.

Om exempelrouten i stället skapades via CLI kan den tas bort med det ovan visade, officiellt dokumenterade mroute del för fysiska interfaces och kontrolleras med mroute show. För tunnelroutes används inget obekräftat borttagningsexempel.

Vanliga frågor

När är en statisk Multicast-route bättre än PIM-SM?

Om Sender, grupp och ett fåtal Destination Interfaces är permanent fastställda är den statiska routen oftast enklare. PIM-SM passar för flera Multicast-routrar, dynamiska vägar och många varierande grupper.