Cache Conntrackd não mostrando sessões tcp

Question

Estou com um problema um pouco estranho com conntrackd . Eu criei um ambiente com um cenário ativo / backup onde as sessões serão replicadas para o backup após um failover e vice-versa. Eu segui o manual oficial da ferramenta e outros tutoriais que praticamente usam a mesma configuração.

O problema

Eu crio várias tcp sessões usando wget ou ssh e posso ver as sessões sendo criadas em conntrack -L e conntrack -E -p tcp

root@master:/home/master# conntrack -L
udp      17 22 src=x.x.x.190 dst=x.x.x. sport=138 dport=138 [UNREPLIED] src=x.x.x. dst=x.x.x.190 sport=138 dport=138 mark=0 use=1
udp      17 4 src=x.x.x.9 dst=255.255.255.255 sport=11235 dport=11232 [UNREPLIED] src=255.255.255.255 dst=x.x.x.9 sport=11232 dport=11235 mark=0 use=1
udp      17 21 src=x.x.x.26 dst=255.255.255.255 sport=17500 dport=17500 [UNREPLIED] src=255.255.255.255 dst=x.x.x.26 sport=17500 dport=17500 mark=0 use=1
udp      17 14 src=x.x.x.212 dst=x.x.x. sport=137 dport=137 [UNREPLIED] src=x.x.x. dst=x.x.x.212 sport=137 dport=137 mark=0 use=1
udp      17 18 src=x.x.x.50 dst=x.x.x. sport=62401 dport=3052 [UNREPLIED] src=x.x.x. dst=x.x.x.50 sport=3052 dport=62401 mark=0 use=1
tcp      6 299 ESTABLISHED src=192.168.0.7 dst=x.x.x.58 sport=46026 dport=80 src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46026 [ASSURED] mark=0 use=1

root@master:/home/master# conntrack -E -p tcp
    [NEW] tcp      6 120 SYN_SENT src=192.168.0.7 dst=x.x.x.58 sport=46030 dport=80 [UNREPLIED] src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46030
 [UPDATE] tcp      6 60 SYN_RECV src=192.168.0.7 dst=x.x.x.58 sport=46030 dport=80 src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46030
 [UPDATE] tcp      6 432000 ESTABLISHED src=192.168.0.7 dst=x.x.x.58 sport=46030 dport=80 src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46030 [ASSURED]

Mas não consigo vê-los no cache interno do cache principal ou externo de backup, só consigo ver udp sessions. (Eu não posso postar o cache interno e externo, eles são muito grandes. Imagine apenas como o primeiro bloco de código, mas apenas udp sessões). O que significa que tcp sessions são destruídas no failover e não são replicadas. Meu gwet faz uma pausa e meu ssh congela a conexão. Mesmo se o mestre assumir novamente, as sessões já estarão perdidas.

A configuração do conntrackd é:

Sync {
    Mode FTFW {
        DisableExternalCache Off
        CommitTimeout 1800
        PurgeTimeout 5
    }

    UDP{
        IPv4_address 192.168.0.4
        IPv4_Destination_Address 192.168.0.5
        Port 3780
        Interface eth1
        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
            UDP
            ICMP # This requires a Linux kernel >= 2.6.31
        }
        Address Ignore {
            IPv4_address 127.0.0.1 # loopback
            IPv4_address x.x.x.58
            IPv4_address x.x.x.56
            IPv4_address x.x.x.59
            IPv4_address x.x.x.7
            IPv4_address 192.168.0.4
            IPv4_address 192.168.0.5
            IPv4_address 192.168.0.6
            IPv4_address 192.168.0.7
            IPv4_address 192.168.100.100
        }
    }
}

Se eu usar DisableExternalCache On como esta pergunta sugere que minhas respostas internas e caches externos estão vazios (até udp sessões são perdidas). O mesmo se aplica se eu usar Address Accept em vez de Address Ignore . DisableExternalCache On também é recomendado para ser usado em um cenário ativo / ativo em vez de um ativo / backup que estou procurando.

As regras de firewall estão definidas para aceitar e essas regras adicionais são adicionadas (tiradas do teste de netfilter )

[1] iptables -P FORWARD DROP
[2] iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
[3] iptables -A FORWARD -i eth1 -p tcp --syn -m state --state NEW -j ACCEPT
[4] iptables -A FORWARD -i eth1 -p tcp -m state --state ESTABLISHED -j ACCEPT
[5] iptables -A FORWARD -m state --state INVALID -j LOG
[6] iptables -I POSTROUTING -t nat -s 192.168.0.3 -j SNAT --to 192.168.1.100

Eu tentei outras configurações, outros modos de sincronização, scripts que confirmam alterações e liberam caches quando apropriado. Mas não consigo descobrir porque tcp sessions não são mostradas no cache. Alguma ideia? Estou faltando alguma coisa?

    

Answer 1

Depois de muita leitura, reconfiguração e ajuda externa, o problema foi resolvido (finalmente o pesadelo acabou).

O problema estava na parte Address Ignore da configuração, não no conjunto de regras que pensei primeiro.

Nos tutoriais que eu segui eles dizem:

The "Address Ignore" block should list ALL the IPs the firewall has

Mas eles não disseram que Address Ignore deveria listar TODOS os IPs que o firewall tem em Interfaces Locais .

A colocação de endereços adicionais, como um host de teste por digitação, ignorará todo o tráfego gerado desse host. É por isso que na tabela de expectativas eu pude ver a sessão, mas não no cache. O que significa que o bloco Address Ignore deve listar apenas seus próprios endereços IP (e talvez o do Backup) (loopback, ext, int, VIP).

PS: Outra coisa que deve ser mencionada é que o firewall deve ser configurado para mascarar os IPs do Firewall. Se não, no failover, o VIP muda o proprietário, mas a sessão ainda estará procurando pelo IP da máquina que foi criada.

Para superar isso, uma regra snat deve ser definida.