Redundant Iptables Routers - erros do pacote marciano do log do roteador secundário

Question

Temos uma rede configurada principalmente com um par redundante de firewalls / roteadores Linux Iptables, mas estamos perdendo uma parte crucial do quebra-cabeça. Qualquer tráfego local destinado ao roteador secundário é bem-sucedido na mesma sub-rede, mas falha no ip do roteador "principal". Aqui está um exemplo:

Diagrama de rede

Router1 e Router2 têm interfaces em 10.0.0.0/24 (Subnet0) e 10.0.1.0/24, (Subnet1) com um VIP 10.0.1.1 compartilhado via ucarp.

Webserver1 tem IP 10.0.1.11 e seu gateway padrão é 10.0.1.1

Os pings são bem-sucedidos do Webserver1 para o Roteador1 nas interfaces Subnet0 e Subnet1

Os pings são bem-sucedidos, como esperado, do Webserver1 para o Roteador2 na interface Subnet1. (sem roteamento envolvido)

No entanto, os pings falham do Webserver1 para o Roteador2 na interface Subnet0. O roteador1 recebe o pedido de eco na interface Subnet1 e o encaminha para fora da interface Subnet0, como esperado, mas quando as solicitações de eco chegam ao Roteador2 na interface correta (Subnet0), o Roteador2 não envia uma resposta.

Router2 registra um pacote marciano toda vez que isso ocorre. Jul 31 21:39:33 Router2 kernel: [2772508.610259] fonte marciana 10.0.0.3 de 10.0.1.11, em dev bond0.1000

Pensamos que a linha de log marciano é causada pelo pacote que chega em uma interface diferente de uma rede na qual o roteador já possui uma interface diferente, que o sistema considera uma interface de origem inválida. Qual é a solução para este problema? Deveríamos estar fazendo algo parecido com o SNAT quando o Router1 envia para o Roteador2?

    

Answer 1

Esta é provavelmente uma sugestão que chega tarde. E nem mesmo uma resposta completa.

Não sei o que você está executando nos seus roteadores, mas é possível usar os filtros de caminho inverso , ou seja, você pode desativá-los parcialmente. Eu acho que a maioria das distribuições Linux permite que você defina o rp_filter para níveis 0,1,2. Por padrão, será 1 , o que faz com que esse pacote seja descartado. 0 deixará todo o tráfego 'impossível' passar, mas 2 permitirá pacotes em ambas as interfaces, se uma das interfaces permitir que eles passem, o que pode funcionar no seu caso.

Eu não conheço a extensão dos riscos de segurança que isso trará, mas parece-me que se uma das interfaces permitir, você não deve realmente ter um problema.

    

Answer 2

Vou dar uma olhada nessa resposta, não tendo acesso à sua configuração de configuração e roteamento do iptables. Eu tenho uma configuração muito semelhante e tive esse tipo de problema.

Estou assumindo que você está enviando o tráfego SNAT de 10.0.1.0/24 para o seu IP público (ou usando o MASQUERADE). Tente colocar uma linha antes de todas as outras declarações SNAT / MASQ semelhantes a:

iptables -A POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT  

Isso ignorará suas regras posteriores do SNAT para o tráfego de / para suas redes locais.

Além disso, verifique se você tem uma regra de encaminhamento configurada adequadamente. Para fins de teste, permita todo o tráfego entre os endereços 10.0.0.0/8 (supondo que você ainda não tenha uma regra apropriadamente permissiva). Por exemplo:

iptables -A FORWARD -s 10.0.0.0/8 -d 10.0.0.0/8 -j ACCEPT

Se eu estiver completamente fora da base, poste a saída do seguinte para os dois roteadores:

iptables -nL
iptables -nL -t nat
ip rule show
ip route show
ip route show table XXXX  (For each table listed as a lookup in rules)