Solução não muito satisfatória, mas o nosso parceiro tinha um IPS que tinha sido atualizado automaticamente com novas regras / assinaturas no fim de semana que estava causando esse comportamento. Eles conseguiram resolver isso para nós agora.
Eu tenho um problema que estou tentando entender. Eu tenho um servidor que é hospedado por um parceiro de negócios em sua rede, mas minha equipe é responsável pela instalação e configuração de software para este servidor (na verdade, existem 3 servidores todos exibindo o mesmo comportamento). Como parte da configuração, estamos tentando copiar arquivos via rsync (por SSH), mas estamos enfrentando problemas que nós e nossos parceiros não entendemos.
Essencialmente, parece que somos capazes de rsync arquivos que são menos de 32768 bytes, mas depois que a conexão pára. Estamos fazendo isso através do SSH e eu posso obter um shell responsivo no servidor. Estou conectando pela internet, mas tentei de dois locais com os mesmos resultados. Aqui está um exemplo do que vejo:
rsync -aP ~/Downloads/file.zip servername:~ -vvv
opening connection using ssh servername rsync --server -vvvlogDtpr --partial . "~"
building file list ...
[sender] make_file(file.zip,*,2)
1 file to consider
server_recv(2) starting pid=2610
send_file_list done
send_files starting
received 1 names
recv_file_list done
get_local_name count=1 /home/me
generator starting pid=2610
delta-transmission enabled
recv_files(1) starting
recv_generator(file.zip,0)
send_files(0, /Users/me/Downloads/file.zip)
send_files mapped /Users/me/Downloads/file.zip of size 54965002
calling match_sums /Users/me/Downloads/file.zip
file.zip
32768 0% 0.00kB/s 0:00:00
Isso vai parar por alguns minutos e, eventualmente, o tempo limite. Eu capturei os pacotes do meu lado enquanto eu não sou particularmente versado em ler capturas de pacotes, parece que o lado do servidor pára de responder por alguns minutos e, eventualmente, redefine a conexão. Eu encontrei um snippet tshark em outra pergunta que eu ajustei um pouco para obter isso:
tshark -r ~/rsync-timeout.pcap -q -z io,stat,20,"COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission","COUNT(tcp.analysis.duplicate_ack)tcp.analysis.duplicate_ack","COUNT(tcp.analysis.lost_segment) tcp.analysis.lost_segment","COUNT(tcp.analysis.fast_retransmission) tcp.analysis.fast_retransmission"
===================================================================================
| IO Statistics |
| |
| Duration: 395.924510 secs |
| Interval: 20 secs |
| |
| Col 1: COUNT(tcp.analysis.retransmission) tcp.analysis.retransmission |
| 2: COUNT(tcp.analysis.duplicate_ack)tcp.analysis.duplicate_ack |
| 3: COUNT(tcp.analysis.lost_segment) tcp.analysis.lost_segment |
| 4: COUNT(tcp.analysis.fast_retransmission) tcp.analysis.fast_retransmission |
|---------------------------------------------------------------------------------|
| |1 |2 |3 |4 | |
| Interval | COUNT | COUNT | COUNT | COUNT | |
|--------------------------------------------| |
| 0 <> 20 | 0 | 0 | 0 | 0 | |
| 20 <> 40 | 2 | 1 | 0 | 0 | |
| 40 <> 60 | 13 | 0 | 0 | 0 | |
| 60 <> 80 | 4 | 0 | 0 | 0 | |
| 80 <> 100 | 4 | 0 | 0 | 0 | |
| 100 <> 120 | 0 | 0 | 0 | 0 | |
| 120 <> 140 | 4 | 0 | 0 | 0 | |
| 140 <> 160 | 0 | 0 | 0 | 0 | |
| 160 <> 180 | 0 | 0 | 0 | 0 | |
| 180 <> 200 | 4 | 0 | 0 | 0 | |
| 200 <> 220 | 0 | 0 | 0 | 0 | |
| 220 <> 240 | 4 | 0 | 0 | 0 | |
| 240 <> 260 | 0 | 0 | 0 | 0 | |
| 260 <> 280 | 4 | 0 | 0 | 0 | |
| 280 <> 300 | 0 | 0 | 0 | 0 | |
| 300 <> 320 | 4 | 0 | 0 | 0 | |
| 320 <> 340 | 0 | 0 | 0 | 0 | |
| 340 <> 360 | 4 | 0 | 0 | 0 | |
| 360 <> 380 | 0 | 0 | 0 | 0 | |
| 380 <> Dur | 0 | 0 | 0 | 0 | |
===================================================================================
Eu posso ver que isso não é ótimo, mas não tenho certeza do que isso me diz. Eu posso ver no rastreamento de pacotes que não há resposta do servidor (ou nenhuma que me atinja) por alguns minutos e, finalmente, um RST está configurado e ambos os lados desligados.
O final do meu rastreio de pacotes visto com tshark é assim:
... everything seems ok before this point
429 45.647732 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=15846 Win=60288 Len=0 TSval=8701862 TSecr=552453169
430 45.714775 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=17254 Win=63232 Len=0 TSval=8701928 TSecr=552453237
431 45.748600 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=18662 Win=64128 Len=0 TSval=8701963 TSecr=552453237
432 45.821013 1.2.3.4 -> 192.168.1.18 TCP 66 22→53839 [ACK] Seq=2438 Ack=21478 Win=64128 Len=0 TSval=8702035 TSecr=552453237
433 47.331298 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408)
434 49.243984 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188)
435 49.243989 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188)
436 49.244199 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188)
437 49.244203 192.168.1.18 -> 1.2.3.4 SSHv2 882 Client: [TCP Retransmission] , Encrypted packet (len=816)
438 52.678673 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188)
439 52.678677 192.168.1.18 -> 1.2.3.4 SSHv2 1254 Client: [TCP Retransmission] , Encrypted packet (len=1188)
... more of the same ...
472 309.358046 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408)
473 309.358166 192.168.1.18 -> 1.2.3.4 SSHv2 222 Client: [TCP Retransmission] , Encrypted packet (len=156)
474 335.714554 1.2.3.4 -> 192.168.1.18 TCP 60 22→53837 [RST, ACK] Seq=4050 Ack=5018 Win=0 Len=0
475 352.579591 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408)
476 352.579592 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408)
477 352.579595 192.168.1.18 -> 1.2.3.4 SSHv2 1474 Client: [TCP Retransmission] , Encrypted packet (len=1408)
478 352.579596 192.168.1.18 -> 1.2.3.4 SSHv2 222 Client: [TCP Retransmission] , Encrypted packet (len=156)
479 395.924510 192.168.1.18 -> 1.2.3.4 TCP 54 53839→22 [RST, ACK] Seq=29014 Ack=2438 Win=131072 Len=0
Eu adoraria ter algumas ideias sobre o que podemos fazer para solucionar isso ou ajudar nosso parceiro a solucionar o problema. Eu sei que existem firewalls e switches entre mim e os servidores remotos (mas eu não sei os detalhes, exceto que eu deveria ter acesso irrestrito ao SSH). Acho que estou pensando que há algum problema de configuração de rede entre nós, pois o problema é o mesmo para todos os três servidores e não foi assim na semana passada.
Esse pode ser um problema de MTU. Você pode verificar rapidamente se é assim com:
ping -M do -s 1472 other.end.address
(1472 = 1500 - 20 (cabeçalho ip) - 8 (cabeçalho icmp)).
Você pode tentar restringir o problema com tracepath . Hoje em dia, coisas comuns que podem causar esse tipo de problema são VPNs / túneis / etc.
Se for o caso, considere ativar a Descoberta MTU do TCP Path:
sysctl -w net.ipv4.tcp_mtu_probing=1