Em um site do cliente, a equipe de rede adicionou um firewall entre o cliente e o servidor. Isso faz 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 nenhum tempo limite de conexão inativa, mas o fato é que as conexões inativas são interrompidas.
Para contornar isso, primeiro configuramos o servidor (uma máquina Linux) com 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 inoperantes e eliminasse a conexão. Alteramos as configurações para time = 300, intvl = 180, probes = 10, pensando que, se o cliente estivesse realmente vivo, o servidor investigaria a cada 300s (5 minutos) e o cliente responderia com um ACK e isso impediria o firewall de ver isso como uma conexão inativa e matá-lo. Se o cliente estivesse morto, após 10 testes, o servidor abortaria a conexão. Para nossa surpresa, as conexões inativas, 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 nenhuma keepalives entre o servidor e o cliente, mesmo quando as keepalives estão ativadas no servidor.
O que poderia estar acontecendo aqui?
Se as configurações de keepalive no servidor forem time = 300, intvl = 180, probes = 10, eu esperaria que, se o cliente estivesse ativo, mas ocioso, o servidor enviaria probes de keepalive a cada 300 segundos e deixaria a conexão em paz. o cliente está morto, ele enviava um após 300 segundos e mais 9 testes a cada 180 segundos antes de interromper a conexão. Estou certo?
Uma possibilidade é que o firewall esteja de alguma forma interceptando os probes de keepalive do servidor e falhando em transmiti-los ao cliente, e o fato de ter obtido um probe faz pensar 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 do 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, portanto acreditamos que isso afeta todas as conexões TCP.