Conntrack: quando os health checks passam e o tráfego para

A decisão é tomada uma vez

O connection tracking existe para que uma firewall avalie a política uma vez por fluxo em vez de uma vez por pacote. O primeiro pacote é comparado com as regras, o resultado de forwarding e NAT é escrito na state table, e cada pacote seguinte desse fluxo é um hash lookup. O conntrack do netfilter, a state table do pf no OPNsense e a connection table no Cisco Firepower funcionam todos assim. A entrada vive até o fluxo fechar ou o seu idle timeout expirar, e para uma ligação TCP established esse timeout mede-se em dias.

A consequência passa facilmente despercebida: uma alteração ao encaminhamento, a uma regra NAT ou a uma interface afeta o fluxo seguinte, não os fluxos que já estão na tabela.

Duas formas de isto deixar cair tráfego em silêncio

O caminho desatualizado. Uma rota muda, uma interface move-se, um NAT pool é editado. As novas ligações seguem o novo caminho. Um stream de longa duração mantém a sua interface de egress ou o seu NAT binding originais, pelo que os seus pacotes saem pelo caminho antigo, para um next hop que já não os encaminha ou sem a tradução que a outra ponta agora espera. A stack TCP do emissor retransmite pacientemente numa ligação que ainda considera established, o recetor não vê nada, e nenhum processo de nenhum dos lados falhou.

A tabela cheia. O nf_conntrack_max é atingido, normalmente por causa de um scanner, de um cliente atrás de NAT com milhares de fluxos curtos, ou de timeouts longos numa máquina ocupada. O kernel regista uma linha e começa a descartar o primeiro pacote das novas ligações enquanto os fluxos existentes continuam. Um health check que reutiliza uma ligação aberta continua a passar. Os utilizadores que abrem ligações novas recebem timeouts.

Nenhuma das duas aparece na monitorização de processos. O daemon está ativo, o listener está ligado à porta, a regra está presente.

Porque é que os health checks passam

Um ping, um probe TCP connect e o path simulator de uma firewall criam cada um um novo fluxo ou avaliam a política de raiz, pelo que cada um recebe a decisão atual e correta. A leitura verde é verdadeira sobre o objeto errado. A pergunta a fazer à firewall não é o que faria com um pacote novo, mas o que está a fazer com os fluxos que já tem.

# the live flows from one source, with their state and NAT binding
conntrack -L -s <source>

# how full the table is
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

# the kernel's own report of a full table
journalctl -k | grep -i 'nf_conntrack: table full'

Um fluxo anterior à última alteração de encaminhamento que mostra um egress ou uma tradução que nenhuma regra atual produziria é a entrada a observar.

O que monitorizar

Chegada, não vivacidade. Linhas por minuto a entrar na base de dados do collector, mensagens por minuto no recetor de syslog, uma posição de replicação que avança. Uma linha plana é o alarme, diga o estado do processo o que disser.

Contadores face à expectativa. O contador de bytes na regra que transporta um stream cresce aproximadamente ao ritmo do stream. Uma regra que devia estar ocupada e está quase plana significa que os pacotes estão a corresponder a outra regra ou não estão a chegar de todo.

Ocupação da state table. Alerte sobre o nf_conntrack_count como fração do nf_conntrack_max muito antes de encher, e sobre a mensagem de tabela cheia do kernel, que de outra forma fica no log sem ser lida.

Verificações sintéticas com a forma do tráfego real. Um probe que mantém uma ligação de longa duração e empurra um registo através dela a intervalos, verificado na outra ponta, testa aquilo que se avaria. Um ping novo testa aquilo que não se avaria.

Depois de cada alteração de encaminhamento ou NAT, liste os fluxos mais antigos do que a alteração e decida deliberadamente se os limpa.

A correção é um bisturi

Apague o estado da origem afetada. O pacote seguinte cria uma entrada nova com a decisão atual e o stream retoma.

conntrack -D -s <source>

Um reboot ou um flush completo também funciona, e leva consigo todas as outras ligações ativas. Para uma tabela cheia, a correção é aumentar o nf_conntrack_max juntamente com o tamanho do hash, encurtar o timeout established onde não são precisos dias, e encontrar o cliente que está a criar os fluxos.