Konfigurera och verifiera PIM-SM i Sophos Firewall

PIM-SM passar när Multicast går via flera routrar och Receivers dynamiskt ansluter till eller lämnar grupper. I stället för att underhålla en fast route för varje Source och varje utgående interface bygger PIM-SM den Multicast-väg som behövs via en Rendezvous Point, förkortat RP.

Den korta proceduren är:

Förbered en backup och oberoende managementåtkomst. Dokumentera därefter Source, grupp, UDP-tjänst, routrar och Receiver-nätverk.
Kontrollera Unicast-nåbarheten till RP och Source-nätverket på varje router.
Säkra befintliga statiska Multicast-routes och avaktivera Enable multicast forwarding kontrollerat.
Kontrollera Device Access i zonerna med verkliga PIM-Neighbors och tillåt Dynamic Routing riktat endast vid behov.
Aktivera PIM på de berörda IPv4-interfaces under Routing > Multicast (PIM-SM).
Ange samma statiska RP och samma gruppintervall på alla PIM-routrar.
Tillåt Multicast-dataströmmen med snävt begränsade och loggade IPv4-firewallregler.
Kontrollera Receiver Join, Neighbor, RP SET, Multicast State, Rule ID och paketväg tillsammans.

⚠️ PIM-SM och Static Multicast Forwarding kan inte konfigureras samtidigt på Sophos Firewall. Växlingen ändrar den produktiva Multicast-vägen. Befintliga routes, grupper, Receivers och en returväg måste dokumenteras i förväg.

Den här artikeln behandlar dynamisk IPv4-Multicast Routing med en statisk RP. En Bootstrap Router, förkortad BSR, distribuerar information inom en PIM-domän om vilken RP som ansvarar för vilka grupper. Candidate RP beskrivs längre fram men används inte som om den automatiskt vore en Bootstrap-Router-lösning.

När PIM-SM är rätt val

PIM-SM är framför allt användbart när flera Multicast-routrar deltar, Receivers finns i olika nätverk eller gruppmedlemskapen ändras ofta. Routrarna bygger då endast State där det finns en Sender eller en intresserad Receiver.

För en enda känd Sender och ett fåtal permanent fasta utgående interfaces är en statisk Multicast-route oftast enklare. Den behöver varken RP eller PIM-grannskap. PIM-SM är inte en bättre inställning för samma lilla topologi, utan en annan driftmodell.

PIM-SM ersätter inte heller Unicast Routing eller firewallregler:

Unicast Routing avgör i vilken riktning Source och RP är nåbara.
PIM-SM bygger Multicast-distributionsträdet mellan routrarna utifrån detta.
IGMP meddelar i det lokala Receiver-nätverket vilka hosts som vill ta emot en grupp.
Firewallregler tillåter eller blockerar den faktiska Multicast-dataströmmen mellan zoner.

Förstå IGMP, RP och RPF

En Receiver skickar ett IGMP-medlemskapsmeddelande för sin grupp i det lokala IPv4-nätverket. Den sista Multicast-routern omvandlar intresset till en PIM Join i riktning mot RP. RP är den gemensamma mötespunkt där Sender och Receiver först hittar varandra. Beroende på den State som byggs upp kan datavägen senare byta till en kortare Source Tree. RP behöver därför inte permanent vidarebefordra varje datapaket.

I Multicast-tabellen står (*,G) för en grupps gemensamma State oberoende av en bestämd Source. (S,G) betecknar i stället State för en konkret Source S och grupp G. I exemplet är det (10.10.10.20, 239.10.10.10).

Den avgörande kontrollmekanismen heter Reverse Path Forwarding, förkortat RPF. För ett paket från Source 10.10.10.20 kontrollerar firewall via vilket interface den skulle nå denna Source enligt routingtabellen. Om Multicast-streamen kommer in via ett annat interface stämmer returvägen inte, och State eller dataflödet kan misslyckas.

PIM är oberoende av vilket Unicast-routingprotokoll som används, men inte av fungerande Unicast-routes. Statiska routes, OSPF eller BGP kan tillhandahålla RPF-vägen. I följande exempel räcker statiska Unicast-routes. I större routingdomäner kan OSPF tillhandahålla samma grund dynamiskt.

Planera exempeltopologin

Exemplet kopplar samman en Sender bakom Firewall A med en Receiver bakom Firewall B:

Sender: 10.10.10.20
Source-nätverk på Firewall A: 10.10.10.0/24, interface Port2, zon DMZ
Firewall A Transit: 10.255.0.1/30, interface Port4, zon PIM-Transit
Firewall B Transit: 10.255.0.2/30, interface Port4, zon PIM-Transit
Receiver-nätverk på Firewall B: 10.20.20.0/24, interface Port3, zon LAN
Test Receiver: 10.20.20.50
Multicast-grupp: 239.10.10.10
Application Service: UDP 5000
Statisk RP: 10.255.0.1
RP-gruppintervall: 239.10.10.0/24

Adresserna är privata exempelvärden. Source, Receiver-nätverk, transitnätverk, grupp och tjänst ersätts tillsammans med värdena för den verkliga applikationen. RP 10.255.0.1 finns i det här exemplet på Firewall A och måste vara nåbar med Unicast från alla PIM-routrar.

Gruppintervallet 239.10.10.0/24 är avsiktligt snävare än *. En asterisk tilldelar alla grupper till RP och ska bara användas om hela PIM-domänen har planerats på det sättet. Sophos dokumenterar högst åtta grupp- eller nätverksposter per RP.

Unicast-routes måste vara på plats före PIM-konfigurationen. Firewall A får en route till 10.20.20.0/24 via 10.255.0.2, och Firewall B får en route till 10.10.10.0/24 via 10.255.0.1. För RPF är särskilt vägen från Firewall B tillbaka till Source viktig. En sökning efter 10.10.10.20 under Diagnostics > Tools > Route lookup måste därför visa Port4 och förväntad Next Hop. Dessa Unicast-routes ersätter inte PIM-distributionsträdet.

Hur interfaces och zoner separeras tydligt för en sådan transitförbindelse förklaras i Konfigurera zoner och interfaces på Sophos Firewall.

Förbered PIM-SM säkert

Följande punkter dokumenteras före underhållsfönstret:

Transit-IP-adresser och Unicast-routes har testats i båda riktningarna.
Source, grupp, UDP-port och Receiver-applikation är kända.
Statisk RP och dess gruppintervall är dokumenterade på samma sätt för alla routrar.
Befintliga statiska Multicast-routes och Enable multicast forwarding är inventerade.
En konfigurationsbackup och oberoende managementåtkomst finns tillgängliga.
Switchar i Receiver-nätverket använder IGMP Snooping endast med en klarlagd och fungerande Querier-roll.

Den aktuella Sophos-dokumentationen nämner fysiska interfaces samt RED och GRE-interfaces för PIM. Alias-, PPPoE- och Cellular WAN-interfaces är undantagna. Andra interfacetyper, till exempel XFRM, bekräftas inte uttryckligen på PIM-sidan och ska därför inte användas oprövade i den här grundtopologin.

Kontrollera Dynamic Routing riktat

PIM-meddelanden tillhör firewallens Control Plane. Den allmänna SFOS-hjälpen grupperar routingprotokoll under Administration > Device access > Dynamic Routing, men den aktuella PIM-sidan nämner inte uttryckligen detta beroende.

Om inget PIM-grannskap bildas kontrolleras därför om Dynamic Routing måste tillåtas i zonen där den faktiska Neighborn finns. I exemplet innehåller den egna zonen PIM-Transit endast transitnätverket mellan de båda firewalls. Om tillåtelsen krävs för den här topologin aktiveras den endast där på båda enheterna.

Tillåtelsen i matrisen gäller hela zonen. Om samma zon innehåller andra, ej betrodda nätverk förblir kryssrutan avaktiverad, och ett snävt avgränsat Local Service ACL Exception tillåter Dynamic Routing endast från avsedda Neighbors. Ett ytterligare Exception begränsar inte en zonbehörighet som redan är aktiv.

Detta Device Access-lager är avsett för routingens Control Traffic. Om tillåtelsen krävs för PIM på den build som används gäller den inte den vidarebefordrade streamen och ersätter inte streamens firewallregel. De två åtkomstlagren förklaras i Säkra Device Access på Sophos Firewall.

Ersätt Static Multicast Forwarding kontrollerat

Under Routing > Static routes dokumenteras befintliga Multicast-routes, beroende applikationer och destinationsinterfaces. Enable multicast forwarding avaktiveras först under underhållsfönstret. Därefter kan PIM-SM aktiveras.

Ta inte bort befintliga statiska Multicast-routes i förebyggande syfte. De finns kvar som dokumenterad Rollback-mall tills PIM-SM har verifierats fullständigt.

Konfigurera PIM-SM

Följande steg utförs på Firewall A och Firewall B.

Aktivera PIM och berörda interfaces

Öppna Routing > Multicast (PIM-SM).
Aktivera Enable PIM.
Välj under PIM-enabled interface endast de IPv4-interfaces som ingår i Multicast-vägen:
- Firewall A: Port2 och Port4
- Firewall B: Port4 och Port3
Betrakta inte ändringen som lyckad ännu. Neighbor och State kontrolleras först efter den fullständiga RP-konfigurationen.

PIM aktiveras inte generellt på alla LAN- eller WAN-interfaces. Varje ytterligare interface utökar Control Plane och kan möjliggöra nya Neighbors eller Multicast-vägar.

Ange statisk RP och gruppintervall

Under RP settings aktiveras alternativet, och samma statiska tilldelning anges på båda firewalls:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

RP IP är en Unicast-adress. Den måste vara nåbar från båda firewalls via den planerade PIM-vägen. Det räcker inte att spara värdet: under Routing > Information > PIM-SM > RP SET måste gruppen senare faktiskt vara tilldelad till denna RP.

Spara därefter konfigurationen. Om PIM inte kan aktiveras ska man först kontrollera om Enable multicast forwarding fortfarande är aktivt.

När Candidate RP är lämplig

Candidate RP passar i en befintlig PIM-domän där BSR-rollen och RP-urvalsprocessen redan har planerats. SFOS erbjuder för detta en interface-IP som Candidate RP IP, en grupplista, en prioritet från 1 till 255 och ett Advertisement Interval från 30 till 180 sekunder.

Enbart Candidate-RP-konfigurationen gör dock inte automatiskt firewall till en fungerande BSR och garanterar inte önskat RP-val. Sophos dokumenterar ingen fullständig konfiguration av Bootstrap Router i WebAdmin. Candidate RP används därför först när BSR-rollen är känd och resulterande Group-to-RP Mapping kan kontrolleras under RP SET. För det överskådliga exemplet är Static RP lättare att följa.

Skapa firewallregler för dataströmmen

PIM-grannskapet innebär ingen generell säkerhetstillåtelse. På varje router behöver streamen en snävt avgränsad IPv4-firewallregel för respektive zonövergång.

På Firewall A ser målkonfigurationen ut så här:

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: egen UDP-tjänst med Destination Port 5000
Action: Accept
Log firewall traffic: aktiverat

På Firewall B skapas en andra regel från PIM-Transit till LAN med samma Source, grupp och UDP-tjänst. Ingen SNAT används för testet, så att Source och (S,G) bevaras.

Reglerna gäller Multicast-dataströmmen. PIM-Hellos och IGMP-medlemskapsmeddelanden kombineras inte med en bred Any-regel. Med Rule ID kontrolleras om gruppobjektet matchar som förväntat på den build som används. Om Rule 0 visas utökas inte regeln okontrollerat, utan paketvägen analyseras.

Den allmänna konfigurationen förklaras i Konfigurera Sophos Firewall-regler säkert.

Verifiera PIM-SM från Neighbor till Receiver

Ett synligt PIM-grannskap är bara den första delen av verifieringen:

Under Routing > Information > PIM-SM > Interface table måste den andra firewall visas som Neighbor vid transitinterfacet.
Under RP SET måste 239.10.10.0/24 peka på 10.255.0.1.
Starta Receiver-applikationen på 10.20.20.50 och anslut till 239.10.10.10 på UDP 5000.
Starta en tidsbegränsad teststream från 10.10.10.20.
Sök under Multicasting routing table efter gruppens (*,G)- eller (S,G)-State. Incoming och Outgoing Interfaces måste stämma med topologin.
Kontrollera förväntad Rule ID i Log Viewer på båda firewalls.
Kontrollera under Diagnostics > Packet capture med följande BPF-filter:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
Streamen måste komma in på Port2 och gå ut på Port4 på Firewall A. På Firewall B tas den emot på Port4 och vidarebefordras på Port3. Kontrollera därefter det faktiska innehållet på Receiver.

Packet Capture-proceduren med interface, Rule ID, Status och Reason finns i Använd Packet Capture på Sophos Firewall.

För Control Traffic kan dessutom följande BPF-filter användas under ett avgränsat test:

ip proto 103

103 står för PIM. IGMP använder IP-protokoll 2:

ip proto 2

Filtren visar om PIM- och IGMP-paket finns. De bevisar inte ensamma vare sig korrekt RP eller en fungerande dataström.

I Advanced Shell ger pimd.log ytterligare sammanhang. Följande kommandon läser endast data:

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

En tom grep-träff bevisar inte ett fel. Aktuell State i WebAdmin och den verkliga paketvägen är fortfarande avgörande. Ytterligare routing- och loggfiler förklaras i Sophos Firewall-tjänste- och loggfiler.

Avgränsa fel efter symptom

Ingen PIM-Neighbor visas

Kontrollera direkt nåbarhet till transit-IP-adresserna 10.255.0.1 och 10.255.0.2.
Kontrollera att Port4 är valt som PIM-enabled interface på båda firewalls.
Kontrollera Dynamic Routing i rätt transitzon eller motsvarande Local Service ACL Exception.
Kontrollera med ip proto 103 om PIM-paket når och lämnar transitinterfacet.
Säkerställ att en interfacetyp som Sophos dokumenterar för PIM används.

Neighbor finns, men RP SET saknas eller är fel

Jämför RP IP och gruppintervall tecken för tecken på alla routrar.
Kontrollera Unicast-nåbarheten till 10.255.0.1.
Klarlägg först den verkliga BSR-rollen vid Candidate RP. Enbart en konfigurerad kandidatur räcker inte.
Utöka inte till * innan det är klart varför den konkreta gruppen inte tilldelas.

RP SET stämmer, men ingen Multicast State skapas

Kontrollera att Receiver faktiskt har anslutit till rätt grupp och UDP-port.
Sök efter IGMP Reports och Queries i Receiver-nätverket med ip proto 2.
Kontrollera Querier-rollen i VLAN vid IGMP Snooping. Ändra inte IGMP-timers på måfå; grundproceduren kräver ingen timerändring.
Kontrollera att Sender faktiskt skickar till 239.10.10.10:5000.

State finns, men Incoming Interface är fel

Utför Route Lookup till Source 10.10.10.20 och RP 10.255.0.1 på varje firewall.
Kontrollera statiska, OSPF-, SD-WAN- och VPN-routes efter en oväntat bättre väg.
Ändra inte global Route Precedence innan den felaktiga RPF-vägen har bekräftats med routingtabellen och Capture.
Dokumentera asymmetriska returvägar och parallella förbindelser separat.

Streamen lämnar firewall men når inte Receiver

Kontrollera Rule ID, Status och Outgoing Interface på båda firewalls.
Kontrollera switchport, VLAN och IGMP Snooping i Receiver-nätverket.
Kontrollera lokal host-firewall och Receiver-applikationen.
Jämför en Capture på Receiver eller switchporten med SFOS-tidsstämplarna.

Ta hänsyn till HA- och interfacegränser

I Active-Active HA fördelas inte Multicast mellan båda nodes. UDP-, Broadcast- och Multicast-sessioner tas inte över vid Failover. Ett kontrollerat rollbyte kan därför avbryta streamen. Därefter kontrolleras Neighbor, RP SET, RPF, Multicast State, regler och Receiver på nytt.

Loggarna lagras lokalt per node. Vid ett HA-problem säkras data från den node som var aktiv före växlingen. En hitless synkronisering av PIM State förutsätts inte.

Den här grundartikeln använder fysiska interfaces. Sophos anger dessutom RED och GRE som PIM-kompatibla. Det bekräftar inte PIM direkt på XFRM-, IPsec- eller SSL VPN-interfaces. En krypterad eller operatörsberoende Multicast-design kräver därför en separat, testad arkitektur.

Återställ säkert

Återställningen sker under underhållsfönstret:

Stoppa teststreamen och dokumentera den senaste fungerande eller felaktiga State.
Avaktivera de nya Multicast-firewallreglerna.
Avaktivera PIM på båda firewalls.
Ta bort Dynamic Routing från transitzonen endast om inget annat routingprotokoll är beroende av inställningen.
Återaktivera Static Multicast Forwarding endast om föregående tillstånd och dess routes är fullständigt dokumenterade.
Kontrollera managementåtkomst, Unicast-routes och tidigare produktiva applikationer igen.

Den här återställningen kräver inga omstarter av PIM-tjänster, Debug-inställningar eller odokumenterade Advanced-Shell-kommandon.

Vanliga frågor

Ersätter PIM-SM IGMP eller firewallregeln?

Nej. IGMP meddelar Receivers intresse i det lokala nätverket, PIM-SM kopplar samman de berörda Multicast-routrarna och firewallregeln tillåter den konkreta dataströmmen mellan zoner. Alla tre lagren måste passa samma design.

Varför påverkar en Unicast-route Multicast-vägen?

PIM-SM använder RPF. Firewall kontrollerar med hjälp av routinginformationen genom vilket interface Source eller RP skulle vara nåbara. Om routen pekar på fel interface stämmer den förväntade returvägen inte, och Multicast State kan bli felaktig eller ofullständig.