Em um servidor de produção, automatizei tarefas que enviam os mesmos comandos SSH e quantidade de dados pela rede uma vez por minuto para um servidor de produção remoto. A única coisa que pode mudar são alguns valores no objeto. Este processo tem funcionado em um programa há anos sem problemas. Sem nenhuma alteração local, começamos a ter ocorrências aleatórias ECONNRESETe Connection lost before handshakeerros. Começou com alguns por dia e cresceu para vários por hora. O administrador do servidor de destino diz que seus logs não fornecem informações úteis... apenas diz Received disconnect from <origin_ip> port 21549:11or pam_unix(sshd:session): session closed for user <username>.
Como a conexão foi inicialmente bem-sucedida ( socket connected), ssh -vvvou o equivalente em minhas ferramentas ssh, não foi útil na coleta de dados adicionais quando a conexão foi interrompida antes que todos os dados fossem enviados. Às vezes, as conexões são interrompidas menos de 12 segundos após a conexão do soquete.
Corri mtr <destinatioin_ip>para inspecionar o trace e com 9 saltos só houve perda de pacotes no último salto, o destino. Geralmente seria entre 12% e 20%. Nunca menos de 6%. Mas como ele usa ping/ICMP, que às vezes é limitado, não acho que isso confirme de forma confiável um problema com a conexão ssh. Então corri mtr -T -P 22 <destination_ip>para verificar o SSH/TCP, que frequentemente mostra 0% de perda nos primeiros 8 saltos e até 29% de perda de pacotes apenas no salto 9, o destino. Porém, com menos frequência, às vezes mostra até 50% de perda de pacotes em cada um dos primeiros 8 saltos e nunca chega ao salto 9. Confuso.
Ao fazer testes como o acima ou apenas deixar as automações tentarem novamente por conta própria, eventualmente o servidor de destino bloqueará todas as minhas conexões SSH. Nesse ponto, ssh -vvv <destination_ip>ele travará e dirá que a conexão expirou:
ssh -vvv <user@destination_ip>
OpenSSH_7.6p1 Ubuntu-4ubuntu0.7, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "<destination_ip>" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to <destination_ip> [<destination_ip>] port 22.
debug1: connect to address <destination_ip> port 22: Connection timed out
ssh: connect to host <destination_ip> port 22: Connection timed out
Para resolver o problema connection timed out, o administrador do servidor de destino disse que reinicia o servidor ssh. Nesse ponto, posso me conectar novamente, mas as desconexões aleatórias continuam até serem completamente bloqueadas novamente.
pfSense é o firewall da rede do servidor de origem junto com os switches Ubiquiti. O firewall de origem não mostra conexões SSH bloqueadas e nunca mais do que 2 a 3 conexões ssh com o servidor de destino ao mesmo tempo.
O que foi dito acima é suficiente para sugerir que o problema pelo menos não é meu servidor e provavelmente é o servidor de destino (salto 9)? Há mais alguma coisa que eu deva examinar localmente para isolar se a causa for local?
Tenho controle total sobre o servidor de produção local. O problema é que, sem evidências suficientes para confirmar que o problema não é local, estou tendo dificuldade em escalar a equipe remota para fazer pesquisas adicionais.
Fim da história. Problema identificado. Nenhuma discussão sobre limitação de pings. Se eles não assumirem a responsabilidade pelo problema, avance.