Em um site do cliente, a equipe de rede adicionou um firewall entre o cliente e o servidor. Isso está fazendo com que as conexões ociosas sejam desconectadas após cerca de 40 minutos de tempo ocioso. As pessoas da rede dizem que o firewall não tem tempo limite de conexão ociosa, mas o fato é que as conexões ociosas são quebradas.
Para contornar isso, primeiro configuramos o servidor (uma máquina Linux) com os keepalives TCP ativados com tcp_keepalive_time = 300, tcp_keepalive_intvl = 300 e tcp_keepalive_probes = 30000. Isso funciona e as conexões permanecem viáveis por dias ou mais. No entanto, também gostaríamos que o servidor detectasse clientes mortos e eliminasse a conexão, por isso alteramos as configurações para time = 300, intvl = 180, probes = 10, pensando que, se o cliente estivesse realmente ativo, o servidor sondaria a cada 300 (5 minutos) e o cliente responderia com um ACK e isso impediria o firewall de ver isso como uma conexão ociosa e matá-lo. Se o cliente estava morto, após 10 testes, o servidor abortaria a conexão. Para nossa surpresa, as conexões ociosas, mas vivas, são mortas após cerca de 40 minutos, como antes.
O Wireshark em execução no lado do cliente não mostra nenhum keepalive entre o servidor e o cliente, mesmo quando os keepalives estão habilitados no servidor.
O que poderia estar acontecendo aqui?
Se as configurações de keepalive no servidor forem time = 300, intvl = 180, probes = 10, seria de esperar que, se o cliente estivesse ativo, mas inativo, o servidor enviaria testes keepalive a cada 300 segundos e deixaria a conexão sozinha, e se o cliente estiver morto, ele enviaria um após 300 segundos, depois mais 9 sondas a cada 180 segundos antes de eliminar a conexão. Estou certo?
Uma possibilidade é que o firewall de alguma forma intercepte os testes keepalive do servidor e falhe em transmiti-los ao cliente, e o fato de ter um probe faz com que ele pense que a conexão está ativa. Esse comportamento é comum para um firewall? Não sabemos que tipo de firewall está envolvido.
O servidor é um nó Teradata e a conexão é de um utilitário cliente Teradata para o servidor de banco de dados, porta 1025 no lado do servidor, mas vimos o mesmo problema com uma conexão SSH, por isso achamos que afeta todas as conexões TCP.