Jumphost внезапно сбрасывает первые попытки подключения SSH MUX
Когда вы выполняете такую проверку, md5sum или sha1sum, вы должны быть уверены, что читаете тот же объем данных.
stat --printf '%s\n' file.iso
blockdev --getsize64 /dev/sr1
Если данные имеют размер, вы должны вычислять наименьший размер. сделать это:
dd if=file.iso bs=2k count=9000 | md5sum
dd if=/dev/sr1 bs=2k count=9000 | md5sum
В конце концов выяснилось, что это произошло из-за ошибок в основном маршрутизаторе Cisco 6059 FWSM и используемом брандмауэре ASA.
Ядро Linux версии 3 и 4 плохо работает с рандомизацией последовательности TCP и вызывает «случайные» проблемы при передаче больших файлов или другие неясные проблемы во многих соединениях, из которых SSH был более заметен. К сожалению, Windows, Mac и FreeBSD работают хорошо, так что это можно назвать ошибкой Linux.
Это была довольно неприятная ситуация, так как у нас были жалобы на то, что люди не могут скачивать случайные файлы с наших сайтов.
Each TCP connection has two ISNs: one generated by the client and one generated by the server. The ASA randomizes the ISN of the TCP SYN passing in both the inbound and outbound directions.
Randomizing the ISN of the protected host prevents an attacker from predicting the next ISN for a new connection and potentially hijacking the new session.
You can disable TCP initial sequence number randomization if necessary, for example, because data is getting scrambled. For example:
If another in-line firewall is also randomizing the initial sequence numbers, there is no need for both firewalls to be performing this action, even though this action does not affect the traffic.
Сначала я отключил Cisco Randomization во внутреннем основном маршрутизаторе, этого было недостаточно. После того, как рандомизация Cisco была отключена как в пограничных брандмауэрах, так и в основном маршрутизаторе/коммутаторе Cisco, проблема перестала возникать.
Для его отключения это что-то похожее на:
policy-map global_policy
class preserve-sq-no
set connection random-sequence-number disable
См. примечание Cisco Отключить рандомизацию последовательности TCP
Я также обнаружил несвязанную ошибку XLATE в FWSM для оптимизации NAT, которая включена по умолчанию, что вызывало ложные проблемы со связью, и поскольку основной маршрутизатор не отвечал за NAT, я отключил ее с помощью:
xlate-bypass
Enable xlate-bypass In both of the examples above, the xlates are created with the Ii flags. These flags indicate that the xlate is an identity translation (I) that originated on a high security (i) interface. By default, the FWSM will build these xlates for any traffic that does not match an explicit NAT/PAT rule. In order to disable this behavior, the xlate-bypass command can be enabled in FWSM 3.2(1) and later:
FWSM(config)# xlate-bypass
Остерегайтесь, это конфигурации по умолчанию, мы потратили месяцы на отслеживание этого в ходе внутреннего расследования, и несколько вовлеченных поставщиков, которых я не буду здесь называть, не смогли точно определить виновника этих конфигураций.
Se encontraron algunos sistemas con
net.ipv4.tcp_timestamps = 0
en /etc/sysctl.conf; todos los servidores que tienen el problema lo tienen habilitado.
Terminé tomando esta línea de los sistemas afectados y ejecutándola en todos los sistemas:
sudo sysctl -w net.ipv4.tcp_timestamps=1
Esperando más pruebas.
Ваши симптомы согласуются с тем, что компьютер в сети использует тот же IP-адрес, что и SSH-сервер. Проверьте MAC-адрес пакетов RST.
Используете ли вы какие-либо FW или устройства, пытающиеся оптимизировать TCP? У меня такой же опыт в сети, и оказалось, что это устройство выполняет оптимизацию TCP.