Saltar para o conteudo
Avanet

Configurar e testar Multicast na Sophos Firewall com uma rota estática

Uma rota Multicast estática encaminha o fluxo de dados de um emissor conhecido para um grupo Multicast fixo através das interfaces selecionadas. É adequada, por exemplo, para um fluxo de vídeo, áudio ou telemetria cuja Source, grupo e redes dos Receivers permanecem fixos.

Este procedimento aborda IPv4-Multicast Routing estático. IPv6-Multicast não faz parte deste guia.

O procedimento resumido é o seguinte:

  1. Documentar o Source-IP, o grupo Multicast, a porta UDP e as interfaces de entrada e saída.
  2. Em Routing > Static routes, ativar Enable multicast forwarding.
  3. Em Manage multicast route > Add, introduzir a Source, o grupo e as interfaces.
  4. Fazer com que um Receiver real adira ao grupo e iniciar o fluxo.
  5. Verificar a rota, bem como a entrada e a saída, com mroute show e Packet Capture.

⚠️ Enable multicast forwarding é uma definição global. Antes de a ativar, devem ser inventariadas as configurações PIM-SM existentes, as rotas Multicast estáticas e os fluxos dependentes. A alteração é testada primeiro com um fluxo de teste limitado; se ocorrer um comportamento inesperado, é revertida antes de serem adicionadas outras Destination Interfaces.

Compreender Multicast, IGMP e a rota estática

Com Unicast, um host envia dados para um único endereço de destino. Com Multicast, a Source envia uma vez para um endereço de grupo e vários Receivers podem subscrever o mesmo fluxo. A firewall não copia o fluxo para redes arbitrárias, mas apenas para as Destination Interfaces introduzidas na rota Multicast.

O exemplo utiliza a combinação fixa do emissor 10.10.10.20 com o grupo 239.10.10.10. Esta combinação é frequentemente designada por Source e Group, abreviadamente (S,G). Se a aplicação alterar o Source-IP ou o grupo, a rota deixa de corresponder.

O IGMP comunica no segmento IPv4 local que um Receiver pretende aderir a um grupo Multicast ou abandoná-lo. Com IGMP Snooping, um switch pode encaminhar o fluxo apenas para as portas com recetores interessados. No entanto, a rota estática da Sophos não aprende novas Destination Interfaces através deste processo: Port3 permanece configurada de forma fixa, mesmo que nenhum Receiver esteja a escutar nesse momento.

O PIM-SM desempenha outra função. Cria dinamicamente caminhos Multicast entre vários routers Multicast e requer um desenho planeado de Rendezvous Point e Unicast Routing. Para um único emissor conhecido e poucas interfaces de Receiver fixas, a rota estática é normalmente mais simples. Com vários routers, grupos variáveis ou muitos caminhos Multicast, o PIM-SM requer um desenho separado.

Uma rota Multicast estática também não é uma rota Unicast estática normal. Não utiliza um Next Hop clássico e aparece numa secção separada.

mDNS é um caso de utilização diferente

O mDNS utilizado pelo Bonjour, AirPlay e muitas pesquisas do Chromecast usa o endereço link-local 224.0.0.251. A Sophos permite grupos de 224.0.2.0 a 239.255.255.255 na rota Multicast estática; o mDNS está fora desse intervalo e não é encaminhado pelos routers como tráfego Multicast normal.

Por isso, este guia não substitui um mDNS Reflector nem um Discovery Gateway. Um fluxo multimédia pode funcionar através de Multicast enquanto a deteção automática de dispositivos entre VLANs continua sem funcionar.

Planear a topologia de exemplo

O exemplo utiliza os seguintes valores:

  • 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 e 10.20.20.0/24 são valores privados de exemplo. 239.10.10.10 pertence ao intervalo Multicast de âmbito administrativo e é adequado para um exemplo local controlado. No ambiente real, a Source, o grupo, a porta e as interfaces são substituídos em conjunto pelos valores da aplicação e da topologia. O grupo não pode ser alterado arbitrariamente: Sender e Receiver têm de utilizar o mesmo endereço e o mesmo serviço.

A aplicação também tem de enviar com uma TTL suficiente. No encaminhamento normal, a TTL é reduzida em uma unidade a cada salto. Se a aplicação enviar com TTL 1, o fluxo não alcança outro segmento enquanto a redução da TTL estiver ativa.

Antes da alteração, devem estar definidos os seguintes pontos:

  • A firewall funciona em Gateway Mode.
  • O Sender alcança Port2 e os Receivers estão atrás de Port3.
  • A aplicação do Receiver consegue efetivamente aderir ao grupo 239.10.10.10 na porta UDP 5000.
  • As configurações PIM-SM existentes, outras rotas Multicast e respetivas dependências estão documentadas.
  • São conhecidos os switches, as VLANs e as definições de IGMP Snooping na rede do Receiver.
  • Estão disponíveis um backup da configuração e um acesso de gestão independente.

A relação entre interfaces, VLANs e zonas é explicada em Configurar zonas e interfaces na Sophos Firewall.

Criar a rota Multicast estática

Ativar Multicast Forwarding

  1. No WebAdmin, abrir Routing > Static routes.
  2. Em Multicast forwarding setting, selecionar Enable multicast forwarding.
  3. Clicar em Apply e depois em OK.

Se não for possível ativar a opção, deve verificar-se a configuração Multicast existente. Uma configuração PIM-SM existente não deve ser alterada de forma improvisada: a ajuda atual do SFOS 22 não documenta, nas páginas relevantes, uma regra geral de coexistência, pelo que prevalecem o comportamento da build instalada e o desenho de rede aprovado.

Introduzir Source, grupo e interfaces

  1. Em Manage multicast route, clicar em Add.
  2. Em Source IPv4 address, introduzir 10.10.10.20.
  3. Selecionar Port2 como Source interface.
  4. Em Multicast IPv4 address, introduzir 239.10.10.10.
  5. Selecionar Port3 como Destination interface.
  6. Guardar com Save.

O WebAdmin pode guardar várias Destination Interfaces numa rota. No entanto, cada interface adicional aumenta a área para a qual o fluxo é encaminhado. Só deve ser selecionada se existirem Receivers nessa rede e se a autorização de segurança também for adequada. Source e Destination Interface não podem ser idênticas.

Utilizar a CLI como caminho alternativo controlado

Na Device Console, o caminho é 3. Route Configuration > 2. Configure Multicast Routing. Multicast Forwarding tem de estar ativo antes de adicionar a primeira rota. Pode ser ativado em Gateway Mode e Transparent Mode, mas as rotas Multicast estáticas só podem ser configuradas em Gateway Mode. Na opção 1, este comando ativa o encaminhamento global:

enable multicast-forwarding

⚠️ Segundo a Sophos, comandos incompletos na Device Console podem fazer com que o access_server deixe de responder. Por isso, complete a sintaxe com ? ou Tab de acordo com a build instalada e só depois execute o comando completo.

Em 2. Configure Static-routes, é possível adicionar uma rota entre duas interfaces estáticas e verificá-la imediatamente:

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

A CLI requer uma entrada mroute add separada para cada interface de saída. Só disponibiliza interfaces estáticas, enquanto o WebAdmin também pode apresentar interfaces dinâmicas, como DHCP e PPPoE. As interfaces de entrada e saída têm de ser diferentes; uma interface não Ethernet, como IPsec0, não pertence a esta forma baseada em portas.

Para remover de forma específica uma rota física, a Sophos indica os valores por posição. Primeiro, confirmar os nomes das interfaces com mroute show:

mroute del Port2 10.10.10.20 239.10.10.10 Port3
mroute show

A Sophos publica formas input-tunnel e output-tunnel separadas para rotas IPsec e GRE, mas os exemplos não usam sempre a mesma grafia. A conclusão de comandos da versão SFOS instalada é a referência; não deve ser colado um exemplo público sem verificação.

Não pressupor a autorização de segurança

O guia oficial do SFOS 22 para criar uma rota Multicast estática não menciona uma regra adicional de firewall ou NAT. Por isso, neste exemplo não se cria preventivamente uma regra Any abrangente. Se a build instalada ou uma policy existente exigir, ainda assim, um Match adicional, isso é verificado no Packet Capture através do estado real do pacote.

Se a firewall indicar um Drop causado por uma policy, não se deve adivinhar a solução: primeiro, registam-se a Source 10.10.10.20, o grupo 239.10.10.10, UDP 5000, as zonas envolvidas e o contexto de regra apresentado. Só após confirmação para a build utilizada é criada uma autorização limitada exatamente a estes valores e com registo ativado. A estrutura geral das regras é explicada em Configurar regras da Sophos Firewall de forma segura.

Testar o fluxo de dados de forma controlada

Uma rota guardada ainda não demonstra que o Receiver recebe o fluxo. O teste de aceitação acompanha o pacote desde a aplicação até ao cliente:

  1. Em 10.20.20.50, iniciar a aplicação do Receiver e aderir ao grupo 239.10.10.10 na porta UDP 5000.

  2. Iniciar um fluxo de teste claramente limitado a partir de 10.10.10.20 e registar a hora e a duração esperada.

  3. Em Diagnostics > Packet capture, filtrar com esta expressão BPF:

    src host 10.10.10.20 and dst host 239.10.10.10 and udp port 5000
    
  4. Na lista de pacotes, confirmar se o fluxo entra em Port2 e aparece em Port3 com o Status Forwarded. Em caso de Drop, registar o Status apresentado e o contexto da regra, sem alargar uma regra com base em suposições.

  5. No Receiver, confirmar se os pacotes chegam e a aplicação processa o conteúdo.

O procedimento de Packet Capture com interface, contexto da regra e Status é explicado em Utilizar Packet Capture na Sophos Firewall.

Na Device Console, a tabela de Static Multicast Routing também pode ser consultada em modo read-only. O caminho passa por 3. Route Configuration > 2. Configure Multicast Routing > 2. Configure Static-routes:

mroute show

O resultado tem de apresentar a Source, o grupo e as interfaces de entrada e saída esperados. O comando não altera a configuração.

Para Troubleshooting mais aprofundado, a documentação atual do SFOS 22 indica mrouting.log. Na Advanced Shell, são apenas lidas as entradas mais recentes:

tail -n 200 /log/mrouting.log

Outros ficheiros e associações de serviços estão descritos em Ficheiros de serviço e de log da Sophos Firewall.

Restringir o erro de acordo com o sintoma

Não é possível ativar ou guardar a rota

  • Verificar o Source-IP, o intervalo do grupo e as interfaces. São permitidos grupos de 224.0.2.0 a 239.255.255.255.
  • Source e Destination Interface não podem ser idênticas.
  • Se já existir uma combinação (S,G), comparar também a Destination Interface. Para várias saídas, a CLI exige uma entrada própria com a mesma Source e o mesmo grupo para cada uma.

O fluxo entra, mas não é encaminhado

  • O Source-IP e o grupo reais correspondem exatamente à rota?
  • mroute show apresenta as interfaces esperadas?
  • A Capture apresenta Forwarded ou um Drop com um contexto de regra utilizável?
  • Port3 foi realmente selecionada como Destination Interface?

O fluxo sai da firewall, mas não chega ao Receiver

  • Verificar a TTL do Sender. Não alterar parâmetros globais de routing com base numa suposição.
  • Verificar a VLAN, a Switchport e o IGMP Snooping na rede do Receiver.
  • Confirmar que 10.20.20.50 aderiu ao grupo e à porta UDP corretos.
  • Verificar a firewall local do host e a aplicação no Receiver.
  • Comparar uma Capture no Receiver ou na Switchport com os timestamps do SFOS.

A deteção de dispositivos não funciona, mas o fluxo funciona

Protocolos de Discovery como o mDNS são link-local e não são refletidos por esta rota estática. O fluxo de dados real e a deteção de dispositivos devem ser verificados separadamente.

Tratar VPN e HA separadamente

O Multicast através de SSL VPN não é suportado pela Sophos. As rotas Multicast estáticas através de IPsec ou de um túnel GRE previamente validado são possíveis e utilizam formas CLI próprias. Para IPsec, a Sophos também exige um host Unicast explícito com /32 na configuração VPN. Os exemplos documentados publicamente contêm várias grafias inconsistentes, pelo que não devem ser aplicados sem verificação como comandos Copy-and-paste numa firewall de produção.

Para Multicast através de um túnel VPN, a versão do firmware também é importante. Os crashes repetidos da firewall relacionados temporalmente com este tráfego são tratados em IPsec Troubleshooting para NC-180433. O erro foi corrigido no SFOS 22.0 MR2 Build 546; uma perda de pacotes normal ou um fluxo em falta não comprova este caso específico.

Em HA Active-Active, o Multicast não é distribuído entre os dois Nodes. Além disso, a Sophos exclui o Multicast do Session Failover. Por isso, deve contar-se com uma interrupção do fluxo quando os papéis mudam. Antes do Failover, guardam-se a Capture e os timestamps no Node anteriormente ativo; depois, verificam-se novamente a rota, a entrada, a saída e o Receiver no novo Node ativo.

Reverter de forma segura

Antes da reversão, documentar a rota, as interfaces e os valores de teste utilizados. Em seguida:

  1. Parar o fluxo de teste.
  2. Remover a rota Multicast estática no WebAdmin.
  3. Desativar Enable multicast forwarding apenas se nenhuma outra rota Multicast estática depender desta opção.
  4. Voltar a verificar o estado anterior das aplicações e redes afetadas.

Se a rota de exemplo tiver sido criada através da CLI, pode ser removida com o comando mroute del apresentado acima, oficialmente documentado para interfaces físicas, e verificada com mroute show. Para rotas de túnel, não é utilizado qualquer exemplo de eliminação que não esteja confirmado.

Perguntas frequentes

Quando é que uma rota Multicast estática é melhor do que PIM-SM?

Quando o Sender, o grupo e poucas Destination Interfaces permanecem fixos, a rota estática é normalmente mais simples. O PIM-SM é indicado para vários routers Multicast, caminhos dinâmicos e muitos grupos variáveis.