Добрый день!

Имею в офисе роутер DI-824. Firmware Version: v1.06b21, Tue, Jun 10 2008.
Задача - обеспечить доступ к хостам во внутренней сети за этим роутером.
Что делаю:
1. Организую IPSec-VPN между офисным роутером и домашним 804м. Работает без проблем. Но - я не всегда дома и надо иметь "мобильный" заход.
2. Поднимаю виртуальный сервер для ssh (22й порт). Попадаю на заказанный хост, терминал работает, но... стоит только в терминале запутить mc, как усе накрывается черным экраном и никой реакции ни на что. Можно только сессию прервать с моей стороны.
3. Поднимаю аналогичный виртуальный сервер на маршрутизаторе конкурирующей фирмы (TP-LINK) и такой проблемы не вижу. mc прерасно открывается и работает.

Вопрос простой и традиционный. Кто виноват и что делать?

Каким клиентом SSH пользуетесь?
Что за терминал за роутером?

_________________
Форум не подразумевает под собой быстрый ответ, хотите быстрый и квалифицированный ответ - звоните в техподдержку компании D-Link 8-800-700-5465

Ось везде - Fedora. В локальной сети версия 12. ядро 2.6.32.14-127.fc12.x86_64.
ssh - openssh-server-5.3p1-19.fc12.x86_64
mc на сервере - mc-4.7.3-0.1.fc12.x86_64. Ситуация наблюдалась и на прежней версии mc.

Дома - федора 13я. Ядро 2.6.33.6-147.fc13.i686.PAE, ssh - openssh-5.4p1-3.fc13.i686

Да, надо уточничь, что через работающий с ssh TP-LINK я попадаю на другой сервер с 13й федорой. И указанной проблемы не вижу. Черный экран вместо mc появляется только в режиме виртуального SSH-сервера на D-LINK (я там еще и 22й порт на новый адрес сажаю). Обычные терминальные команды (типа cat, ls и иже с ними) работают без проблем. Если же я иду на этот же сервер через IPSec VPN, поднятый на этом же роутере, то никаких проблем нет и с mc. mc в черный экран в этом случае не валится. Поэтому собственно на ось сервера я грешить не склонен.
==================
неуверенная догадка - надо попробовать поколдовать с величиной MTU. Вполне возможно, что дефолтные 1500 не везде пролезают. Но это только вечером.

Попробуйте MTU выставить в 1400 и запустить mc.

_________________
Форум не подразумевает под собой быстрый ответ, хотите быстрый и квалифицированный ответ - звоните в техподдержку компании D-Link 8-800-700-5465

Догадка оказалась верной. При MTU=1400 на внешнем интерфейсе сервера всё заработало.

А если за DI-824VUP стоит несколько компов, на всех компах на сетевых интерфейсах придется менять MTU? Как-нибудь с помощью самого DI-824 решается эта проблема?

Просто у меня сейчас 3 девайса этих DI-824 в удаленных офисах. За каждым из них небольшая сеть. Плюс приходные-уходные ноуты с Wi-Fi. Все три девайса держат VPN с DFL-800 и имееют данную проблему. Однако есть DFL-200, и DFL-210 которые также держат VPN c этим же центральным DFL-800 и у них данной проблемы нет.

То есть за DFL-2xx, большие сети 192.168.x.1/24, за DI-824 сети 192.168.124.1/28, на втором 192.168.124.17/28 и на третьем 192.168.124.33/28. Дальше вероятно будет больше. И руками менять MTU на сетевых картах компов как-то не впечатляет.

Пока подобрал с помощью TCPOptimizer MTU 1406 и выставил данный MTU на нескольких компьютерах. С таким MTU пакеты не дефрагментируются и скорость по VPN у этих машин стала нормальная.

Единственное что хочу отметить, что все DI-824 имеют доступ в интернет через PPPoE и в соединении PPPoE у них стоит MTU 1492. А DFL-2xx у которых нет данной проблемы получают доступ в интернет от провайдеров на прямую по статичному IP.

В соединении PPPoE пробовал ставить MTU ниже 1492, но это не помогает. Помогает только установка MTU на сетевых картах компьютеров которые за DI-824. Как решить проблему не изменяя настройки каждого компа в отдельности?!

Прошивки на DI-824 попробовал v2.10, Mon, Dec 29 2008 и V2.10b10(beta01), Tue, Jun 08 2010. Проблема и на предпоследней и на новой.

Up.

Up.