Прошивка 2.11.D.10.0-2 : теряет проброс порта 1723.

[Mkdlk5]

Приветствую!

после обновления прошивки с 2.11.D.10/0-1 перестал работать, но по-прежнему исправно демонстрируетсяся в web как действующий проброс tcp порта 1723.

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

Решить проблему удалось внесением правила проброса порта из cli.

С уважением,

Mkdlk5.

[Mkdlk5]

Описанный дефект исчез после понижения версии прошивки загрузкой из файла до 2.11.D.10.0-1.

Далее для меня неясное. Выполнил через cli удаление компонента dvb - тюнера.

Компонент обновился, автоматически обновилась и версия NDM до 2.11.D.10.0-2.

После этого обновления управление пробросом порта (во всяком случае, ip порта) через web - интерфейс работает добросовестно! Конечно, хорошо что роутер работает на самой свежей версии прошивки. Но почему устойчивый отказ исчез?

Кто - нибудь может объяснить, как такое возможно?

Mkdlk5.

[Le ecureuil]

Случаем nat-helper pptp или pptp сервер не удаляли?

[Mkdlk5]

31 минуту назад, Le ecureuil сказал:

Случаем nat-helper pptp или pptp сервер не удаляли?

После обновления на 2.11.D.10.0-2 пытался использовать встроенный pptp-сервер.

После выяснения, что он работает только с 40-битными ключами и любому клиенту потребуется вносить изменения в реестр,

предпочел вернуться на pptp сервер внутри локальной сети. Вот тут-то и обнаружилось, что порт 1723 при отключении встроенного pptp сервера снаружи перестает быть доступен. Пробное удаление - возвращение компонентов pptp сервер и ALG (pptp) к решению не привело, снаружи порт по-прежнему был недоступен.

С помощью поддержки в селф-тесте была обнаружена аномалия:

Цитата

Добрый день. Проблема в том, что у вас в netfilter нет правил в цепочке PREROUTING 

Т.е в конфиге у Вас пробросы созданы:

ip static tcp PPPoE0 1723 bc:ee:7b:db:6a:9e 1723 !pptp на сервер
ip static udp PPPoE0 500 bc:ee:7b:db:6a:9e 500 !IKE protocol for l2TP 
ip static udp PPPoE0 4500 bc:ee:7b:db:6a:9e 4500 !NAT-T for l2TP

А вот в netfilter их нет:

== Chain _NDM_STATIC_DNAT ==
-> Chain default policy: RETURN

Поэтому тут возникает проблема 
На старой версии ПО такое было, но разбираться в ней уже нет возможности 
Поэтому нужно попробовать пересоздать все правила проброса заново 

Пересоздание которых через web-интерфейс, как выяснилось, эффекта (открытия порта) не дает.

А вот команда ip static tcp PPPoE0 1723 [ip address] - эффект дала.

Дефект воспроизводился устойчиво, многократно.

[r13]

@Mkdlk5

По умолчанию 40бит, в cli можно включить 128

[Mkdlk5]

Спасибо, буду знать! Но я увидел при копирование файлов через VPN IpSec Xauth, что один пользователь в один поток кладет мой Keenetic III на обе лопатки: 90-100% загрузка процессора, производительность 19MB. А пропуск транзитного pptp практически на скорости wan не нагружает процессор более, чем на 31%. А сервер внутри сети при обработке соединения показывает рост нагрузки в пределах 1%.

Сделал вывод, что если внутри сети есть включенный 24/7 компьютер, лучше входящие VPN соединения серверить ему.
В новых Кинетиках, возможно, все иначе. Однако для ненагружающих задач встроенным серверам Кинетика цены нет. За что и любим

[vk11]

4 часа назад, Mkdlk5 сказал:

я увидел при копирование файлов через VPN IpSec Xauth, что один пользователь в один поток кладет мой Keenetic III на обе лопатки: 90-100% загрузка процессора, производительность 19MB.

...

лучше входящие VPN соединения серверить ему.

А зачем пользователям гонять файло? Что-то мне подсказывает, что у вас офисная сетка. Гораздо гораздее использовать RDP over VPN.

[Mkdlk5]

Верно подсказывает ;). Кроме RDP бывают потребности погонять файлы обновлений некоторых справочных правовых систем.

Это не жестко, но производительность компьютера действительно несколько выше, чем у устройства общей мощностью 12Вт. Но например, для редкого подключения с планшета - мобильного использую Кинетик. 

 

[vk11]

В 26.11.2021 в 20:44, Mkdlk5 сказал:

Верно подсказывает ;). Кроме RDP бывают потребности погонять файлы обновлений некоторых справочных правовых систем.

Тогда Peak, там внутри неонка ARM

[Mkdlk5]

😉.. и думатель? 
Аппаратик очень устраивает. Иначе бы столько лет не пользовался. 
И дефект прошивки обнаруженный здесь бы не расписывал.

На ARM не переманивайте, для случая   качать и нагружать ARM Ксеону не товарищ.

Лучше поддержите запрос проверить - исправить прошивку.

 

[Mamay]

6 часов назад, Mkdlk5 сказал:

Лучше поддержите запрос проверить - исправить прошивку.

Нету проверять. Некому. Вся поддержка представлена тут в одном лице и это лицо уже в третьем посте данного топа отметилось.

[Mkdlk5]

Я тут человек новый.
Простодушно исполнил правило "нашел багу - напиши". Не следовало?

[Mamay]

11 минуту назад, Mkdlk5 сказал:

Я тут человек новый.
Простодушно исполнил правило "нашел багу - напиши". Не следовало?

Всё верно сделали. Уповать на быстрое решение не следует. Вы тут пока пилите self-test и всё как положено.

[Mkdlk5]

То, что "неофициальная поддержка" и развитие имеет быть, уже очень много.
И дай ей бог разобраться и починить, если сможет и когда сможет.

[Le ecureuil]

В 27.11.2021 в 23:51, Mkdlk5 сказал:

😉.. и думатель? 
Аппаратик очень устраивает. Иначе бы столько лет не пользовался. 
И дефект прошивки обнаруженный здесь бы не расписывал.

На ARM не переманивайте, для случая   качать и нагружать ARM Ксеону не товарищ.

Лучше поддержите запрос проверить - исправить прошивку.

 

Вот это кстати вы зря так категорично, хороший ARM с CE отличается от зиона не на порядок, а всего в пару раз (ну условно в OpenVPN 200 мбит против 500 на зионе).

[Le ecureuil]

В 26.11.2021 в 13:13, Mkdlk5 сказал:

После обновления на 2.11.D.10.0-2 пытался использовать встроенный pptp-сервер.

После выяснения, что он работает только с 40-битными ключами и любому клиенту потребуется вносить изменения в реестр,

предпочел вернуться на pptp сервер внутри локальной сети. Вот тут-то и обнаружилось, что порт 1723 при отключении встроенного pptp сервера снаружи перестает быть доступен. Пробное удаление - возвращение компонентов pptp сервер и ALG (pptp) к решению не привело, снаружи порт по-прежнему был недоступен.

С помощью поддержки в селф-тесте была обнаружена аномалия:

Пересоздание которых через web-интерфейс, как выяснилось, эффекта (открытия порта) не дает.

А вот команда ip static tcp PPPoE0 1723 [ip address] - эффект дала.

Дефект воспроизводился устойчиво, многократно.

Так, а у вас mac-то правильный? В сети доступен? В списке хостов светится как online?

[Mkdlk5]

Рад видеть!

Цитата

Вот это кстати вы зря так категорично, хороший ARM с CE отличается от зиона не на порядок, а всего в пару раз (ну условно в OpenVPN 200 мбит против 500 на зионе).

Спасибо. Буду знать - для выбора в соответствующем случае.

В отношении активного Keenetic списка хостов. Если я верно понял вопрос:

arp говорит, что хост светится...

Но позволю себе напомнить, что проблема с транзитом pptp после перепрошивки из файла и последующего обновления из Вашего репозитория изволила исчезнуть. И на текущий момент "мы так и не знаем, чем Вы болели".