У нас есть SFTP-сервер, который работал нормально, пока мы не добавили другого интернет-провайдера. Подключение к серверу SFTP не происходит через нового провайдера, я подтвердил это с помощью tracert
. На сервере также не было внесено никаких изменений. Но с тех пор время ожидания SFTP или SSH-соединений некоторых пользователей истекает / зависает, если выполненная команда имеет больший возврат. Вот сценарий:
ls
команда для моего корневого каталога возвращает небольшое количество файлов или папок, а затем показывает список файлов и папокls
Команда для моего корневого каталога больше, чем, скажем, 5 или 6 файлов или папок, тогда она зависает / время ожидания.Это случается не со всеми, но, похоже, с пользователями, которые находятся в другом городе ..
Я пробовал разные SFTP-клиенты (FileZilla и WinSCP). У обоих одна и та же проблема.
Я запустил WireShark на своем ПК (который находится за пределами нашей сети и за городом), когда время ожидания SFTP / SSH истекает, я вижу, что возникают ошибки повторной передачи и части не захваченного сегмента, что наводит меня на мысль, что может быть какой-то пакет потеря где-то между прыжками.
Expert Info (Note/Sequence): Retransmission (suspected)
Previous segment not captured (common at capture start)
Является ли SFTP / SSH чувствительным к потере пакетов? Разве SSH / SFTP не будет повторно передавать / подтверждать, чтобы избежать этих ошибок потери пакетов? Есть ли что-то в настройках сервера, которые я могу настроить, чтобы это работало?
Я считаю, что комментатор попал в точку, это классический пример проблемы с MTU (и MTU пути не определяет должным образом меньший MTU, необходимый для этого конкретного пути, который не работает). Вы должны проверить, что промежуточные устройства на пути, который дает сбой, правильно пропускают пакеты обнаружения пути MTU, и что нет промежуточных маршрутизаторов с излишне маленькими MTU. Вероятно, вы можете сузить его, отправив большие пакеты icmp размером до MTU на каждый переход по пути, чтобы обнаружить, где он дает сбой (хотя это не всегда работает).