SSH туннель к маршрутизатору периодически зависает. Проблема с TCP?

Что-то странное, что я заметил с момента обновления моего офисного маршрутизатора до Buffalo WZR-HP-G300NH. Когда я удаляю использование туннеля SSH, туннель будет «замораживаться» довольно часто. Замораживание длится 1-2 минуты каждый, после чего весь трафик, который застрял, догоняет. Очень раздражает использование VNC и пауза сессии каждые несколько минут.

Я использую следующую команду с моей локальной машины:

ssh -D 9000 root@my.router.hostname 

Я знаю, что весь роутер не замерзает, потому что я могу открыть еще один сеанс SSH, и все в порядке – пока он не замерзнет. Сеансы замораживания не зависят друг от друга. Оба будут периодически замирать, но не в то же время.

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

Если я перенаправляю порт VNC прямо на удаленный компьютер, проблема становится несколько лучше, поэтому я полагаю, что это скорее проблема TCP, чем SSH. Но я ничего не выношу.

Такое поведение сохранилось, несмотря на обновление прошивки до последнего dd-wrt, включая сборку, которая была вытащена несколько недель назад.

Это проблема с dropbear? Или с MTU? QoS?

2 Solutions collect form web for “SSH туннель к маршрутизатору периодически зависает. Проблема с TCP?”

Две догадки:

  1. Потеря пакетов. Не доверяйте «ping», который вы выполняете параллельно, поскольку потеря пакетов может влиять только на те потоки TCP по любой причине. Один простой способ обнаружить это – часто выполнять $ netstat -s -p|grep "segments retransmited" с обеих сторон (клиент и сервер ssh) во время сеанса SSH. Посмотрите, увеличивается ли счетчик, и в этом случае вы столкнулись с потерей пакетов в сеансах TCP на этом компьютере. Тем не менее, лучший способ – использовать tcpdump или wirehark для записи того, что происходит, и подтвердить, что происходят повторные передачи (они обычно отмечены красным от wirehark, но YMMV).

  2. Проблемы с MTU. Например, если вы пытаетесь перечислить содержимое большого каталога через SSH, может случиться, что объем передаваемых данных потребует фрагментации данных. Конечные точки будут использовать обнаружение MTU пути для определения количества отправляемых данных за раз. Но в некоторых случаях брандмауэр в пути может блокировать все ICMP-пакеты и, следовательно, прерывать обнаружение MTU пути, вызывая очевидные зависания. Это может быть трудно подтвердить и диагностировать. Самый простой способ обхода, который всегда работает, – это изменить MTU сетевого интерфейса с обеих сторон на низкое значение, например 1200 или 1000. Это может повредить вашей производительности, поэтому вам лучше не использовать это навсегда.

Вы пробовали просто перенаправить порт VNC (что это за 5900?)

 ssh -L 5900:127.0.0.1:5900 root@my.router.hostname 

Затем вы используете 127.0.0.1 при использовании своего клиента VNC.

  • Может ли nmap отображать только узлы с определенными портами?
  • Хранение огромных данных в ядре Linux
  • Где пропало / dev / tcp?
  • Как я могу отредактировать / proc / net / tcp?
  • Почему Linux не использует диапазон портов IANA Ephemeral?
  • Сброс TCP после SYN ACK, возможно, связанный с "no route to host"
  • Запуск сканирования локального порта и обнаружение открытых портов, но не знаете, для чего они используются?
  • Как создать прослушиватель TCP?
  • Какая часть недавней исправления TCP-буфера для Linux также применяется к SCTP?
  • Прозрачное проксирование TCP-соединений на порту (в основном, без доступа root)
  • Есть ли способ инкапсулировать RTP / RTSP / RTCP в одно TCP-соединение?
  • Interesting Posts
    Linux и Unix - лучшая ОС в мире.