Sophos Firewall: mDNS Reflector para deteção de dispositivos entre VLANs

O mDNS Reflector no SFOS 23 permite detetar dispositivos entre redes internas e VLANs selecionadas. Assim, por exemplo, um cliente pode encontrar um recetor AirPlay noutra VLAN. O Reflector transmite pedidos de pesquisa e anúncios de serviços, mas não permite automaticamente o tráfego de aplicação subsequente. A autorização para streaming, impressão ou acesso remoto é planeada e verificada separadamente.

O procedimento resumido: em Network > mDNS, ativar mDNS reflector, selecionar de forma específica IP version, Allowed interfaces e Services e aplicar com Apply. Em seguida, testar separadamente a descoberta, a utilização efetiva e os limites de rede que continuam bloqueados.

Este guia descreve a interface do SFOS 23. Um guia existente do SFOS 22 para routing Multicast estático continua a corresponder a um procedimento diferente; não substitui um Reflector. A disponibilidade de documentação, por si só, não comprova o estado de disponibilização nem a adequação de uma determinada build de firmware.

Distinguir a descoberta da utilização

O mDNS, ou Multicast DNS, é utilizado em conjunto com o DNS-SD para a descoberta local de serviços. Bonjour é a designação da Apple para os respetivos serviços de configuração automática. Em sub-redes separadas, esta pesquisa fica normalmente limitada ao respetivo segmento. O Reflector liga a camada de descoberta das interfaces explicitamente selecionadas, sem transformar as redes numa VLAN comum.

Isto tem duas consequências distintas:

• Um dispositivo pode tornar-se visível mesmo que a ligação ao seu serviço continue bloqueada. A visibilidade não comprova a existência de uma regra de firewall adequada nem o funcionamento do streaming.
• As redes selecionadas recebem informações adicionais sobre os serviços disponibilizados. Mesmo com o tráfego de aplicação bloqueado, esta visibilidade pode ser indesejada, por exemplo, entre uma rede de convidados e uma rede de gestão.

Por isso, Allowed interfaces constitui um limite de segurança, e não apenas uma seleção técnica. A caixa de diálogo define as interfaces participantes, não um par direcionado de origem e destino. Não se deve assumir que apenas os clientes de uma VLAN passam a ver os dispositivos da outra. Services limita as categorias de serviços refletidas; no entanto, uma categoria não autoriza todos os hosts nem todas as portas de uma aplicação.

As interfaces WAN e VPN não são suportadas. Esta definição não integra automaticamente um cliente VPN remoto na descoberta local. Também não passa a ser suportado outro protocolo de pesquisa apenas porque uma aplicação utiliza adicionalmente mDNS.

Pré-requisitos e exemplo limitado

Antes da alteração, são necessários:

• Uma build do SFOS 23 com Network > mDNS, acesso ao WebAdmin e um acesso de gestão independente.
• Interfaces internas já configuradas, com VLANs e redes corretamente associadas. As zonas e interfaces têm de corresponder à topologia real.
• Um cliente e um dispositivo conhecido que disponibilize o serviço, cuja pesquisa mDNS já funcione no mesmo segmento.
• Uma decisão sobre as categorias de serviços que podem ficar visíveis entre segmentos e as portas de aplicação necessárias, de acordo com a aplicação e a versão do dispositivo utilizadas.
• Um backup da configuração e um registo do estado anterior do Reflector, da versão IP, das interfaces, das categorias e das regras de aplicação existentes.

Para um teste AirPlay limitado, utilizam-se, por exemplo:

• Cliente 10.20.20.50 na VLAN de colaboradores 10.20.20.0/24, interface de firewall Port2.20, zona LAN.
• Recetor 10.30.30.20 na VLAN multimédia 10.30.30.0/24, interface de firewall Port2.30, zona própria MEDIA.
• IP version: IPv4, porque este teste utiliza exclusivamente IPv4.
• Allowed interfaces: apenas Port2.20 e Port2.30.
• Services: apenas AirPlay.

Os endereços, IDs de VLAN, nomes de interfaces e a zona de exemplo MEDIA são substituídos pelos valores da configuração real. O Reflector seleciona interfaces, não estes dois hosts individuais: outros dispositivos nas interfaces envolvidas também podem participar na descoberta dentro das categorias selecionadas. Um limite de confiança mais restrito exige um desenho de segmentação adequado, e não apenas regras de aplicação mais restritas.

As interfaces de convidados, de gestão e outras interfaces não envolvidas permanecem excluídas neste exemplo. Um primeiro teste bem-sucedido com duas interfaces é mais esclarecedor do que uma autorização abrangente em que se torna difícil relacionar causas e efeitos.

Configurar o mDNS Reflector

Guardar o estado anterior e selecionar a versão IP

1. No WebAdmin, abrir Network > mDNS e registar as definições existentes. Um Reflector desativado pode conservar uma configuração anterior; por isso, verificar também a seleção guardada antes de o ativar.
2. Ativar mDNS reflector. O estado predefinido documentado é Off.
3. Em IP version, selecionar a opção efetivamente necessária: IPv4 reflete apenas mDNS sobre IPv4, IPv6 apenas mDNS sobre IPv6 e Dual ambas as versões.

No exemplo, mantém-se IPv4. Dual não é uma opção genérica de correção: alarga a descoberta às duas versões IP. Se forem utilizados serviços IPv6 mais tarde, a acessibilidade e as regras de aplicação para IPv6 também têm de ser planeadas de forma deliberada e verificadas separadamente.

Limitar as interfaces e as categorias de serviços

1. Em Allowed interfaces, selecionar Port2.20 e Port2.30. Apenas as interfaces selecionadas participam nos pedidos de pesquisa e anúncios refletidos; são suportadas, no máximo, 16 interfaces.
2. Em Services, selecionar AirPlay.
3. Antes de aplicar, verificar que nenhuma interface de convidados, WAN, VPN ou de gestão foi incluída por engano na seleção planeada.
4. Clicar em Apply. A firewall reflete imediatamente o tráfego de descoberta suportado entre as interfaces selecionadas.

Além de AirPlay, estão disponíveis AirDrop, Apple File Share, Chromecast, IoT Smart Home, Printer, Remote Desktop, Scanner, Sonos e Spotify Connect. A seleção é ajustada às necessidades reais. Uma categoria de serviço não dispensa a verificação de outros pré-requisitos da aplicação concreta além da descoberta.

⚠️ Any processa todas as categorias de serviços mDNS, incluindo as que não estão listadas individualmente. Isto pode gerar tráfego de rede adicional e afetar o desempenho do sistema. Também alarga os serviços visíveis. Não mudar para Any apenas porque falta um dispositivo; verificar primeiro a respetiva descoberta e a categoria adequada.

Autorizar o tráfego de aplicação separadamente

Para a utilização posterior, cria-se uma regra de firewall específica ou verifica-se uma regra já adequada. No teste, o nome da regra é, por exemplo, AirPlay-Test-Client-zu-Media, a origem é o host 10.20.20.50 em LAN e o destino é o host 10.30.30.20 em MEDIA. Os serviços correspondem às portas TCP/UDP confirmadas para este dispositivo e esta aplicação; o registo é ativado para o teste de aceitação.

Não se fornece aqui, deliberadamente, uma lista universal de portas AirPlay para copiar. As funções do dispositivo e as direções de ligação necessárias têm de estar definidas antes da autorização. A ausência de informação do fabricante não é compensada com Any. Se a aplicação também necessitar de uma ligação iniciada pelo dispositivo que disponibiliza o serviço, essa ligação é justificada separadamente e autorizada de forma restrita. A resposta normal a uma ligação existente não justifica automaticamente uma regra abrangente no sentido inverso.

Também não faz sentido criar, com base numa suposição, uma autorização UDP genérica como substituto da configuração do Reflector. A seleção de descoberta e a regra de aplicação cumprem funções diferentes. As alterações ficam limitadas ao teste documentado; outras regras, o NAT e as rotas Multicast não são alterados incidentalmente.

Comprovar o sucesso em três verificações separadas

1. Descoberta nas interfaces selecionadas

Após Apply, voltar a confirmar a versão IP, a seleção de interfaces e as categorias guardadas. Em seguida, reiniciar a pesquisa de dispositivos da aplicação no cliente de teste. Espera-se encontrar o recetor conhecido da VLAN multimédia, e não apenas uma entrada de uma pesquisa anterior.

Se o resultado não for claro, iniciar uma captura curta, com duração limitada, em Diagnostics > Packet capture. Um filtro BPF adequado para mDNS é:

udp port 5353

O filtro é apenas um auxílio de observação e não altera autorizações. No teste IPv4, espera-se tráfego mDNS com o endereço Multicast local 224.0.0.251. Comparam-se a interface e os timestamps: a pesquisa é gerada na rede do cliente e o tráfego de descoberta correspondente também é visível na interface multimédia selecionada? O conteúdo dos pacotes e uma captura no cliente ajudam a verificar se o serviço esperado está efetivamente a ser anunciado. Um único pacote ou um determinado estado de pacote, por si só, não comprova uma pesquisa bem-sucedida. O procedimento é explicado em Packet Capture na Sophos Firewall.

2. Utilizar o serviço efetivo

Selecionar o recetor detetado e iniciar um breve teste AirPlay. O sucesso significa que a função pretendida funciona no recetor, e não apenas que o seu nome aparece. No log da regra ou numa captura separada do par de hosts 10.20.20.50 e 10.30.30.20, verificar o endereço de destino, as portas, a direção da ligação e a regra correspondente.

Se a descoberta funcionar, mas a utilização não, a seleção do Reflector mantém-se inicialmente inalterada. Verificam-se agora as regras de aplicação, as portas efetivas, o routing, as firewalls locais dos dispositivos e a própria aplicação. Um Reflector mais abrangente não corrige um serviço de aplicação bloqueado.

3. Verificar os limites não autorizados

Com uma nova pesquisa num segmento de teste excluído, verificar que o serviço não se torna visível através deste Reflector. Testar também que as ligações não autorizadas continuam bloqueadas. As caches existentes e outros Discovery Gateways podem distorcer o resultado; uma indicação sem novo tráfego de rede correspondente não é prova suficiente de uma reflexão indesejada.

Em HA, as definições do Reflector são sincronizadas entre os dispositivos. A função do SFOS 23 também suporta descoberta em caso de Failover. Isto não constitui uma garantia de sessões de aplicação sem interrupções. Utiliza-se um teste HA já planeado para voltar a verificar a descoberta e a utilização após a mudança de papéis; não se provoca um Failover em produção apenas para seguir este guia.

Isolar os erros de forma específica

Network > mDNS não está disponível ou falta uma interface

Verificar a versão SFOS instalada e a configuração real das interfaces. Este guia pressupõe a interface do SFOS 23. As interfaces WAN e VPN estão excluídas. Uma interface interna em falta ou uma seleção que não possa ser guardada é documentada com a build, o tipo de interface e a mensagem exata; o limite de 16 interfaces não pode ser excedido. Não contornar a limitação com uma rota Multicast estática nem com uma alteração não documentada na Shell.

O serviço não é encontrado

Verificar primeiro, no segmento local do dispositivo que disponibiliza o serviço, se a respetiva descoberta funciona. Se já falhar nesse segmento, os próximos elementos a investigar são o dispositivo, a aplicação, o isolamento de clientes WLAN ou os filtros de rede locais, e não o Reflector. Se funcionar localmente, verificar a versão IP, as duas interfaces selecionadas, a categoria de serviço e o resultado efetivamente guardado após Apply.

Em seguida, comparar as capturas mDNS curtas dos dois lados. Se o pedido de pesquisa já estiver ausente na interface do cliente, verificar o cliente e o caminho de rede. Se o pedido estiver presente, mas não houver um anúncio de serviço correspondente, investigar o dispositivo que disponibiliza o serviço. Se existir um anúncio adequado, mas a descoberta não funcionar no cliente, verificar o caminho de rede de regresso ao cliente. As alterações são efetuadas individualmente e, após cada uma, repete-se o mesmo teste.

O serviço está visível, mas não funciona

Capturar o tráfego de aplicação separadamente e investigar um Drop com base nos hosts, nas portas e no contexto da regra. Complementar a autorização apenas com valores comprovadamente necessários, sem abrir todos os serviços entre as duas VLANs. Um endereço anunciado que não seja acessível a partir do cliente também pode impedir a utilização; verificar o endereço de destino efetivo e o respetivo caminho de routing.

Aparecem demasiados serviços ou carga adicional

Verificar se Services está definido como Any, se existem categorias indesejadas e se Allowed interfaces inclui segmentos adicionais. Reverter uma ampliação involuntária para o estado anterior registado. Se a perturbação tiver começado imediatamente após a ativação, desativar o Reflector de forma controlada e repetir o mesmo teste limitado. Não introduzir reinícios de serviços nem Reflectors adicionais com base em suposições.

Se o problema persistir, guardar para escalamento a build, a versão IP, as interfaces envolvidas, as categorias, os endereços de hosts anonimizados, os timestamps e capturas curtas dos dois lados. Os dados de clientes e os conteúdos desnecessários dos pacotes não devem ser incluídos num exemplo público de suporte.

Reverter de forma segura

1. Terminar o teste e documentar o resultado e as últimas definições guardadas.
2. Se o Reflector estava anteriormente desativado, voltar a desativá-lo em Network > mDNS e aplicar com Apply. Se já estava ativo, restaurar e aplicar a versão IP e as seleções de interfaces e categorias anteriormente registadas; não desativar indiscriminadamente outros serviços dependentes.
3. Desativar apenas a regra de aplicação adicionada para este teste ou reverter a alteração documentada numa regra existente.
4. Voltar a abrir as definições e verificar a descoberta, os serviços anteriores e as ligações que continuam bloqueadas, utilizando uma nova pesquisa.

Ao desativar, a configuração do Reflector é mantida; ao reativar, a seleção anterior volta a ser utilizada. Por isso, desativar não elimina os limites de confiança guardados. Antes de qualquer reativação posterior, voltar a verificar as interfaces e as categorias. As entradas de descoberta já existentes no cliente podem continuar a ser apresentadas após a reversão, e uma aplicação já em execução não comprova que a nova descoberta continue a ser refletida.