Conexões presas no estado ESTABLISHED

Question

Em uma máquina Debian estou tendo várias conexões penduradas por cerca de 8 horas:

tcp6       0      0 192.168.1.35:56312      88.191.79.XXX:25        ESTABLISHED
tcp6       0      0 192.168.1.35:43352      88.191.79.XXX:25        ESTABLISHED
tcp6       0      0 192.168.1.35:56300      88.191.79.XXX:25        ESTABLISHED
tcp6       0      0 192.168.1.35:43350      88.191.79.XXX:25        ESTABLISHED

Todas as conexões são para a mesma máquina do servidor de correio remoto localizada em uma rede diferente. A máquina remota, na verdade, não vê essas conexões. O Tcpdump também não mostra atividade.

O cliente é um aplicativo Java e tem 4 encadeamentos bloqueados no soquete:

"MessageFeedbackQueueProc-Worker-202" prio=10 tid=0x00007f9c552f1800 nid=0x53d5 runnable [0x0000000043fb6000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)

Todas essas conexões acontecem em um pequeno período de tempo, antes e depois do qual tudo estava / está funcionando corretamente.

Interessante que o mesmo aconteceu na outra máquina Windows com o mesmo aplicativo Java no mesmo período de tempo. Neste caso, ele desativou o aplicativo de processar novas solicitações, pois todos os threads foram bloqueados pela leitura do soquete (nenhum tempo de espera ocorreu apesar do ponto final remoto morto). Outra coisa estranha: todos os threads em ambas as máquinas foram bloqueados após exatamente o mesmo comando SMTP (MAIL FROM), mas em momentos diferentes.

Por que isso pode acontecer e por que essas conexões não terminam?

    

Answer 1

Eu vi algo semelhante quando a conexão estava sendo finalizada em um firewall. Nenhum ponto de extremidade verá um FIN ou RST, portanto, de sua perspectiva, a sessão ainda está ativa e no estado Estabelecido. É possível que você olhe para os logs do firewall em ambas as extremidades para ver se a conexão está sendo terminada em qualquer um deles?

Também pode ser uma configuração de tempo limite de sessão ociosa no firewall em qualquer extremidade SE não houver dados percorrendo a conexão quando o período de tempo limite da sessão ociosa expirar.