Por que o conntrackd não está replicando o estado?

Question

Eu tenho um problema com um cluster de firewall ativo / ativo em que o estado de rastreamento de conexão no firewall não parece estar sendo replicado.

Ele está ativo / ativo porque eu tenho dois roteadores conectados através de diferentes ISPs e um intervalo de rede que é fornecido através do BGP. Como os dados são encaminhados de volta é determinado pelo BGP. Portanto, o roteamento é assimétrico. Esses dois firewalls estão conectados em rede na rede interna e eu tenho um IP virtual atuando como uma rota padrão para servidores Windows.

Quando ambos os firewalls estão sendo executados e um servidor interno tenta se conectar, a resposta retorna através do firewall secundário (aquele que não tem registro do estado da conexão). Portanto, a resposta é descartada e não encaminhada para o servidor que iniciou a solicitação.

Eu pensei que conntrackd iria consertar isso, mas eu não consigo fazer isso funcionar. Talvez eu entenda mal como isso funciona. Posso obter o conntrackd para replicar o estado do iptables? Funciona realmente no modo ativo / ativo? O estado é replicado em tempo real?

Aqui está o que o meu arquivo conntrackd.conf contém.

Sync {
  Mode ALARM {
    RefreshTime 15
    CacheTimeout 180
  }

  Multicast {
    IPv4_Address 225.0.0.50
    Group 3780
    IPv4_Interface 10.0.0.100
    Interface eth2
    SndSocketBuffer 1249280
    RcvSocketBuffer 1249280
    Checksum on
  }
}

General {
  Nice -20
  HashSize 32768
  HashLimit 131072
  LogFile on
  Syslog on
  LockFile /var/lock/conntrack.lock
  UNIX {
    Path /var/run/conntrackd.ctl
    Backlog 20
  }
  NetlinkBufferSize 2097152
  NetlinkBufferSizeMaxGrowth 8388608
  Filter From Userspace {
    Protocol Accept {
      TCP
    }

    Address Ignore {
      IPv4_address 127.0.0.1 # loopback
      IPv4_address 10.0.0.100 # dedicated link0
      IPv4_address 10.0.0.101 # dedicated link1
      IPv4_address x.x.x.130 # Internal ip
    }
  }
}

O outro conntrackd é o mesmo para além do IPv4_interface na seção multicast que tem 10.0.0.101. E o IP interno na seção de filtro termina em 131

Defini regras de firewall para aceitar entradas para 225.0.0.50/32 & saída para 225.0.0.50/32.

Configurei o modo ALARM aqui, mas primeiro tentei o FTFW. Nem parece funcionar.

Minha versão do kernel é: 3.11.0.

Desculpe, meu recorte e cole não está funcionando na janela da caixa Virtual. No entanto, deixe-me apenas dizer que quando eu executo: sudo conntrackd -i ele lista como saída uma conexão tcp ESTABLISHED que é uma que eu criei com o ssh entrando.

No entanto, no outro roteador, o mesmo comando não produz saída. O que eu acho que deveria significar que o estado não foi transferido para o outro roteador.

Alguma idéia?

Atualização: Eu corri o tcpdump -i eth2 em cada máquina e eu posso ver pacotes UDP chegando localmente do outro roteador que foram destinados para o endereço multicast 225.0.0.50 porta 3780 com um comprimento de 68 bytes.

Se eu iniciar uma conexão ssh, vejo a atividade imediata no tcpdump, e a desconexão faz o mesmo. Caso contrário, batimentos cardíacos regulares dessa mensagem aparecem. Portanto, está claro que os roteadores estão enviando os pacotes, mas está desconectando-os? Existe alguma depuração oculta que eu possa ativar?

Update2: Ok, depois de dias pesquisando e olhando o código-fonte, descobri que o conntrackd está replicando o estado, mas acaba em um cache externo. Para confirmar as regras, você precisa executar conntrackd -c. Claramente o conntrackd é projetado para ser usado em um modo ativo / backup.

Parece que uma nova opção foi introduzida em algum momento chamado CacheWriteThrough. Mas foi então removido. Pode conntrack fazer ativo / ativo ou não? Eu não consigo encontrar uma resposta para isso.

    

Answer 1

Ok, depois de dias de frustração e pouca documentação e até lendo o código fonte. Eu descobri isso.

Mode FTFW {
     [...]
     DisableExternalCache On
}

Desativar o cache externo é o que você precisa para um cenário de roteamento assimétrico. Caso contrário, para ativo / backup, você deseja usar o padrão off e definir notify_master, notify_backup, notify_fault settings no keepalived.

A configuração CacheWriteThrough foi removida e substituída por DisableExternalCache.

Esses scripts são usados para confirmar o cache de estado da conexão externa ao roteador que contém o IP. Com DisableExternalCache On eles não devem ser necessários porque o estado já está comprometido.

    

Answer 2

Descobri que uma configuração ativa / de backup (sem nopreempt) falhou em um par de firewall / roteador se o servidor ativo foi reinicializado. Quando o mestre foi desativado, o backup assumiu e o script primary-backup.sh confirmou o cache externo para a tabela de kernel, conforme o esperado. Todas as conexões ficaram ativas.  No entanto, como o mestre (original) foi reiniciado e assumiu novamente, já que seu cache externo estava vazio, o script primary-backup.sh confirmou um cache externo vazio para a tabela de kernel e todas as conexões foram eliminadas pelo iptables. Eu consertei isso adicionando algumas linhas perto do início do script:

case "$1" in
  primary)
    #
    # request resynchronization with master firewall replica
    #
    # Note: this is an attempt to fix problem after reboot of original master,
    # which had no entries in external cache and so resulted in empty
    # conntrack table
    #
    $CONNTRACKD_BIN -C $CONNTRACKD_CONFIG -n
    if [[ $? -eq 1 ]]
    then
        logger "ERROR: failed to invoke conntrackd -n"
    fi

    #
    # commit the external cache into the kernel table
    #
    # etc