Resolver problemas de ARP no Sophos Firewall após uma migração

Após a substituição de uma firewall, o novo Sophos Firewall pode estar online, enquanto alguns endereços IP públicos de alias continuam inacessíveis. Muitas vezes, o router a montante ainda associa esses endereços ao endereço MAC da interface WAN do equipamento antigo. Nesse caso, os pacotes nem sequer chegam à nova firewall, embora o alias, o DNAT e a regra de firewall pareçam estar corretamente configurados.

Este guia mostra como diagnosticar este problema de IPv4 através da verificação da interface, do Packet Capture e do ARP a montante. A cache ARP só deve ser atualizada de forma direcionada, ou deve ser executado um ARP-Ping através da Device Console, depois de confirmada a causa na camada 2. Para uma migração geral de hardware, consulte também Comparar Sophos XG e XGS.

Quando o ARP é realmente o principal suspeito

O problema surge normalmente logo após a substituição de um equipamento, um restauro ou uma mudança de fabricante. O endereço IP público mantém-se, mas o endereço MAC da interface WAN muda.

Os indícios mais fortes são:

O IP principal da interface WAN funciona, mas um ou mais endereços IP de alias não.
Um teste externo não consegue alcançar um serviço publicado em determinados IPs públicos.
O Packet Capture não mostra qualquer pacote de entrada para o IP afetado.
O serviço começa subitamente a funcionar quando expira um cache a montante, sem qualquer outra alteração na firewall.
O router a montante ainda mostra o endereço MAC do equipamento antigo para o IP público.

O ARP não é automaticamente a causa. Se os pacotes chegarem à interface WAN, os pontos seguintes a verificar são o DNAT, a regra de firewall, a zona, o servidor interno ou a rota de retorno. Este procedimento também não se aplica ao IPv6, que utiliza Neighbor Discovery para a resolução de vizinhos.

Para verificar a cache ARP ou NDP local da Sophos Firewall, consultar Verificar a cache de vizinhos ARP e NDP. O artigo também explica quando faz sentido limpar a cache e quando o problema continua no fornecedor ou equipamento a montante.

Porque podem falhar IPs de alias após uma substituição

O ARP associa um endereço IPv4 a um endereço MAC no segmento local de camada 2. O router guarda esta associação na cache ARP. Após a substituição, o dispositivo a montante deverá aprender o endereço MAC da interface WAN da nova firewall. Se isto não acontecer para um IP de alias, continuará a enviar os pacotes para o equipamento antigo.

Isto explica por que motivo o IP principal pode funcionar enquanto um IP de alias falha: o dispositivo a montante mantém uma entrada separada para cada endereço IP. Uma associação pode já estar atualizada, enquanto outra continua a apontar para o endereço MAC antigo.

Primeiro, é necessário esclarecer como o operador fornece os endereços públicos:

Rede diretamente ligada: O dispositivo a montante resolve os IPs principal e de alias através de ARP. Após uma substituição de hardware, é plausível existirem entradas antigas.
Bloco público encaminhado: O operador encaminha o bloco para o IP WAN principal. Neste caso, não é necessariamente expectável uma entrada ARP separada para cada IP público; a rota do operador e a configuração local de alias/NAT são mais relevantes.

Diagnóstico antes de intervir

O diagnóstico deve começar por mostrar onde termina o fluxo de pacotes. Desta forma, evita-se alterar simultaneamente o ARP, o NAT e as regras de firewall.

Em Network > Interfaces, verifique a interface WAN física e os endereços afetados. Um IP de alias é associado à interface física correta através de Add interface > Add alias; a versão IP, o endereço e a máscara de rede têm de corresponder ao desenho da rede.
Se os endereços de alias pertencerem a outra sub-rede, verifique se o dispositivo a montante nessa sub-rede está acessível à firewall como gateway. Várias interfaces WAN separadas na mesma sub-rede não são uma solução adequada e podem provocar problemas de ARP; consoante o desenho, devem ser utilizadas interfaces de alias ou LAG.
A partir de um sistema de teste verdadeiramente externo, teste o mesmo IP público e o mesmo serviço. Um ping, por si só, não é suficiente, porque o ICMP pode estar bloqueado; utilize também um teste a uma porta TCP conhecida.
Em Diagnostics > Packet capture, capture o tráfego na interface WAN. Para a verificação da camada 2, filtre pela interface e por Ethernet type: ARP; para o serviço, filtre depois pelo IP de destino afetado e pelo protocolo.
Apenas quando chegarem pacotes IP, procure no Log viewer pelo IP de destino, pelo serviço, pela Firewall Rule ID e pela NAT Rule ID. O próprio ARP é analisado através do Packet Capture, e não através de um registo normal de regras de firewall.

Utilizar o Packet Capture no Sophos Firewall explica a apresentação dos dados em maior detalhe. Para verificar a interface, a zona e a associação do alias, consulte Configurar zonas e interfaces do Sophos Firewall.

A observação indica claramente o caminho a seguir:

Não chegam pacotes à WAN: Verifique o ARP a montante, o encaminhamento do operador, o CPE ou o switch anterior.
Os pacotes chegam e são descartados: Verifique a regra de firewall, o DNAT, a zona e o serviço.
Os pacotes são encaminhados internamente, mas não há resposta: Verifique a rota de retorno, o servidor interno, o SNAT e a firewall do servidor.
Apenas o IP de alias é afetado: Compare especificamente a configuração do alias e a entrada a montante desse IP.

Atualizar a associação ARP de forma direcionada

Limpar o cache a montante

A correção mais adequada deve ser feita no equipamento que contém a entrada incorreta. Se gerir o router a montante ou o CPE do operador, elimine especificamente a entrada ARP do IP afetado. Em seguida, o dispositivo a montante terá de aprender o novo endereço MAC da interface WAN.

Se não for possível eliminar uma entrada específica, reiniciar o router responsável também pode atualizar o cache. Esta operação deve ser realizada numa janela de manutenção, porque interrompe outras ligações. No caso de equipamentos do operador, este deve conhecer o IP afetado, os endereços MAC antigo e novo e o CPE responsável, em vez de reiniciar indiscriminadamente todo o percurso.

Executar um ARP-Ping através da Device Console

O Sophos Firewall disponibiliza um diagnóstico ARP na Device Console. O ARP-Ping pode utilizar o Source IP afetado e a interface WAN para provocar uma atualização no dispositivo a montante diretamente ligado.

Após iniciar sessão através da consola ou por SSH, abra Option 4: Device Console e execute o comando com os valores reais:

system diagnostics utilities arp ping source <alias-ip> interface <wan-interface> <upstream-gateway>

Exemplo com endereços reservados para documentação:

system diagnostics utilities arp ping source 198.51.100.21 interface Port2 198.51.100.1

Neste exemplo, 198.51.100.21 é o IP de alias afetado em Port2; 198.51.100.1 é o dispositivo a montante diretamente acessível no mesmo segmento de camada 2. O Source IP, a interface e o destino têm de ser coerentes entre si. Se existirem vários IPs de alias afetados, teste cada endereço individualmente para que seja possível identificar o efeito da operação.

O comando não corrige uma configuração de alias incorreta nem uma entrada ARP estática no operador. Se o operador encaminhar os endereços em vez de os resolver localmente por ARP, o ARP-Ping também não é a solução adequada. Ligar ao Sophos Firewall por SSH explica como aceder em segurança à Device Console.

Validar a acessibilidade após a correção

Depois de aplicar exatamente uma medida, repita o mesmo teste. Assim, é possível identificar o que resolveu o problema.

No dispositivo a montante, verifique se o IP afetado aponta agora para o novo endereço MAC da interface WAN.
Repita o teste externo de ping ou à porta TCP com a mesma origem e o mesmo destino.
No Packet Capture, verifique se os pacotes chegam agora à interface WAN.
Se os pacotes chegarem, confirme a Firewall Rule ID e a NAT Rule ID no Log Viewer.
Teste o serviço publicado até ao servidor interno, incluindo o percurso de retorno.

Uma entrada ARP atualizada apenas prova que o dispositivo a montante consegue enviar os pacotes para a nova firewall. O funcionamento do serviço continua a depender do DNAT, da regra de firewall, do destino interno e da rota de retorno. Publicar um servidor através de DNAT mostra o percurso completo das regras para a publicação de um servidor.

Se o problema persistir

Se o IP continuar inacessível apesar da entrada ARP atualizada, não deve experimentar mais comandos de shell; deve antes rever a hipótese inicial.

As alternativas mais comuns são:

O IP de alias está associado à interface física errada ou utiliza uma máscara de rede incorreta.
O operador encaminha o bloco público de forma diferente da assumida.
Uma entrada ARP ou MAC estática no dispositivo a montante sobrepõe-se à aprendizagem dinâmica.
Um switch anterior mantém uma associação MAC antiga ou utiliza Port Security.
A regra DNAT aponta para outro IP público.
A regra de firewall não permite a origem, o serviço ou a zona.
O servidor interno responde através de outro gateway.
Num ambiente HA, é esperado o endereço MAC virtual ou físico incorreto.

Uma perda de ARP que se repete continuamente também não deve ser contornada com um comando personalizado executado periodicamente. O operador, o CPE, o desenho da camada 2 e, se necessário, o Sophos Support devem esclarecer a causa.

Envolver o operador ou a equipa responsável pelo upstream

Se a captura na WAN não mostrar pacotes para o IP afetado, o operador precisa de um diagnóstico preciso, e não apenas da indicação genérica de que a firewall está inacessível.

Tenha disponíveis os seguintes dados:

IP principal ou de alias afetado,
interface WAN e novo endereço MAC,
gateway a montante ou CPE,
hora do teste externo e do ARP-Ping,
resultado do Packet Capture,
modo de disponibilização esperado, como rede diretamente ligada ou encaminhada,
resultado para o IP principal e para outros IPs de alias.

Com estes dados, o operador pode verificar a entrada ARP concreta, uma associação estática ou a rota para o bloco público. Dados de configuração sensíveis ou capturas de pacotes completas só devem ser enviados através de um canal de suporte acordado.

Verificação final resumida

IP principal, IPs de alias e modo de disponibilização documentados.
Interface física, versão IP e máscara de rede verificadas.
Teste TCP externo e Packet Capture realizados com destinos idênticos.
Tráfego ARP e IP analisado separadamente no diagnóstico.
Entrada a montante eliminada de forma direcionada ou ARP-Ping executado com os parâmetros corretos.
Nova associação MAC confirmada no dispositivo a montante.
DNAT, Firewall Rule ID, NAT Rule ID e percurso de retorno verificados posteriormente.
Causa e medida documentadas no pedido de alteração ou no registo da migração.

FAQ

É necessário limpar a cache ARP após cada migração de firewall?

Não. Normalmente, o dispositivo a montante aprende automaticamente o novo endereço MAC. Só é necessário intervir quando uma entrada específica permanece desatualizada e o Packet Capture mostra que o IP afetado não chega à nova firewall.

Porque funciona o IP principal, mas não um IP de alias?

O dispositivo a montante guarda a associação de cada endereço IPv4 separadamente. A entrada do IP principal pode já apontar para o novo endereço MAC da interface WAN, enquanto um IP de alias continua associado ao endereço MAC antigo.

Trata-se de um problema de ARP, NAT ou da regra de firewall?

Se nenhum pacote chegar à interface WAN durante o teste externo, a causa situa-se antes da avaliação local do DNAT e da regra de firewall. Se o pacote chegar, verifique a NAT Rule ID, a Firewall Rule ID, o destino interno e a rota de retorno.

É possível simplesmente reiniciar o CPE do operador?

Um reinício pode atualizar a cache ARP, mas também interrompe outras ligações. É preferível eliminar especificamente a entrada afetada; se isso não for possível, o reinício deve fazer parte de uma janela de manutenção coordenada.

O ARP-Ping requer a Advanced Shell?

Não. O comando system diagnostics utilities arp ping é executado na Device Console. A Advanced Shell não é necessária.