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.
Salvaguardar as rotas Multicast estáticas existentes e desativar Enable multicast forwarding de forma controlada.
Verificar o Device Access nas zonas com Neighbors PIM reais e permitir Dynamic Routing de forma específica apenas quando necessário.
Em Routing > Multicast (PIM-SM), ativar o PIM nas interfaces IPv4 envolvidas.
Introduzir o mesmo RP estático e o mesmo intervalo de grupos em todos os routers PIM.
Autorizar o fluxo de dados Multicast com regras de firewall IPv4 restritas e com registo.
Verificar em conjunto o Receiver Join, Neighbor, RP SET, Multicast State, Rule ID e o percurso dos pacotes.

⚠️ O PIM-SM e o Static Multicast Forwarding não podem ser configurados simultaneamente na Sophos Firewall. A mudança altera o caminho Multicast de produção. As rotas, os grupos, os Receivers e um caminho de retorno existentes têm de ser documentados antecipadamente.

Este artigo aborda IPv4-Multicast Routing dinâmico com um RP estático. Um Bootstrap Router, abreviado como BSR, distribui num domínio PIM a informação sobre o RP responsável por cada grupo. O Candidate RP é enquadrado mais adiante, mas não é tratado como uma suposta solução automática de Bootstrap Router.

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 menciona interfaces físicas, RED e interfaces GRE para PIM. As interfaces Alias, PPPoE e Cellular WAN estão excluídas. Outros tipos de interface, como XFRM, não são confirmados de forma positiva na página PIM e, por isso, não devem ser incluídos sem verificação 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.

Substituir o Static Multicast Forwarding de forma controlada

Em Routing > Static routes, são documentadas as rotas Multicast existentes, as aplicações dependentes e as interfaces de destino. Enable multicast forwarding só é desativado durante a janela de manutenção. Em seguida, pode ativar-se o PIM-SM.

Não eliminar preventivamente as rotas Multicast estáticas existentes. Estas permanecem como modelo de Rollback documentado até à validação completa do PIM-SM.

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
Não considerar ainda a alteração como bem-sucedida; Neighbor e State só são verificados após a configuração completa do RP.

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

O RP IP é um endereço Unicast. Tem de estar acessível a partir de ambas as firewalls através do caminho PIM previsto. Não basta guardar o valor: em Routing > Information > PIM-SM > RP SET, o grupo tem de estar efetivamente atribuído a este RP.

Em seguida, guardar a configuração. Se não for possível ativar o PIM, verificar primeiro se Enable multicast forwarding continua ativo.

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. Para isso, o SFOS disponibiliza um endereço IP de interface como Candidate RP IP, uma lista de grupos, uma prioridade de 1 a 255 e um Advertisement Interval de 30 a 180 segundos.

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. O fluxo necessita, em cada router, de uma regra de firewall IPv4 restrita para a respetiva passagem entre zonas.

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. A correspondência do objeto de grupo no build utilizado é verificada através da Rule ID. Se aparecer Rule 0, a regra não é alargada de forma descontrolada; em vez disso, analisa-se o percurso dos pacotes.

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 e aderir a 239.10.10.10 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.
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 Receiver aderiu realmente ao grupo e à porta UDP corretos.
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 são locais a cada node. Em caso de problema de HA, são salvaguardados os dados do node que estava ativo antes da mudança. Não se pressupõe uma sincronização sem interrupções do PIM State.

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.
Reativar o Static Multicast Forwarding apenas se o estado anterior e as respetivas rotas estiverem completamente documentados.
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.