Verificar a cache de vizinhos ARP e NDP na Sophos Firewall
Se um dispositivo não estiver acessível apesar de ter o endereço IP correto, a causa não tem de ser imediatamente uma regra de firewall ou uma rota incorreta. Na rede local, a Sophos Firewall também precisa do endereço MAC correto do destino. Esta associação é guardada na cache de vizinhos.
Em Network > Neighbors (ARP–NDP) é possível verificar que endereço IP está atualmente associado a cada endereço MAC e interface. Primeiro, documenta-se a entrada existente e compara-se com a situação real da rede. Só quando a associação está desatualizada se limpa a cache afetada e se permite que seja aprendida novamente.
Os nomes e comandos deste procedimento correspondem ao SFOS 22.0. O diagnóstico começa no WebAdmin; a Device Console só é utilizada para as verificações adicionais expressamente descritas abaixo.
⚠️ Flush limpa a cache IPv4 ou IPv6 selecionada, não apenas uma linha. Numa firewall em produção, deve primeiro guardar-se a entrada atual, limitar o teste e evitar limpar a cache durante um pico de carga.
O que fazem ARP, NDP e a cache de vizinhos
O ARP associa um endereço IPv4 a um endereço MAC no segmento Layer 2 local. Trata-se de um dispositivo diretamente acessível, normalmente na mesma VLAN. No IPv6, o Neighbor Discovery Protocol (NDP) assume esta função através de ICMPv6. A firewall precisa desta informação antes de poder enviar um pacote por uma interface diretamente ligada para o vizinho seguinte.
As associações aprendidas dinamicamente permanecem na cache durante 600 segundos por predefinição. Depois disso, são aprendidas novamente quando necessário. Uma entrada desatualizada pode surgir, por exemplo, após a substituição de um dispositivo ou de uma placa de rede, ou depois de uma alteração numa VM. Um endereço IP duplicado pode, por outro lado, fazer com que o endereço MAC visível mude repetidamente.
Em Neighbor cache entry timeout, pode alterar-se o intervalo de limpeza automática e aplicá-lo com Apply. Um valor mais curto força uma reaprendizagem mais frequente e não corrige endereços IP duplicados, VLAN incorretas nem associações estáticas desatualizadas. Antes da alteração, deve registar-se o valor inicial. Se o teste não trouxer benefícios, introduz-se novamente esse valor exato, clica-se em Apply e volta-se a testar o caminho de dados real.
A cache de vizinhos abrange apenas vizinhos diretamente acessíveis no respetivo segmento Layer 2. Para um destino remoto, a firewall não guarda o endereço MAC do servidor de destino, mas sim o do router seguinte.
Não é o mesmo que Proxy ARP: nesse caso, a firewall responde numa interface, em nome de outro endereço de destino, ao respetivo pedido ARP IPv4. Este caso especial é tratado separadamente em Configurar e testar Proxy ARP na Sophos Firewall.
Identificar ARP flux em várias interfaces
O ARP flux pode ocorrer quando várias interfaces Ethernet físicas da Sophos Firewall estão ligadas ao mesmo meio de Layer 2 ou à mesma broadcast domain. A firewall pode então responder a um pedido ARP através das duas interfaces, fazendo com que o dispositivo que envia o pedido veja associações MAC variáveis ou inesperadas. Duas VLAN separadas, um LAG configurado incorretamente ou um endereço IP duplicado comum não constituem automaticamente ARP flux.
Uma captura de pacotes curta serve apenas para verificar o comportamento ARP: deve confirmar-se se o mesmo pedido chega às duas portas físicas e se ambas as interfaces da firewall respondem. A captura não mostra o valor configurado de arp-flux.
A Device Console está acessível pela consola local ou por SSH. Os pré-requisitos e o acesso SSH são explicados em Ligar à Sophos Firewall por SSH. Depois de iniciar sessão, seleciona-se Option 4: Device Console. Antes de qualquer alteração, executa-se a verificação prévia de referência do SFOS 22.0:
show arp-flux
Regista-se exatamente o valor devolvido, on ou off. A definição é global e não específica de uma interface. Só deve ser alterada temporariamente quando as duas interfaces partilham intencionalmente a mesma broadcast domain, a captura confirma o comportamento problemático e o valor atual requer uma alteração. Se tiver sido registado on, testa-se o modo de resposta específico da interface numa janela de manutenção com:
set arp-flux off
Com off, a firewall responde aos pedidos ARP através da interface Ethernet correspondente. Em seguida, verificam-se, nos dois caminhos, a acessibilidade, as entradas de vizinhos, o serviço original e o comportamento ARP com uma nova captura.
Depois do teste, independentemente do resultado, restaura-se exatamente o valor registado com show arp-flux. Se o valor inicial era on, executa-se:
set arp-flux on
Se o valor inicial era off, executa-se em alternativa:
set arp-flux off
Executa-se novamente show arp-flux para confirmar o valor restaurado e repetem-se os testes de caminho. A captura de pacotes serve apenas para verificar o comportamento resultante.
Se não houver prova de uma broadcast domain partilhada ou o problema permanecer inalterado com off, não se devem alterar outras definições ARP com base em suposições. A análise deve regressar às VLAN, bridges, LAG, tabela MAC do switch, cablagem e endereços IP duplicados.
Verificar primeiro a cache de vizinhos
- Abrir Network > Neighbors (ARP–NDP).
- Em Show, selecionar IPv4 neighbor cache ou IPv6 neighbor cache.
- Procurar o endereço IP afetado.
- Anotar o endereço IP, o endereço MAC e a interface.
- Em Static neighbor table, excluir a existência de uma associação fixa, mas incorreta, para o mesmo endereço IP.
- Comparar o endereço MAC com o dispositivo final, o hypervisor, o switch ou o router seguinte.
A interface é tão importante como o endereço MAC. Uma associação IP-MAC correta na porta errada aponta frequentemente para um problema de VLAN, bridge, LAG ou cablagem. O endereço MAC esperado pode ser consultado, por exemplo, nas informações de rede do dispositivo final, na tabela MAC do switch ou no router diretamente ligado. Se a entrada estiver completamente ausente, envia-se a partir da firewall um ping direcionado para o endereço IP afetado e volta-se depois a verificar a vista.
Para IPv4 e IPv6, as duas vistas de cache no WebAdmin são o ponto de verificação documentado. Mostram a interface além do endereço e evitam aplicar por engano uma observação IPv4 a um problema IPv6.
Reaprender de forma controlada uma associação desatualizada
Limpar a cache é um passo de diagnóstico, não uma reparação permanente. Também não remove uma associação estática incorreta. Não existe um rollback direto para entradas dinâmicas eliminadas; a firewall volta a aprendê-las com novo tráfego. Se a mesma associação errada regressar, a causa continua presente na rede.
- Documentar o endereço IP, o endereço MAC e a interface atuais.
- Reproduzir o erro com um único ping ou uma tentativa de ligação.
- Se houver suspeita de um endereço IP duplicado ou de manipulação, guardar primeiro o estado atual e um capture curto. Um flush imediato eliminaria este indício.
- Em Show, selecionar a cache IPv4 ou IPv6 afetada.
- Clicar em Flush. Esta ação limpa a cache selecionada.
- Voltar a gerar tráfego direcionado a partir do dispositivo afetado.
- Verificar que endereço MAC e interface foram aprendidos novamente.
- Voltar a testar o serviço original com a mesma origem e o mesmo destino.
Para um teste controlado a partir da Device Console, podem ser enviados, por exemplo, quatro pacotes para um endereço de destino documentado:
ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4
Os endereços são exemplos e devem ser substituídos pelo destino IPv4 ou IPv6 real. Um ping bem-sucedido confirma apenas a acessibilidade básica; depois disso, continua a ser necessário testar o serviço originalmente afetado.
Durante a reaprendizagem podem ocorrer breves atrasos. Reduzir muito o timeout de forma generalizada raramente é a melhor solução: a firewall terá de resolver os vizinhos com maior frequência, sem que isso corrija um endereço IP duplicado ou uma porta de switch incorreta.
Se, depois do flush, apenas um endereço IP público continuar sem mudar para o novo endereço MAC da firewall, a entrada desatualizada encontra-se provavelmente no fornecedor ou num router a montante. Existe um procedimento separado para Resolver problemas de ARP após uma migração da firewall.
Criar um vizinho estático apenas para associações fixas
Um vizinho estático associa permanentemente um endereço IP a um endereço MAC e a uma interface física. Só pode existir uma associação deste tipo por endereço IP. A firewall verifica as entradas estáticas antes da cache dinâmica e, ao guardar, remove referências dinâmicas para o mesmo endereço IP. Se mais tarde o endereço IP, o endereço MAC ou a porta deixarem de corresponder, a ligação pode falhar apesar de o dispositivo final estar configurado corretamente.
As entradas estáticas são, por isso, adequadas para sistemas estáveis, como um dispositivo de infraestrutura com ligação por cabo e endereço IP fixo. Normalmente, não são adequadas para clientes DHCP, dispositivos móveis, alterações de HA ou VM e portas de switch variáveis.
Em Network > Neighbors (ARP–NDP), apresentar a Static neighbor table e selecionar Add. Em seguida, definir os seguintes valores:
- IP version: selecionar IPv4 ou IPv6.
- IPv4/IPv6 address: introduzir o endereço fixo do dispositivo.
- MAC address: introduzir o endereço MAC real deste dispositivo.
- Interface: selecionar a interface física através da qual o vizinho está acessível.
Um exemplo documentado pode utilizar 192.0.2.10, 02:00:00:00:00:10 e Port1. Estes valores são placeholders e têm de ser totalmente substituídos pelo endereço IP, endereço MAC e porta reais.
Antes de guardar, regista-se se a opção Add as a trusted MAC address to prevent a spoofing attempt está selecionada. Só deve ser ativada quando esta estratégia de proteção for utilizada de forma consciente, porque uma alteração posterior de VM, NIC ou porta pode surgir como um conflito legítimo. A interação das entradas MAC fidedignas com redes dinâmicas, DHCP e virtualização é explicada em Verificar Spoof Protection e DoS Settings na Sophos Firewall.
Com Save cria-se a associação e, em seguida, testa-se exatamente o dispositivo afetado. Ao reverter o teste, remove-se a nova entrada da Static neighbor table, gera-se tráfego direcionado e verifica-se a associação aprendida dinamicamente. Depois, abre-se Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Se permanecer uma entrada MAC fidedigna correspondente criada para este teste, remove-se separadamente; não se deve presumir que a eliminação do vizinho estático também a elimina. Deve ainda ficar documentado quem irá ajustar uma entrada mantida em caso de alteração de hardware, endereço IP ou porta. Uma associação estática sem esta responsabilidade transforma-se facilmente numa causa de erro invisível mais tarde.
Verificar possíveis tentativas de neighbor poisoning
Uma associação estática define a combinação esperada de endereço IP, endereço MAC e interface. Se o mesmo endereço IP aparecer com outro endereço MAC, ou se a mesma combinação IP-MAC surgir noutra porta associada, a firewall trata a situação como possível manipulação e não atualiza a cache com a associação divergente.
Em Network > Neighbors (ARP–NDP), pode ativar-se Log possible neighbor poisoning attempts e guardar com Apply. Antes de um teste de duração limitada, regista-se se a caixa de seleção está marcada e restaura-se esse estado visível no final. A opção ajuda no diagnóstico, mas não significa que todas as divergências devam ser imediatamente consideradas um ataque. Um endereço IP duplicado, um adaptador de rede substituído, uma VM movida ou uma mudança de porta também podem provocar um conflito.
Os pacotes ARP IPv4 rejeitados podem ser apresentados na Device Console durante um teste curto:
drop-packet-capture 'arp'
Se existirem muitas interfaces, a saída pode ser limitada a uma porta física:
drop-packet-capture interface Port1 'arp'
Port1 é um exemplo e deve ser substituído pela interface afetada. Em seguida, reproduz-se o erro uma vez e termina-se a saída contínua com Ctrl+C. O filtro mostra apenas pacotes ARP rejeitados e não constitui um arquivo de logs permanente. Para NDP IPv6 ou uma análise geral de pacotes, utiliza-se Packet Capture no WebAdmin, limitando de forma direcionada a origem, o destino, o protocolo e a interface.
Interpretar sintomas típicos
- Após a substituição de um dispositivo ou NIC, o destino continua inacessível: comparar o valor MAC antigo com o que foi aprendido novamente, limpar a cache de forma controlada e voltar a testar.
- O endereço MAC muda repetidamente: verificar se existe um endereço IP duplicado, uma lease DHCP, um clone de VM ou um comportamento de HA. Uma entrada estática apenas ocultaria o conflito real.
- A associação aparece na interface errada: verificar VLAN, bridge, LAG, porta do switch e cablagem.
- Um dispositivo com associação estática deixa de funcionar após uma alteração: comparar o endereço IP, o endereço MAC e a porta física com a associação e ajustar ou remover conscientemente a entrada.
- Apenas o IPv6 é afetado: verificar IPv6 neighbor cache, Router Advertisements, VLAN e o caminho ICMPv6. Um comando ARP IPv4 não fornece qualquer prova neste caso.
- Os pacotes chegam à firewall, mas o serviço continua sem funcionar: verificar separadamente a regra de firewall, NAT, routing e o caminho de retorno. A cache de vizinhos comprova apenas a entrega Layer 2 local.
Verificação final
- Endereço IP afetado, endereço MAC esperado e interface documentados.
- Cache IPv4 ou IPv6 verificada antes de uma alteração.
- Se necessário, foi limpa exatamente a cache selecionada e gerado tráfego direcionado.
- Associação aprendida novamente comparada com o dispositivo final, switch, hypervisor ou router.
- Associação estática utilizada apenas com uma combinação IP-MAC-porta permanentemente estável.
- Aviso de poisoning distinguido de um endereço IP duplicado, uma substituição de dispositivo e alterações de rede.
- Serviço original novamente testado após a verificação de Layer 2.