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?

Две догадки:

  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.