У меня проблема, которую я пытаюсь понять. У меня есть сервер, который размещен бизнес-партнером в их сети, но моя команда отвечает за установку и настройку программного обеспечения на этом сервере (на самом деле есть 3 сервера, все демонстрирующие одинаковое поведение). В рамках конфигурации мы пытаемся скопировать файлы через rsync (через SSH), но мы сталкиваемся с проблемами, которые мы и наш партнер не понимаем.
По сути, кажется, что мы можем rsync-файлы размером менее 32768 байт, но после этого соединение останавливается. Мы делаем это через SSH, и я жестяная банка получить отзывчивую оболочку на сервере. Я подключаюсь через Интернет, но пробовал из двух мест с одинаковыми результатами. Вот пример того, что я вижу:
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
Это остановится на несколько минут и, в конечном итоге, произойдет тайм-аут. Я захватил пакеты со своей стороны, хотя я не особо разбираюсь в чтении захваченных пакетов, кажется, что сторона сервера перестает отвечать на несколько минут и в конечном итоге сбрасывает соединение. Я нашел фрагмент tshark на Другой вопрос который я немного изменил, чтобы получить это:
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 | |
===================================================================================
Я вижу, что это не очень хорошо, но я не совсем уверен, что это мне говорит. По трассировке пакетов я вижу, что сервер не отвечает (или не получает до меня) в течение нескольких минут, а затем, наконец, устанавливается RST и обе стороны вешают трубку.
Конец трассировки моего пакета при просмотре с помощью tshark выглядит так:
... 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
Я хотел бы получить некоторые идеи о том, что мы можем сделать, чтобы устранить эту проблему или помочь нашему партнеру устранить их конец. Я знаю, что между мной и удаленными серверами есть брандмауэры и переключатели (но я не знаю подробностей, за исключением того, что у меня должен быть неограниченный доступ по SSH). Полагаю, я думаю, что между нами возникла проблема с конфигурацией сети, поскольку проблема одинакова для всех трех серверов, и на прошлой неделе этого не было.
это мощь быть проблемой MTU. Вы можете быстро проверить, так ли это, с помощью:
ping -M do -s 1472 other.end.address
(1472 = 1500 - 20 (заголовок ip) - 8 (заголовок icmp)).
Вы можете попытаться сузить проблему с помощью tracepath. В настоящее время обычные вещи, которые могут вызвать проблемы такого типа, - это VPN / туннели и т. Д.
В этом случае рассмотрите возможность включения обнаружения MTU пути TCP:
sysctl -w net.ipv4.tcp_mtu_probing=1
Не очень удовлетворительное решение, но оказалось, что у нашего партнера была IPS, которая автоматически обновлялась новыми правилами / сигнатурами за выходные, что и вызывало такое поведение. Теперь они смогли решить эту проблему за нас.