У меня есть сервер в удаленном месте. При подключении к этому компьютеру с помощью SSH он продолжает отключаться со словами:
Read from remote host XXXX: Connection reset by peer
Connection to XXX closed.
Я сомневаюсь, что это проблема с подключением к Интернету на нашей стороне, потому что пинг на эту машину показывает тайм-ауты запроса через случайные промежутки времени. Я попытался даже пинговать Google, который также показал тайм-аут запроса.
Как я могу подтвердить, что это проблема с Интернетом / какова настоящая ошибка?
Больше информации:
У нас есть VPN-туннель между нашей сетью и удаленной сетью. Таким образом, я могу использовать удаленную машину ssh, используя один из локальных IP-адресов, которые она получает. и tracert к тому, что в 2-х надеждах завершился успехом.
Я бы посоветовал установить что-то вроде курение. Это даст вам статистику за период времени, которую вы можете использовать, чтобы превзойти своего интернет-провайдера и предоставить приличный сервис.
Я бы порекомендовал вам использовать команду traceroute. В окнах он сокращается до tracert.
например, откройте командную строку и введите следующее (-d означает не выполнять поиск в DNS):
tracert -d <your server ip address>
это даст вам список всех переходов, которые TCP-пакет достигает на пути к цели. Последний успешный переход перед тайм-аутом даст вам представление о том, где происходит сбой в Интернете. Это может быть ваш Wi-Fi, ваш интернет-провайдер или что-то еще.
Другая идея заключается в том, что иногда соединение SSH может быть прервано, потому что система считает, что соединение бездействует, и что ее можно разорвать. Это также может быть настройка вашего модема. Но я думаю, что traceroute даст вам хорошее представление о точке отказа. Если вы никогда не обнаружите сбой с помощью traceroute, я бы сказал, что, возможно, что-то активно разрывает ваше незанятое соединение. Посмотрите настройки типа Keep-Alive в вашем Wi-Fi роутере / DSL-модеме и т. Д.
Но опубликуйте свои выводы и давайте посмотрим, сможем ли мы помочь вам разобраться в этом вопросе.
удачи.
Запустите сетевой захват на своем компьютере, когда он подключен к удаленному компьютеру. Когда происходит отключение, посмотрите в захвате TCP RST (сброс) с удаленного компьютера. Если вы его нашли, значит проблема в удаленном компьютере. Если вы этого не сделаете, проблема где-то в связи между ними.
При всем уважении, я не имею в виду, что tracert дает сбой каждый раз. Я имею в виду, что когда один хост на пути не отвечает на tracert, это не означает, что проблема в этом хосте, и если вы часто используете tracert, вы увидите, что всегда кажется, что на пути всегда есть хост это не отвечает.
Проблема здесь в том, что соединение периодически обрывается. Если бы это было сложно, то хорошим выбором было бы использование tracert и ping. Ping и tracert - хорошие инструменты уровня сортировки, но они не помогут выявить причину периодических проблем. Tracert (как следует из названия) - это инструмент для отслеживания маршрута к удаленному хосту, и по своей природе он может сказать вам, существует ли путь или нет. Tracert - это не диагностический инструмент, который может сказать вам, почему хост не отвечает или сбрасывает пакеты. Единственный способ получить эту информацию - запустить сетевой захват на обоих концах соединения и, в идеале, если возможно, на каждой ссылке на пути.
Если я запускаю постоянный ping и постоянный tracert для удаленного хоста, и я получаю неудавшийся ответ ping от удаленного хоста и в тот же момент вижу, что промежуточный хост в tracert перестает отвечать, означает ли это, что этот промежуточный хост является проблемой ? Нет, это не так, и теперь был бы способ сопоставить два события, если бы я не выполнял захват сети для каждой ссылки на пути и мог бы анализировать данные на уровне пакетов.
Я просто предлагал начать поиск неисправностей с известных, измеримых компонентов, которыми являются два хоста на обоих концах соединения.
Я знаю, что у каждого свое мнение, и я не собираюсь начинать войну, поэтому приношу свои извинения, если кто-то обидится.
Есть ли у вас что-нибудь, что может регулировать или ограничивать скорость входящих SSH-подключений на машине, например iptables (Linux) или inetd.conf (FreeBSD)? Что произойдет, если вы подождете 5 или 15 минут перед повторной попыткой подключения?