SSH к удаленному серверу зависает, но работает локально (putty / cygwin / windows 10 для linux)

Question

У меня есть Linux-сервер под управлением openssh. Я могу подключиться к нему как из локальной сети, так и удаленно. Однако есть один клиент (ноутбук с Windows 10), который может подключаться к нему только локально. Когда я пытаюсь подключиться удаленно, аутентификация принимается, но клиент ssh на ноутбуке зависает и должен быть уничтожен с помощью Process Explorer. Я думал, что проблема может быть:

1. Брандмауэр Windows - Нет. Выключил, получил то же самое поведение.
2. Клиент SSH (Cygwin) - Нет. Получил то же поведение с замазкой.
3. Windows 10 - Нет. Я могу успешно подключиться удаленно с другой машины Win10.

Я попробовал новую установку как Cygwin & Putty.

Я попытался запустить ssh с несколькими параметрами -v и сравнить вывод с другой машиной Win10, которая может подключиться. Вывод был идентичным, до определенного момента:

Authenticated to <<IP REMOVED>>.
debug2: fd 5 setting O_NONBLOCK
debug2: fd 6 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

>>>  "bad" machine hangs here

debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Welcome to Linux Mint 17.3 Rosa (GNU/Linux 3.19.0-32-generic x86_64)

Welcome to Linux Mint

В редких случаях он продвигался дальше - один или два раза даже к приветственному сообщению - но соединение никогда не реагирует на ввод ввода.

Я попытался запустить sshd -d вручную на сервере и сравнить вывод между "плохим" удаленным сеансом и "хорошим" с другого клиента. Выход идентичен.

Подводя итог: кажется, что это не брандмауэр Windows, или клиентское программное обеспечение, или Win10, или переадресация портов на сервер, или DNS, или сам сервер. Проблема только в этом клиентском компьютере и только при подключении извне локальной сети. Это аутентификация успешно. И на клиентском компьютере работает тот же OS/ssh-клиент, что и на другом компьютере, у которого нет проблемы, и я не вижу в журналах ничего, что могло бы его отличить.

РЕДАКТИРОВАТЬ: я должен также упомянуть, SSH-подключение к другим удаленным серверам работает нормально со всех машин. Кажется, это просто пара сервер / клиент, и только при удаленном подключении.

ОБНОВЛЕНИЕ: см. Мои комментарии непосредственно ниже для получения дополнительной информации - проблема, кажется, специфична для локальной сети.

Какие дальнейшие шаги я могу предпринять, чтобы отладить его?

Answer 1

Мне кажется, что в момент зависания TCP-пакеты с сервера перестают доходить до клиента. Я думаю, что причина в том, что он иногда зависает в разных точках, а также потому, что проблема меняется в зависимости от конфигурации сети. Например, это может быть нежелательное взаимодействие между переадресацией портов, NAT и / или межсетевыми экранами. Но вопрос в том, как диагностировать, почему это происходит на одном клиенте, а не на другом. Я могу придумать два подхода:

• Вы можете попробовать мониторинг пакетов на сервере и клиенте и в точках маршрута, чтобы проверить, действительно ли пакеты теряются и в какой момент.

• Вы можете поэкспериментировать, чтобы попытаться найти связь между настройками сети и наличием или отсутствием проблемы на разных клиентах. Поменяйте местами все или некоторые сетевые настройки и IP-адреса между работающим и неработающим клиентом, чтобы увидеть, если это поменяет проблему.