Configurar e testar Proxy ARP na Sophos Firewall
O Proxy ARP só é necessário numa Sophos Firewall quando um dispositivo no segmento IPv4 diretamente ligado procura um endereço de destino adicional através de ARP e a firewall deve responder em seu nome com o próprio endereço MAC. Isto pode acontecer, por exemplo, com um IP público adicional que depois é encaminhado por DNAT para um servidor interno.
O ponto decisivo é este: o Proxy ARP resolve apenas a descoberta do vizinho antes do verdadeiro caminho de dados IP. Não cria uma regra de firewall, uma regra NAT nem uma rota de retorno. Por isso, começa-se por confirmar com uma captura ARP que é precisamente essa resposta que falta. Só depois se adiciona uma única entrada Proxy ARP e se testa em conjunto com o serviço real.
⚠️ Não ativar Proxy ARP preventivamente para todo um intervalo de endereços públicos. Antes da alteração, documentar a atribuição do fornecedor, a interface, o estado ARP original, o backup, um acesso de gestão independente e o rollback. Um endereço de destino incorreto ou utilizado em duplicado pode atrair tráfego para a firewall errada.
Proxy ARP em oito passos
- Confirmar com o fornecedor ou a equipa upstream se o endereço IPv4 adicional é procurado por ARP no segmento WAN ou se é encaminhado como prefixo para a firewall.
- Excluir que o endereço já esteja a ser utilizado como alias, noutro dispositivo ou por uma configuração existente.
- Durante uma nova ligação, efetuar uma captura ARP na interface de entrada esperada.
- Continuar apenas se o pedido ARP para o endereço de destino chegar e faltar comprovadamente a resposta necessária da firewall.
- Na Device Console, adicionar com
set proxy-arp adduma entrada para exatamente um endereço IPv4. - Configurar ou verificar separadamente a regra de firewall, o DNAT ou a rota, bem como o caminho de retorno.
- Verificar a resposta ARP, a Firewall Rule ID, a NAT Rule ID e o serviço real através de uma nova ligação.
- Depois de um failover de HA e durante o rollback, repetir o mesmo teste e remover especificamente a entrada com
set proxy-arp del.
Distinguir Proxy ARP, alias e routing
O que o Proxy ARP realmente faz
Antes de um dispositivo IPv4 enviar um pacote para um vizinho no mesmo segmento Layer 2, precisa do respetivo endereço MAC. Para isso, envia um pedido ARP. Com Proxy ARP, a Sophos Firewall responde a esse pedido relativo a outro IP de destino com o endereço MAC da interface selecionada.
O upstream passa assim a enviar os quadros Ethernet seguintes para a firewall. Só depois o routing, o NAT e as regras de firewall decidem o que acontece ao pacote IP. Uma resposta ARP bem-sucedida ainda não prova, por isso, que um serviço publicado esteja a funcionar.
O comando da Device Console documentado pela Sophos aplica-se a ARP e, portanto, a IPv4. Em IPv6, a descoberta de vizinhos é feita por Neighbor Discovery. Não se pode deduzir deste comando um procedimento de Proxy NDP.
Qual variante corresponde à atribuição do fornecedor
- IP de alias: O endereço adicional é associado localmente a uma interface física da firewall. É adequado quando a firewall deve possuir o endereço ou utilizá-lo especificamente para NAT ou tráfego de sistema. O procedimento completo encontra-se em Configurar um IP de alias na Sophos Firewall.
- Proxy ARP: A firewall responde em nome de um endereço IPv4 encaminhado ou traduzido ao respetivo pedido ARP. Este comando não cria o endereço como um endereço normal de interface.
- Prefixo encaminhado: O upstream encaminha uma rede completa para o endereço WAN ou para um next hop acordado. Nesse caso, normalmente não procura por ARP no segmento WAN cada endereço de destino desse prefixo. Uma entrada Proxy ARP manual seria a correção errada.
- Vizinho estático: Associa um endereço MAC fixo a um vizinho diretamente acessível. É a perspetiva oposta e não substitui o Proxy ARP. A distinção é explicada em Verificar a cache de vizinhos ARP e NDP.
Uma regra DNAT também não significa automaticamente que seja necessário Proxy ARP manual. Primeiro testa-se o caminho de dados existente. A entrada CLI só se justifica quando o desenho do fornecedor e a captura comprovam realmente a falta da resposta ARP.
Exemplo e valores substituíveis
O exemplo utiliza uma atribuição IPv4 pública diretamente ligada. Um serviço HTTPS deve ficar acessível através do endereço adicional 203.0.113.10:
- interface WAN:
Port2 - endereço WAN da firewall:
203.0.113.9/29 - gateway do fornecedor:
203.0.113.14 - IP de destino público adicional:
203.0.113.10 - host de teste externo:
198.51.100.25 - servidor interno:
10.20.40.20 - serviço:
HTTPS
203.0.113.0/24 e 198.51.100.0/24 são redes de documentação. Não funcionam como endereços de produção e devem ser totalmente substituídas pela atribuição real do fornecedor e por um host de teste externo autorizado. Port2 também é apenas um exemplo; utiliza-se exatamente a interface onde se comprova que o pedido ARP chega.
A máscara /29 não é incluída no comando Proxy ARP. Serve apenas para explicar a rede do exemplo. A entrada propriamente dita aplica-se deliberadamente apenas a 203.0.113.10. Só se deve responder por todo um intervalo quando a propriedade, a utilização e a sintaxe de cada endereço estiverem documentadas de forma inequívoca e tiverem sido verificadas no build utilizado.
Verificar o caminho do fornecedor e o ARP antes da alteração
Antes da intervenção por CLI, separam-se três causas possíveis:
- Nenhum pedido ARP chega à firewall: O caminho do fornecedor, a VLAN, a porta do switch ou a hipótese sobre a atribuição devem ser analisados antes do passo Proxy ARP.
- O pedido chega e já existe um dispositivo a responder: Não se pode gerar uma segunda resposta. Primeiro é necessário identificar o proprietário do endereço MAC visível.
- O pedido chega, mas ninguém responde: Só este resultado corresponde à falta de uma resposta Proxy ARP na firewall.
Para efetuar a captura através de SSH ou da consola local, abrir Option 4: Device Console. O acesso e a distinção entre Device Console e Advanced Shell são explicados em Ligar à Sophos Firewall por SSH.
O filtro BPF seguinte é apenas de leitura e mostra exclusivamente tráfego ARP relativo ao endereço do exemplo:
tcpdump 'arp and host 203.0.113.10'
Em seguida, iniciar uma nova ligação a 203.0.113.10 a partir do caminho de teste externo autorizado. Se o upstream ainda mantiver uma entrada em cache, atualizar ou deixar expirar apenas essa entrada segundo o procedimento documentado do router ou do fornecedor. Limpar todas as caches ARP ou reiniciar o router é desproporcionado para o diagnóstico inicial.
Na captura, a interface, o IP de destino e o momento devem corresponder ao teste. Um pedido ARP noutra VLAN ou interface não é resolvido por uma entrada em Port2.
Adicionar uma única entrada Proxy ARP
Quando a verificação prévia for inequívoca, adiciona-se na Device Console exatamente o endereço confirmado:
set proxy-arp add interface Port2 dest_ip 203.0.113.10
As partes fixas são set proxy-arp add interface e dest_ip. Port2 e 203.0.113.10 são substituídos pela interface real e pelo endereço IPv4 confirmado individualmente.
A Sophos também documenta dst_iprange, mas não publica na página de ajuda atual um exemplo de intervalo completo e testado. Por isso, não se tenta adivinhar aqui o formato. Para intervalos públicos, um endereço individual é também o piloto mais seguro: limita o impacto e permite testes positivos e negativos inequívocos.
Imediatamente após o comando, gerar um novo pedido ARP e repetir a captura. Espera-se uma resposta com o endereço MAC da interface prevista da firewall. Se responder outro endereço MAC ou aparecerem várias respostas, interrompe-se a implementação e esclarece-se primeiro o conflito de endereços.
Implementar separadamente regra de firewall, NAT e retorno
O Proxy ARP leva o quadro Ethernet até à firewall. O caminho de dados IP subsequente continua a precisar de uma configuração própria e tecnicamente adequada.
No exemplo com o servidor HTTPS interno, isso inclui:
- uma regra DNAT restrita de
203.0.113.10:443para10.20.40.20:443; - uma regra de firewall adequada da origem WAN autorizada para a zona do servidor;
- logging durante o teste de aceitação;
- um caminho de retorno do servidor através da Sophos Firewall;
- se necessário, loopback apenas como caso interno planeado separadamente.
Publicar um servidor por DNAT explica a posição da regra, Original Destination, zona de destino, loopback e funções de proteção. Os conceitos SNAT, DNAT, MASQ e PAT são explicados em NAT na Sophos Firewall.
Se o endereço público adicional tiver de ser encaminhado sem DNAT para um sistema downstream, a firewall precisa, em alternativa, de uma rota inequívoca e de regras adequadas. Uma rede sobreposta não deve ser disfarçada com uma rota estática adivinhada ou um intervalo Proxy ARP. O prefixo do fornecedor, o endereçamento interno e o caminho de retorno têm de ser definidos primeiro como um desenho de routing coerente.
Testar o ARP e o serviço real
O teste de aceitação inclui uma verificação de Layer 2 e uma verificação de IP/aplicação:
- Gerar um novo pedido ARP para
203.0.113.10. - Na captura, confirmar o pedido em
Port2e exatamente uma resposta com o endereço MAC esperado da firewall. - Abrir a partir do host de teste
198.51.100.25uma nova ligação HTTPS. - No Log viewer, verificar a Firewall Rule ID e a NAT Rule ID esperadas.
- No Built-in Packet Capture, comparar a entrada em
Port2com a saída para o servidor. - No servidor, confirmar que a ligação chega e que a resposta regressa através da firewall.
- Efetuar um teste negativo com uma porta não permitida e uma origem não autorizada.
- Se for utilizado HA, verificar uma nova ligação e um novo ciclo ARP após um failover controlado.
O sucesso só fica comprovado quando a resposta ARP e o serviço real estão corretos. Um ping não é suficiente: o ICMP pode ser deliberadamente tratado de forma diferente do HTTPS em Device Access ou na regra de firewall. Filtros, Status, Reason, Rule ID e comparação de interfaces são explicados em Packet Capture na Sophos Firewall; o teste completo de regras encontra-se em Testar sistematicamente regras de firewall.
Delimitar problemas de forma sistemática
Não chega qualquer pedido ARP
Verificar a atribuição do fornecedor, o routing upstream, a VLAN, a porta do switch e a verdadeira interface de entrada. Uma entrada Proxy ARP local não pode responder a um pedido que nunca chega à interface. Num prefixo encaminhado, é até esperado que não exista um pedido ARP para o IP de destino individual; nesse caso, devem verificar-se a rota e o next hop em vez do Proxy ARP.
O pedido ARP chega, mas não sai qualquer resposta
Comparar o IP de destino e a interface no comando com a captura. Depois, excluir que a interface tenha mudado, que o endereço esteja incorreto ou que o teste tenha sido executado a partir de outro segmento Layer 2. Não adicionar um intervalo IP mais amplo para aparentemente corrigir um teste individual pouco claro.
Se a entrada documentada na interface confirmada continuar sem responder, guardar a versão de firmware, uma captura curta e a topologia exata para o Sophos Support. Intervenções não documentadas em parâmetros ARP ou do kernel através de Advanced Shell não são um passo padrão seguro.
Respondem vários endereços MAC
O teste é interrompido. Causas frequentes são um endereço IP duplicado, um equipamento antigo ainda ativo, um alias numa segunda firewall ou outra entrada Proxy ARP. Primeiro é necessário identificar o proprietário de cada endereço MAC e resolver o conflito de endereços. Uma regra de firewall não consegue corrigir respostas ARP concorrentes.
O ARP está correto, mas o serviço continua inacessível
Nesse caso, o Proxy ARP já cumpriu a sua função. A seguir, verificam-se a Firewall Rule ID, a NAT Rule ID, a ordem das regras, a zona de destino, o serviço, o gateway do servidor e o caminho de retorno. Uma nova ligação não deve reutilizar uma sessão antiga.
Após substituição ou failover de HA, o endereço fica brevemente inacessível
No nó ativo no momento do evento, voltar a verificar o ARP e o serviço real. O upstream pode ainda manter uma associação MAC antiga. Primeiro, atualizar de forma controlada apenas a entrada afetada; o procedimento completo para caches antigas do fornecedor ou do router encontra-se em Resolver problemas ARP após uma migração de firewall.
Não se promete a continuação sem interrupções das ligações existentes. São determinantes um novo pedido ARP, uma nova sessão da aplicação e os logs do nó que realmente processa o tráfego.
Rollback e operação
Antes de remover, documentar qual endereço publicado e qual serviço dependem da entrada. Na janela de manutenção, remover o mesmo valor individual com del:
set proxy-arp del interface Port2 dest_ip 203.0.113.10
Em seguida, gerar um novo pedido ARP. A firewall já não deve responder por esta entrada manual, desde que nenhum alias, peer de HA ou outro mecanismo legítimo sirva o mesmo endereço. As regras de teste dependentes e a configuração NAT temporária são repostas no estado anterior documentado.
A entrada deve constar da documentação operacional porque, ao contrário de um endereço normal de interface, explica por que motivo a firewall responde pelo IP adicional. Depois de uma alteração de interfaces, substituição do equipamento, restore, mudança de firmware ou teste de HA, voltar a verificar o endereço de destino, a interface, a resposta ARP e o serviço real.
Lista de verificação
- Atribuição do fornecedor e modelo ARP em vez de routing confirmados.
- Confirmado que o IP de destino pertence ao próprio ambiente e não está atribuído em duplicado.
- O pedido ARP chega à interface documentada.
- Falta da resposta antes da alteração comprovada por captura.
- Apenas um endereço piloto introduzido com
dest_ip. - Regra de firewall, NAT ou rota e caminho de retorno verificados separadamente.
- Endereço MAC esperado, Firewall Rule ID e NAT Rule ID confirmados.
- Origem não autorizada e porta não permitida testadas negativamente.
- Failover de HA ou caminho de substituição verificado com uma nova ligação.
- Comando
delexato e estado original documentados.