Jump to content
Калькуляторы

SNR-CPE поддержка, опыт эксплуатации, регрессии, результаты тестирования, общие вопросы

On 1/31/2018 at 12:41 AM, CHIPSET7 said:

@RingoAl Если ставите уже на существующее правило, то так не сработает. Надо: Удалить правило -> Применить -> Добавить заново поставив флаг -> Применить.

Я сделал как вы предложили WAN  TCP&UDP  80  192.168.0.10    80   х   server , настройка Nat loopback сохранилась, но из локальной сети по внешнему адресу внутренний сервер так и не доступен.

Share this post


Link to post
Share on other sites
4 hours ago, CHIPSET7 said:

@Condorious В соседней теме недавно обсуждалось.

 

Спасибо, настройка Nat loopback сохранилась, но внутренний сервер по прежнему не доступен по внешнему адресу.

Share this post


Link to post
Share on other sites

Рожу роутера с 80 порта перенесите для начала на другой порт в misc. Нельзя делать петли для портов используемых сервисами роутера. Более того у вас http по udp ходить начал чтоль, на кой чёрт правило для обоих протоколов добавили?

 

На доступе что? IPOE надеюсь? Ибо если PPPOE/L2TP/PPTP и прочий VPN то правило вообще не верно.

 

Зачем дублируете в нескольких темах? Ждёте пока вытру из обоих?

Share this post


Link to post
Share on other sites

Там сюда послали, там тоже отписался, что не помогло.

Здесь было ближе к теме, но тоже не помогло.

На доступе авторизатор Кабинета, морду роутера перевесил на 90 порт, переписал правило с петлёй, пытаюсь что WAN    TCP    80    192.168.0.10    80, что VPN    TCP    80    192.168.0.10    80 писать, всё равно "The connection has timed out".

Share this post


Link to post
Share on other sites

А по внутреннему-то IP заходит?

 

У меня никаких проблем не возникло после пересоздания правил с нуля и сразу с галкой.

Share this post


Link to post
Share on other sites

Авторизатор кабинета это не VPN прото его впихнуть было некуда вот тиснули в VPN. Так что ещё раз но с правилом через WAN.

Share this post


Link to post
Share on other sites

По внутреннему адресу заходит, правило написано через WPN, не помогает :0((

Вот ну чего тут можно неправильно настроить?

wive.png

Share this post


Link to post
Share on other sites

ХЗ, ту логику не трогал никто лет 300, да и вон рядом люди говорят, что ничего не сломалось с тех пор и работает. Видимо дело не в "бобине".

 

Пишите на wifi@nag.ru пусть повторяют, разбираются и т.д. В пределах бесплатного для НАГ лимит исчерпан.

Share this post


Link to post
Share on other sites

@Condorious Может действительно провайдер чудит? Надо же как-то проверять, либо напрямую без маршрутизатора(если возможно), либо на других сервисах. Есть же встроенный веб-сервер(рожа), можно удалить созданное правило для 80-го порта, вернуть роже 80-ый,  временно выставить рожу наружу(выбрав под номером порта "WAN & LAN") и попробовать зайти на него по внешнему адресу. Это для начала. И не забудьте потом вернуть назад! Если не выйдет, то дело в другом.

Share this post


Link to post
Share on other sites

Кстати да есть момент. Если у провайдера адресация на WAN перекрывает адресацию в LAN то там тоже вместо лупбэка будет пролёт сразу в его сеть.

 

У кабинета я не помню как именно доступ организован для белоайпишников.

Share this post


Link to post
Share on other sites

Провайдер не чудит, проброс портов на ZYXEL Keenetic Giga работает с полпинка. Тут проблема в роутере точно.

Попробую в НАГ написать.

Share this post


Link to post
Share on other sites

У вас проброс и тут работает (или не работает? из инета-то пускает хоть?). У вас почему-то проблема с нат лупбэк (правда учитывая что нат лупбэк эт костыль с правкой содержимого пакетов налету причём между локальными клиентами, как бы могут быть подвыверты, нат лупбэк не нормальная сущность, и добавлена только ради стонов 2,5 юзверей за последние 10ть лет). Почему ХЗ. Надо разбираться, вот пусть берут и разбираются. Мне сиё действо не оплачено и у себя на коленке я уже проверил и проблем не обнаружил, значит надо дальше разбираться с вашей конфигурацией включая что там у провайдера и что в сети, где-то есть какой-то нюанс.

 

И вопрос не в чудесах провайдера, а в возможном пересечении диапазонов адресов со стороны LAN и со стороны WAN. Я ХЗ какие дефолтовые адреса юзает зюхель у себя, или что там у кабинета по адресации. Но нет тут никаких чудес и быть не может.

 

Был бы комплексный какой протокол, можно было бы попробовать ещё offload в HW_ONLY переключить в misc. Но тут http как бы пофигу.

 

Кстати попробуйте ради интереса в миск в offload engine переключить в HW only режим оффлоада. Или вообще вырубить. Сотку оно и в софт режиме на IPOE вывезет.

 

Предложил бы посмотреть на то, что происходит в нетфильтре по выводу iptables -L -v -n -t nat т.е. есть ли вообще хоть один пакет у вас по правилу лупбэка. Но см выше.

 

Ну и на всякий рестартануть девайс через Administrator->Save&Reboot может с кабинетовским аутентификатором чего не учёл на эту тему. 500 лет туда не заглядывал, могло что-то в процессе и сломаться. Но это надо садиться и разбираться.

 

А пока мы играем в гадалок на кофейной гуще. Тарифный план Free. =)))

Share this post


Link to post
Share on other sites

Походу нашёл. В общем при рефакторинге web нумерацию кое-то поменял для типов VPN да не везде... В итоге lanauth обрабатывается как VPN, а не как авторизатор и часть логики нетфильтра генерируется не верно. Касается только кабинета. Скорее всего в этом и есть проблема. Как бы всякие аутентификаторы эт экзотика, потому не проверяю на регулярной основе. Когда уже они блин выкинут это дело и перейдут на нормальный IPOE без костылей... Хотя если посмотреть что их РТК купил, то лучше уж так, чем PPPOE.

 

Сейчас соберу на проверку исправленную версию.

 

Фиг с ним, будет ещё подарок NAG.

 

Share this post


Link to post
Share on other sites

Упс, пробежался ещё нашёл ещё 2 нестыковки по kabauth в общем позже на http://wive-ng.ru залью финальную 7.0.13 проверите.

Share this post


Link to post
Share on other sites

Залил, пробуйте https://sourceforge.net/projects/wive-ng/files/wive-ng-mt/

 

Вроде просмотрел везде где обрабатываться должно это дело и мог или упустить или могли потерять при рефакторинге. Это объясняет почему у остальных проблем не было.

Share this post


Link to post
Share on other sites

Спасибо за отклик!

Снаружи по http всё открывается, проблема доступа к локальному серверу по внешним адресам только из этой же локальной сети.

Залил 7.0.13, не помогло.

Изменения настроек NAT offload mode не на что не влияют.

 

[Wive-NG-MT@/]# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 27 packets, 2331 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   27  2331 port_forward_pre  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
   12  1107 MINIUPNPD  all  --  eth2.2 *      !224.0.0.0/4          0.0.0.0/0           
   12  1107 MINIUPNPD  all  --  eth2.2 *       0.0.0.0/0            0.0.0.0/0           

Chain INPUT (policy ACCEPT 13 packets, 1067 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 3 packets, 161 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 3 packets, 161 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    5   318 port_forward_post  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    2   157 SNAT       all  --  *      eth2.2  192.168.0.0/24       0.0.0.0/0            to:92.54.73.68
    0     0 MINIUPNPD-POSTROUTING  all  --  *      eth2.2  0.0.0.0/0           !224.0.0.0/4         
    1    52 MINIUPNPD-POSTROUTING  all  --  *      eth2.2  0.0.0.0/0            0.0.0.0/0           

Chain MINIUPNPD (2 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain MINIUPNPD-POSTROUTING (2 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain port_forward_post (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  tcp  --  *      *       192.168.0.0/24       192.168.0.10         tcp dpt:22
    0     0 MASQUERADE  tcp  --  *      *       192.168.0.0/24       192.168.0.10         tcp dpt:80

Chain port_forward_pre (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            92.54.73.68          tcp dpt:37 to:192.168.0.10:22
    0     0 DNAT       tcp  --  eth2.2 *       0.0.0.0/0           !192.168.0.0/24       tcp dpt:37 to:192.168.0.10:22
    0     0 DNAT       tcp  --  br0    *       0.0.0.0/0            92.54.73.68          tcp dpt:80 to:192.168.0.10:80
    0     0 DNAT       tcp  --  eth2.2 *       0.0.0.0/0           !192.168.0.0/24       tcp dpt:80 to:192.168.0.10:80

 

Что это означает я не понял.

 

Так же сделал проброс для SSH с 37 внешнего порта на 22 порт локального сервера, при попытке законнектиться по внешнему IP адресу и 37 порту, проброс корректно отрабатывает и пускает меня по SSH на локальный сервер (до обновления прошивки не пускало).

 

Проблема с пробросом именно по 80 порту http.

 

 

Edited by Condorious
Очепятка

Share this post


Link to post
Share on other sites

О_0

Заработало.

0_О

После того, как пробился по SSH, перенаправление 80 порта тоже заработало.

Очень странно, несколько раз перезагружал же роутер, у него мозги наместо должны были раньше встать, после обновления прошивки.

Сейчас всё работает, спасибо огромное за помощь!

Визуально, роутер работает чуть быстрее, чем зюксель первая гига.

Share this post


Link to post
Share on other sites

Вероятнее всего дело было в стэйтах на вашем клиенте (трафика то по правилам как видите 0 было, т.е. до роутера не долетали ваши запросы). Надо было клиента ребутнуть после обновления на 7.0.13 было бы быстрее. А так пока принудительно не обновились при поптке коннекта к тому же хосту но по новому порту. Ну или пока таймауты не истекли. Опять же зависит от клиента и реализации в нём.

Share this post


Link to post
Share on other sites

Ещё экспериментальным путём установил, что если включаешь режим NAT offload mode, то проброс портов перестаёт работать.

Моло ли у кого ещё проблемы с пробросом возникнут.

Share this post


Link to post
Share on other sites

Не выдумайте. Проброс работает с включенным оффлоадом хоть софтовым, хоть комплексным хоть хардварным.

 

Могут возникнуть проблемы с Nat Loopback на комплексных протоколах или в не совсем корректной сети при комплексном или чисто софтовом режиме.

 

Тут уж выбирайте сами. Для IPOE/PPPOE можно вместо комплексного режима смело использовать чисто Hardware режим. Для L2TP/PPTP лучше отказаться от NatLoopback  чем отключать софтовый оффлоад.

 

Почему у вас проблема проявляется на http я ХЗ. Не должно быть и у себя повторить не смог.

Share this post


Link to post
Share on other sites

В моём случае в совтовом и комплексном режиме проброс портов не отрабатывает. Пробовал несколько раз.

В хардварном режиме NAT offload mode проброс портов заработал.

Использую Nat Loopback, без него у меня так же порты не пробрасываются.

После нескольких дней теста роутера с Wiwe-NG-MT прошивкой, убедился что SNR роутер с ней работает быстрее, чем более дорогие роутеры с родными прошивками, LEDE и DD-WRT.

Share this post


Link to post
Share on other sites
1 час назад, Condorious сказал:

В моём случае в совтовом и комплексном режиме проброс портов не отрабатывает. Пробовал несколько раз.

Использую Nat Loopback, без него у меня так же порты не пробрасываются.

 

Чудес не бывает. Если бы я сам не использовал бы проброс поров на IPOE без всяких лупбэков и не сам бы писал эту логику, то может и поверил бы и полез разбираться. Галка NAT Loopback лишь добавляет DNAT правила. И никак не влияет на сам проброс извне.

 

Ни одного правила для WAN он не добавляет.

 

Более того, сами себе противоречите:

Снаружи по http всё открывается, проблема доступа к локальному серверу по внешним адресам только из этой же локальной сети.

 

В любом случае закрыли тему. Если у кого-то ещё будет подобная проблема - вернёмся к ней. Но уверен дело не в "бобине".

 

 

 

Share this post


Link to post
Share on other sites

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

Но мне до сих пор не ясно, как достаточно не свежее китайское оборудование на русской прошивке работает гораздо быстрее, чем современное железо от уважаемых брендов.

Ну и практически все альтернативные прошивки тестировались.

Раньше на зюкселе если качаешь торренты, даже сайты еле открывались, балансировка нагрузки канала работала очень плохо, сейчас на SNR тореннты качаются быстрее, и при этом ещё ролики на трубе в HD вообще не тормозят.

Магия какая-то.

Share this post


Link to post
Share on other sites

У меня тут новый вопрос образовался.

Есть некоторое желание, чтобы роутер показывал чуть больше, для чего хочется в iptables прописать примерно это:

iptables -t raw -N lawfilter
iptables -t raw -A lawfilter -p tcp --sport 80 -m string --hex-string 'Location: http://фиг.вам.ru/' --algo bm --from 50 --to 200 -j DROP
iptables -t raw -I PREROUTING -j lawfilter

 

или, например, вот это:

iptables -t mangle -I PREROUTING -p tcp --sport 80 -m u32 --u32 "всякие шестнадцатиричные циферки" -j DROP
iptables -t mangle -I PREROUTING -p tcp --sport 443 -m connbytes --connbytes 1:4 --connbytes-mode packets --connbytes-dir reply -m u32 --u32 "ещё немного циферок" -j DROP

 

Но не знаю как добавить таблицу raw, и с PREROUTING отлуп.

Можно ли как-то это реализовать на MT7620?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now