Есть DNS-315, установленный за маршрутизатором (DFL-210). Задача - обеспечить доступ снаружи к WEB-интерфейсу прибора.
Делаю стандартный проброс портов с внешнего, например, 2280 на внутренний 80 и получаю следующее: первая, стартовая страница с формой для входа отображается нормально, но после нажатия на кнопку Login дальше ничего полезного не происходит. В разных браузерах это выглядит по-разному: в Chrome вообще всё тихо, IE говорит, что "не может отобразить эту страницу" (http://<addr>:<port>/cgi-bin/login_mgr.cgi), а FF определяет ситуацию как "Ошибку искажения содержимого" (Corrupted Content Error).

Для проверки, временно изменяю внешний порт на 80 - всё работает, как положено. На любой другой (пробовал выборочно) - фигня, описанная выше. Пробовал также запустить в этой сети прокси и доступаться к DNS через него: тоже без проблем. К сожалению, по условиям эксплуатации, ни один из этих вариантов не подходит для использования в штатном режиме.

Ещё интересный момент: после такой неудачной попытки входа в логе железки можно узнать, что в процессе этой попытки пользователь, оказывается, logged in. То есть, сам вход отрабатывается нормально, а проблема - с отображением.
Пробовал со всеми доступными прошивками DNS-315 - 1.00, 1.01 и 1.02beta - с одинаковым результатом.

На всякий случай: в этой сети через этот же DFL работает ещё несколько WEB-серверов. Они без проблем доступны по заданным внешним портам.

Есть ли какая-нибудь возможность заставить железку работать так, как нужно?
Может быть, можно как-то добраться до её файловой системы? Я бы взглянул на конфигурацию Apache...
В одной из тем этого форума читал о том, что её "прошивка" (rootfs?) хранится на вставленном в неё диске. Если его вынуть и подключить к компьютеру, получится ли там отредактировать что-то?

сделайте на DFL VPN $-)

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Я так и сделал, для стационарных удалённых пользователей. Но для мобильных, с их "зоопарком" устройств, такое решение получается, как минимум, неудобным, если вообще применимым.

На нем lighttpd, а не апач. Доступ к шеллу http://forum.ixbt.com/topic.cgi?id=11:42972-68#2064

весь мобильный зоопарк , умеет IPsec Over L2tp , рядом в вееке бегала инструкция для такого сервера на DFL.

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

А разве можно установить аддоны на DNS-315?

Нет, решение с туннелем здесь не подходит.

Хотелось бы услышать комментарий сотрудника службы поддержки D-Link. Всё-таки, речь идёт об ошибке во встроенном ПО устройства.

А разве там про аддоны что-то написано? Хотя fun_plug в какой-то степени и можно к аддонам отнести

Тормозил., разобрался с fun_plug, получил доступ к консоли, научился запускать копию lighttpd из комплекта fun_plug с возможностью редактирования конфигурационных файлов.
Сначала просто поменял порт для lighttpd на другой, который можно напрямую прокинуть наружу.
Не помогло. Но помогло понять, что происходит: обработчик /usr/local/modules/cgi/login_mgr.cgi, который запускается после нажатия на кнопку Login, после завершения своих "логиновых" дел запускает редирект на одну из страниц, например, /web/home.html. Беда в том, что он при этом теряет номер порта из первоначального URI. Т.е., вместо <IP>:<port>/web/home.html у него всегда получается <IP>/web/home.html. Отсюда и проблема, если внешний порт не равен 80.
Вторая беда - в том, что этот login_mgr.cgi - не скрипт, а исполняемый файл (ELF), так что быстро "починить" его не удастся.

Как бы это дело обойти? Заменить его на свой shell-скрипт, что ли, который будет сам проверять пароль и делать правильные редиректы?
Или "обернуть" его в скрипт и на выходе переписывать ответ?

Да, а если после такого логина перейти на ту же /web/home.html, дописав порт в адресную строку браузера, то дальше весь интерфейс работает нормально, как и должно быть. То есть, остальные 15 подобных *.cgi, которые используются в процессе работы, такой ошибки не имеют.

А кто-нибудь пробовал доступ с трансляцией порта на других моделях линейки DNS? Если где-то оно работает нормально, то, может быть, взять этот login_mgr.cgi из прошивки другого аппарата?