Configurar e verificar PIM-SM na Sophos Firewall

O PIM-SM é indicado quando o Multicast atravessa vários routers e os Receivers aderem ou abandonam grupos dinamicamente. Em vez de manter uma rota fixa para cada Source e cada interface de saída, o PIM-SM cria o caminho Multicast necessário através de um Rendezvous Point, abreviado como RP.

O procedimento resumido é o seguinte:

Disponibilizar um backup e um acesso de gestão independente; depois documentar a Source, o grupo, o serviço UDP, os routers e as redes dos Receivers.
Verificar em cada router a acessibilidade Unicast ao RP e à rede da Source.
Inventariar as rotas Multicast estáticas existentes e planear a migração para uma janela de manutenção.
Em Routing > Multicast (PIM-SM), ativar o PIM nas interfaces IPv4 envolvidas.
Introduzir o RP estático planeado e o intervalo de grupos em todos os routers PIM.
Controlar o fluxo de dados Multicast com regras de firewall IPv4 restritas e com registo.
Verificar em conjunto a adesão ao grupo, a aplicação UDP, o Neighbor PIM, RP SET, Multicast State, Rule ID e o percurso dos pacotes.

⚠️ A mudança de rotas Multicast estáticas para PIM-SM altera o caminho Multicast de produção. Por isso, é necessário documentar as rotas, os grupos e os Receivers existentes, bem como o plano de Rollback. A ajuda do SFOS 22 descreve separadamente o Static Multicast Forwarding e o PIM-SM, mas não indica uma regra geral de coexistência ou exclusão. Verifique o build efetivamente utilizado durante uma janela de manutenção, em vez de pressupor que ambos podem funcionar em paralelo.

Este artigo aborda IPv4-Multicast Routing dinâmico com um RP estático. O SFOS 22 suporta PIM versão 2 e PIM-SM; a Sophos documenta BSR para a seleção dinâmica de RP. O exemplo utiliza deliberadamente um RP estático. O Candidate RP e o BSR são apenas contextualizados mais adiante.

Quando o PIM-SM é a escolha certa

O PIM-SM é especialmente útil quando estão envolvidos vários routers Multicast, quando os Receivers se encontram em redes diferentes ou quando a pertença aos grupos muda com frequência. Os routers criam então State apenas onde existe um Sender ou um Receiver interessado.

Para um único Sender conhecido e poucas interfaces de saída permanentemente fixas, uma rota Multicast estática continua normalmente a ser mais simples. Não requer RP nem vizinhança PIM. O PIM-SM não é uma opção melhor para a mesma topologia pequena, mas sim um modelo operacional diferente.

Além disso, o PIM-SM não substitui o Unicast Routing nem as regras de firewall:

O Unicast Routing determina em que direção a Source e o RP estão acessíveis.
O PIM-SM utiliza essa informação para criar a árvore de distribuição Multicast entre routers.
O IGMP comunica na rede local dos Receivers quais os hosts que pretendem receber um grupo.
As regras de firewall permitem ou bloqueiam o fluxo de dados Multicast propriamente dito entre zonas.

Compreender IGMP, RP e RPF

Um Receiver envia na rede IPv4 local uma mensagem de pertença IGMP para o seu grupo. O último router Multicast traduz esse interesse num PIM Join em direção ao RP. O RP é o ponto de encontro comum através do qual Sender e Receiver se encontram inicialmente. Consoante o State criado, o caminho dos dados pode mais tarde mudar para uma Source Tree mais curta; por isso, o RP não tem de encaminhar permanentemente todos os pacotes de dados.

Na tabela Multicast, (*,G) representa o State comum de um grupo, independentemente de uma Source específica. (S,G) representa, por sua vez, o State de uma Source S concreta e de um grupo G. No exemplo, corresponde a (10.10.10.20, 239.10.10.10).

O mecanismo de controlo determinante chama-se Reverse Path Forwarding, abreviado como RPF. Para um pacote da Source 10.10.10.20, a firewall verifica através de que interface chegaria a essa Source segundo a tabela de routing. Se o fluxo Multicast entrar por outra interface, o caminho inverso não corresponde e o State ou o fluxo de dados pode falhar.

O PIM é independente do protocolo de Unicast Routing utilizado, mas não de rotas Unicast funcionais. As rotas estáticas, OSPF ou BGP podem fornecer o caminho RPF. Para o exemplo seguinte, são suficientes rotas Unicast estáticas; em domínios de routing maiores, o OSPF pode fornecer dinamicamente a mesma base.

Planear a topologia de exemplo

O exemplo liga um Sender atrás da Firewall A a um Receiver atrás da Firewall B:

Sender: 10.10.10.20
Rede da Source na Firewall A: 10.10.10.0/24, interface Port2, zona DMZ
Firewall A Transit: 10.255.0.1/30, interface Port4, zona PIM-Transit
Firewall B Transit: 10.255.0.2/30, interface Port4, zona PIM-Transit
Rede dos Receivers na Firewall B: 10.20.20.0/24, interface Port3, zona LAN
Test Receiver: 10.20.20.50
Grupo Multicast: 239.10.10.10
Application Service: UDP 5000
RP estático: 10.255.0.1
Intervalo de grupos do RP: 239.10.10.0/24

Os endereços são valores privados de exemplo. A Source, a rede dos Receivers, a rede de trânsito, o grupo e o serviço são substituídos em conjunto pelos valores da aplicação real. Neste exemplo, o RP 10.255.0.1 encontra-se na Firewall A e tem de estar acessível por Unicast a partir de todos os routers PIM.

O intervalo de grupos 239.10.10.0/24 é deliberadamente mais restrito do que *. Um asterisco atribui todos os grupos ao RP e só deve ser utilizado quando todo o domínio PIM estiver planeado dessa forma. A Sophos documenta um máximo de oito entradas de grupos ou redes por RP.

As rotas Unicast têm de estar operacionais antes da configuração PIM. A Firewall A recebe uma rota para 10.20.20.0/24 através de 10.255.0.2; a Firewall B recebe uma rota para 10.10.10.0/24 através de 10.255.0.1. Para RPF, é especialmente importante o caminho da Firewall B de regresso à Source. Por isso, uma consulta para 10.10.10.20 em Diagnostics > Tools > Route lookup tem de mostrar Port4 e o Next Hop esperado. Estas rotas Unicast não substituem a árvore de distribuição PIM.

A separação correta de interfaces e zonas para uma ligação de trânsito deste tipo é explicada em Configurar zonas e interfaces na Sophos Firewall.

Preparar o PIM-SM em segurança

Antes da janela de manutenção, devem ficar registados os seguintes pontos:

Os endereços IP de trânsito e as rotas Unicast foram testados em ambas as direções.
São conhecidos a Source, o grupo, a porta UDP e a aplicação do Receiver.
O RP estático e o respetivo intervalo de grupos estão documentados de forma idêntica para todos os routers.
As rotas Multicast estáticas existentes e Enable multicast forwarding estão inventariadas.
Estão disponíveis um backup da configuração e um acesso de gestão independente.
Os switches na rede dos Receivers só utilizam IGMP Snooping com uma função Querier definida e funcional.

A documentação atual da Sophos exige pelo menos uma interface PIM com um endereço IPv4. Indica como suportadas as interfaces físicas, RED e interfaces GRE; as interfaces Alias, PPPoE e Cellular WAN estão excluídas. Outros tipos de interface, como XFRM, não são confirmados de forma explícita na página PIM e, por isso, não devem ser utilizados sem testes nesta topologia de base.

Verificar o Dynamic Routing de forma específica

As mensagens PIM pertencem à Control Plane da firewall. A ajuda geral do SFOS agrupa os protocolos de routing em Administration > Device access > Dynamic Routing; no entanto, a página PIM atual não indica explicitamente esta dependência.

Se não for criada uma vizinhança PIM, verifica-se por isso se o Dynamic Routing tem de ser permitido na zona do Neighbor real. No exemplo, a zona própria PIM-Transit contém apenas a rede de trânsito entre as duas firewalls. Se esta autorização for necessária para a topologia, é ativada em ambos os dispositivos exclusivamente nessa zona.

A autorização na matriz aplica-se à zona inteira. Se existirem outras redes não fidedignas na mesma zona, a caixa permanece desativada e uma Local Service ACL Exception restrita permite Dynamic Routing apenas a partir dos Neighbors previstos. Uma Exception adicional não restringe uma autorização de zona já ativa.

Esta camada de Device Access destina-se ao tráfego de controlo do routing. Se a autorização para PIM for necessária no build utilizado, não se aplica ao fluxo encaminhado nem substitui a regra de firewall desse fluxo. As duas camadas de acesso são explicadas em Proteger o Device Access na Sophos Firewall.

Inventariar o Static Multicast Forwarding existente

Em Routing > Static routes, são documentadas as rotas Multicast existentes, as aplicações dependentes e as interfaces de destino. A ajuda do SFOS 22 não confirma se Enable multicast forwarding e PIM-SM podem ser configurados em paralelo em todos os builds. Por isso, o estado existente só deve ser alterado durante a janela de manutenção, registando-se a reação da interface.

Não eliminar preventivamente as rotas Multicast estáticas existentes. Estas permanecem como modelo de Rollback documentado até à validação completa do PIM-SM. Se o SFOS exigir que o forwarding estático seja desativado antes de ativar o PIM, esse passo faz parte da migração planeada e não constitui uma regra geral do produto aqui assumida sem confirmação.

Configurar PIM-SM

Os passos seguintes são executados na Firewall A e na Firewall B.

Ativar o PIM e as interfaces envolvidas

Abrir Routing > Multicast (PIM-SM).
Ativar Enable PIM.
Em PIM-enabled interface, selecionar apenas as interfaces IPv4 envolvidas no caminho Multicast:
- Firewall A: Port2 e Port4
- Firewall B: Port4 e Port3
Guardar. Só depois da configuração completa o Neighbor PIM, a atribuição do RP e o Multicast State mostram se a topologia funciona.

O PIM não é ativado indiscriminadamente em todas as interfaces LAN ou WAN. Cada interface adicional expande a Control Plane e pode permitir novos Neighbors ou caminhos Multicast.

Introduzir o RP estático e o intervalo de grupos

Em RP settings, a opção é ativada e é introduzida a mesma atribuição estática em ambas as firewalls:

RP IP: 10.255.0.1
Multicast group: 239.10.10.0/24

Para vários grupos, separar os endereços IP dos grupos Multicast ou os endereços de rede por vírgulas em Multicast group. O exemplo continua a utilizar uma única rede de âmbito restrito.

Não confundir o limite de endereços IP dos RP com o limite de grupos: A ajuda do SFOS 22 e SFOS 23 indica separadamente em RP IP: «Maximum eight RP IP addresses per RP are allowed.» A formulação permite, portanto, um máximo de oito endereços IP de RP «por RP», mas o âmbito de «por RP» permanece ambíguo. Isto não confirma de forma independente um máximo de oito RP para todo o dispositivo. Este exemplo utiliza um único RP. Antes de conceber uma configuração com vários RP, verificar o âmbito do limite para o build instalado ou esclarecê-lo com o Sophos Support.

O RP IP é um endereço Unicast. Na Firewall B, a tabela de routing Unicast tem de mostrar Port4 e 10.255.0.1 como caminho esperado; na Firewall A, o RP IP é o endereço de uma interface própria. Não basta guardar o valor: em Routing > Information > PIM-SM > RP SET, o grupo tem de estar efetivamente atribuído a este RP.

Guardar a configuração. Se o SFOS não permitir ativar o PIM, verificar a mensagem da interface e o estado atual de Enable multicast forwarding. Alterar esta opção apenas se a interface confirmar efetivamente o conflito no build utilizado e o caminho de reposição estiver documentado.

Quando o Candidate RP é adequado

O Candidate RP é adequado a um domínio PIM existente no qual a função BSR e o processo de seleção de RP já estão planeados. Os campos do SFOS têm o seguinte significado:

Candidate RP IP: O IP da interface selecionada é utilizado como IP do RP se o router for selecionado como Candidate RP.
Multicast group list: Até oito endereços IP de grupos Multicast ou endereços de rede a servir por este RP; separar as entradas múltiplas por vírgulas.
Candidate RP priority: Prioridade do router PIM na eleição do RP, de 1 a 255, com o valor predefinido 1.
Timer: Intervalo de geração das mensagens de candidatura a RP, de 30 a 180 segundos, com o valor predefinido 60.

A configuração de Candidate RP por si só não transforma automaticamente a firewall num BSR funcional nem garante a seleção de RP pretendida. A Sophos não documenta no WebAdmin uma configuração completa do Bootstrap Router. Por isso, o Candidate RP só é utilizado quando a função BSR é conhecida e o Group-to-RP Mapping resultante pode ser verificado em RP SET. Para este exemplo simples, o Static RP continua a ser mais fácil de acompanhar.

Criar regras de firewall para o fluxo de dados

A vizinhança PIM não fornece uma autorização de segurança geral. As regras gerais de firewall do SFOS controlam o tráfego entre zonas e redes. Por isso, o seguinte modelo de duas regras é uma configuração Avanet estritamente limitada a esta topologia, não um modelo PIM obrigatório documentado pela Sophos.

Na Firewall A, a configuração pretendida é a seguinte:

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: serviço UDP personalizado com Destination Port 5000
Action: Accept
Log firewall traffic: ativado

Na Firewall B, é criada uma segunda regra de PIM-Transit para LAN com a mesma Source, o mesmo grupo e o mesmo serviço UDP. Não está previsto SNAT para o teste, de modo a preservar a Source e (S,G).

As regras aplicam-se ao fluxo de dados Multicast. Os PIM-Hellos e as mensagens de pertença IGMP não são combinados com uma regra Any abrangente. No Packet Capture, avaliar em conjunto a Rule ID, o Status, a Reason e as interfaces de entrada e saída. A ajuda do SFOS 22 não documenta um significado geral para a Rule ID 0; por isso, este valor, por si só, não comprova que nenhuma regra correspondeu.

A configuração geral é explicada em Configurar regras de Sophos Firewall em segurança.

Validar o PIM-SM do Neighbor ao Receiver

Uma vizinhança PIM visível é apenas a primeira parte da validação:

Em Routing > Information > PIM-SM > Interface table, a outra firewall tem de aparecer como Neighbor na interface de trânsito.
Em RP SET, 239.10.10.0/24 tem de apontar para 10.255.0.1.
Em 10.20.20.50, iniciar a aplicação do Receiver. O sistema operativo tem de aderir ao grupo 239.10.10.10 e a aplicação tem ainda de escutar na porta UDP 5000.
Iniciar um fluxo de teste temporalmente limitado a partir de 10.10.10.20.
Em Multicasting routing table, procurar o State (*,G) ou (S,G) do grupo. Incoming e Outgoing Interfaces têm de corresponder à topologia; os PIM timers e os flag bits fornecem contexto de diagnóstico adicional.
No Log Viewer de ambas as firewalls, verificar a Rule ID esperada.
Em Diagnostics > Packet capture, verificar com o seguinte filtro BPF:
```
src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
```
O fluxo tem de entrar na Firewall A por Port2 e sair por Port4. Na Firewall B, é recebido em Port4 e encaminhado por Port3. Depois, verifica-se o conteúdo real no Receiver.

O procedimento de Packet Capture com interface, Rule ID, Status e Reason é descrito em Utilizar Packet Capture na Sophos Firewall.

Durante um teste limitado, também podem ser utilizados os seguintes filtros BPF para tráfego da Control Plane:

ip proto 103

103 representa PIM. O IGMP utiliza o protocolo IP 2:

ip proto 2

Os filtros mostram se existem pacotes PIM e IGMP. Por si só, não comprovam nem o RP correto nem um fluxo de dados funcional.

Na Advanced Shell, o pimd.log fornece contexto adicional. Os comandos seguintes são apenas de leitura:

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

Um resultado vazio de grep não comprova um erro; o State atual no WebAdmin e o percurso real dos pacotes continuam a ser determinantes. Outros ficheiros de routing e logs são explicados em Ficheiros de serviço e de log da Sophos Firewall.

Restringir o erro por sintoma

Não aparece nenhum PIM Neighbor

Verificar a acessibilidade direta dos endereços IP de trânsito 10.255.0.1 e 10.255.0.2.
Confirmar se Port4 está selecionado como PIM-enabled interface em ambas as firewalls.
Verificar Dynamic Routing na zona de trânsito correta ou na Local Service ACL Exception adequada.
Utilizar ip proto 103 para verificar se os pacotes PIM chegam à interface de trânsito e a abandonam.
Garantir que é utilizado um tipo de interface documentado pela Sophos para PIM.

O Neighbor existe, mas o RP SET está ausente ou incorreto

Comparar, caráter a caráter, o RP IP e o intervalo de grupos em todos os routers.
Verificar a acessibilidade Unicast de 10.255.0.1.
No caso de Candidate RP, esclarecer primeiro a função BSR efetiva. Uma candidatura configurada, por si só, não é suficiente.
Não alargar para * antes de compreender por que razão o grupo específico não é atribuído.

O RP SET está correto, mas não é criado nenhum Multicast State

Verificar se o sistema operativo do Receiver aderiu ao grupo correto e se a aplicação escuta na porta UDP 5000.
Utilizar ip proto 2 para procurar IGMP Reports e Queries na rede dos Receivers.
Com IGMP Snooping, verificar a função Querier na VLAN. Não alterar os temporizadores IGMP por tentativa; o procedimento de base não requer qualquer alteração dos temporizadores.
Verificar se o Sender envia efetivamente para 239.10.10.10:5000.

Existe State, mas a Incoming Interface está incorreta

Em cada firewall, executar um Route Lookup para a Source 10.10.10.20 e o RP 10.255.0.1.
Verificar se existem rotas estáticas, OSPF, SD-WAN ou VPN com um caminho inesperadamente melhor.
Não alterar a Route Precedence global antes de comprovar o caminho RPF incorreto com a tabela de routing e um Capture.
Documentar separadamente caminhos de retorno assimétricos e ligações paralelas.

O fluxo abandona a firewall, mas não chega ao Receiver

Verificar a Rule ID, o Status e a Outgoing Interface em ambas as firewalls.
Verificar a porta do switch, a VLAN e o IGMP Snooping na rede dos Receivers.
Verificar a firewall local do host e a aplicação do Receiver.
Comparar um Capture no Receiver ou na porta do switch com os timestamps do SFOS.

Considerar os limites de HA e das interfaces

Em Active-Active HA, o Multicast não é distribuído entre ambos os nodes. As sessões UDP, Broadcast e Multicast não são assumidas durante o Failover. Uma mudança controlada de funções pode, por isso, interromper o fluxo; em seguida, voltam a verificar-se Neighbor, RP SET, RPF, Multicast State, regras e Receiver.

Os logs e os reports não são sincronizados entre os nodes HA. Em caso de problema de HA, devem ser salvaguardados os dados do node que processava o tráfego antes da mudança. A ajuda oficial de HA não documenta uma transferência de State específica do PIM; o artigo não deduz daí qualquer afirmação mais abrangente sobre sincronização.

Este artigo de base utiliza interfaces físicas. A Sophos também indica RED e GRE como compatíveis com PIM. Isto não confirma PIM diretamente em interfaces XFRM, IPsec ou SSL VPN. Um desenho Multicast encriptado ou dependente do operador requer, por isso, uma arquitetura separada e testada.

Repor a configuração em segurança

A reposição é efetuada durante a janela de manutenção:

Terminar o fluxo de teste e documentar o último State funcional ou com erro.
Desativar as novas regras de firewall Multicast.
Desativar o PIM em ambas as firewalls.
Remover Dynamic Routing da zona de trânsito apenas se nenhum outro protocolo de routing depender desta definição.
Se o Static Multicast Forwarding tiver sido desativado durante a migração, repor o estado anterior documentado juntamente com as respetivas rotas.
Voltar a verificar o acesso de gestão, as rotas Unicast e as aplicações anteriormente em produção.

Esta reposição não requer reinícios do serviço PIM, opções de Debug nem comandos não documentados da Advanced Shell.

Perguntas frequentes

O PIM-SM substitui o IGMP ou a regra de firewall?

Não. O IGMP comunica o interesse dos Receivers na rede local, o PIM-SM liga os routers Multicast envolvidos e a regra de firewall permite o fluxo de dados específico entre zonas. As três camadas têm de corresponder ao mesmo desenho.

Por que razão uma rota Unicast influencia o caminho Multicast?

O PIM-SM utiliza RPF. Com base nas informações de routing, a firewall verifica através de que interface a Source ou o RP estariam acessíveis. Se a rota apontar para a interface errada, o caminho inverso esperado não corresponde e o Multicast State pode ficar incorreto ou incompleto.