Я получаю странное поведение с Ubuntu Server 10.04 64bit на двух наших новых серверах (оба свежих установки). У меня есть сервер ubuntu (такая же версия), развернутый на 4-5 других серверах без этой проблемы.
Первоначально я не могу установить ssh на новый сервер, пока я вручную не установлю адрес, который прослушивает ssh-сервер, в / etc / ssh / sshd_config. После подключения меня, кажется, выгоняют через случайные промежутки времени со следующей ошибкой:
Ошибка записи: сломана труба
Использование "ssh -vv" не показывает никакой другой информации. Когда меня выгоняют таким образом, я не могу восстановить соединение в течение другого, казалось бы, случайного периода времени. Иногда несколько секунд, иногда несколько минут. Если я запускаю netstat -nap | grep: 22, я вижу, что мое соединение все еще существует после ошибки записи. Кажется, я не могу повторно подключиться, пока это соединение не разорвется.
После одной из этих ошибок, если я перейду на сервер с консоли, перейду по ssh на другой компьютер, а затем попытаюсь снова подключиться к серверу, все будет работать нормально.
Использование «-o TCPKeepAlive = yes» на стороне клиента, похоже, ни на что не влияет. Я отключил на сервере iptables и ufw. AppArmor не показывает никаких принудительных профилей, и SELinux не установлен.
Мои журналы не сообщают об ошибках, и у меня нет настраиваемых конфигураций. Это коробочная установка. Обратите внимание, что когда я пытаюсь вернуться в систему после ошибки сломанной трубы, я получаю следующую ошибку:
ssh: подключиться к хосту 172.22.50.92 порт 22: в соединении отказано
И nmap больше не показывает порт 22 как открытый, хотя netstat на сервере сообщает, что он все еще прослушивает порт 22.
РЕДАКТИРОВАТЬ - Я не уверен, что это что-то значит, но я установил KVM на эти хосты, и я могу использовать ssh для гостей (также 64-битный сервер ubuntu) без каких-либо проблем.
ОБНОВЛЕНИЕ - я пробовал очистить openssh и переустановить с помощью apt. Я также очистил и установил openssh из исходников, но безуспешно. traceroutes и ping за ночь не показывают потери пакетов вообще.
ЕЩЕ ЕЩЕ ОДИН ОБНОВЛЕНИЕ. Похоже, Dell думает, что у нас плохая материнская плата на сервере. Заменив это, чтобы увидеть, решит ли это проблему.
Используйте mtr для проверки сети. Попробуйте команду вроде mtr -i 15 remotehost. Оставьте это в окне или используйте screen, чтобы можно было отсоединиться. Он должен улавливать любые проблемы с сетью. На большинстве моих систем потеря пакетов обычно составляет 0%.
РЕДАКТИРОВАТЬ: Что означает вывод arp -n показать для вашего IP-адреса до и после сброса ssh. Вы можете попробовать это на другом сервере в той же подсети. Для IP-адреса должен быть только один HW-адрес, и он не должен изменяться. Если это так, у вас есть конфликт IP-адресов.
Этот пост решил проблему: массовая потеря пакетов при подключении серверов к сети
Хорошо .. ооочень из того, что я могу предположить, взглянув на это ...
вы в основном получаете длительные отсеивания ..
1.) У вас плохое сетевое соединение ..
2.) Сеть, в которой находится сервер, имеет плохое сетевое соединение / плохой маршрутизатор / что-то плохое: P
3.) Ваши серверы имеют конфликтующие адреса / проблемное оборудование.
Мое решение ..
Выполните ping на ночь ... и посмотрите, сколько пакетов вы потеряете утром: D (просто чтобы увидеть, в правильном ли я направлении)
Надеюсь это поможет..
Вы можете получить нестабильные соединения с некоторыми комбинациями сетевых адаптеров и коммутаторов, когда автосогласование включено, и оно переходит в полудуплекс.
Используйте "ethtool eth0", чтобы проверить правильность настроек скорости и дуплексного режима, а также изменить их при необходимости.