Le ecureuil

Хотелось бы понять, раз уж зашла речь - правильно ли я понимаю, что в 2.06 можно будет вместо сети на базе штатного PPTP-сервера использовать IPsec, терминируемый с обоих сторон на роутерах? Или все-таки на стороне сервера должна быть железка поумнее? Если KG2 сможет выступать сервером - будет ли совместимость с белыми кинетиками в качестве клиента? Сейчас у меня один KG2 является PPTP-сервером, другой KG2 и KG1 - клиенты, эпизодически подключаюсь с ПК, планирую подцепить простой первый кинетик, 4G II и тплинк с OpenWRT. Можно ли будет в таком виде на 2.06 перейти на IPsec, или белые кинетики на 2.04 не будут совместимы? В 2.06 реализована функция как клиента, так и сервера для site-to-site соединений, потому будет работать как между двумя кинетиками, так и между кинетиком и компом/железкой поумнее. Белые кинетики с 2.04 будут совместимы, если поставите в них ipsec из entware/keenopt и настроите, бекпорта именно как функционала NDMS туда не будет. В вашей схеме из-за ее высокой гетерогенности возможно стоит остаться на PPTP имхо. Настройть IPsec в такой среде даже для спецов может быть сложно, причем я не знаю адресации в вашей сети, а linux kernel xfrm не поддерживает перекрывающиеся подсети в IPsec SA, потому возможно придется городить GRE/IPIP/EoIP туннели поверх IPsec или NAT.

Для Keenetic II IPsec пока недоступен (будет в 2.06), потому надежным рабочим вариантом остается только PPTP.

Судя по логу здесь явно что-то не то с сетью или pptp-сервером: соединение с ним пытается установиться и на полпути разывается, даже не достигая стадии PPP. На других версиях прошивки работает нормально?

Пришлите пожалуйста self-test с включенной через telnet командой > interface PPTP0 debug Это должно прояснить все вопросы. Еще подскажите - а если руками в web включить/выключить PPTP, то все нормально устанавливается?

Все верно, поскольку ваш роутер не шлет RELEASE провайдеру, и постоянно делает RENEW - таким образом провайдер тоже в курсе, что этот адрес у вас и никому его не отдает заново.

Хм, а если на двух интерфейсах гейтом железка с одним MAC но с разными IP? Если подсети не пересекаются, то все должно быть нормально.

Просто если подсети на разных WAN совпадают, то это любой роутер одуреет и не сможет их сразу вдвоем использовать

Создал тикет суппорту zyxel.ru, #329 370 Если для менеджмента нужна аргументация зачем нужна эта фича на старых моделях: дать пользователям возможность повышения приватности, я конечно могу поднять PPTP на centos, но считаю L2TP/IPSec более безопасным и удобным. У нас локально в рознице (супермаркеты бытовой техники) только Keenetic и TPLink, у последнего IPSec есть, но zyxel то лучше! Спасибо! Не за что Я сам все понимаю, и всячески бы накручивал IPsec во всех моделях роутеров, только это упирается в - нет запросов от юзеров - как следствие начальство не хочет тратить время программистов на то, что людям не нужно - отдел тестирования/QA просто не пропускает эти фичи из-за того, что на их тестирование нужно время, которого им тоже не выделяют Потому чем больше будет запросов от юзеров - тем лучше А кстати, tp-link умеет l2tp/ipsec? Из того, что я видел - он умеет только site-to-site tunnel.

у меня два keenetic DSL очень жду и нужен L2TP/IPsec в режиме клиента, готов выступить QA -- серверная часть также конфигурируется мной Окончательно решение еще не принято, но скорее всего Keenetic DSL останется на NDMS 2.05 с ядром 2.6.22 из NDMS 2.04 навсегда (это связано с особенностью чипа RT63368), что вероятно ставит крест на поддержке IPsec в нем. Однако еще раз повторю, что окончательное решение еще непринято - возможно IPsec будет перенесен в 2.05. Попробуйте в дополнение обратиться с этим в официальную техподдержку - пусть у них тоже будут заявки на это, чтобы product manager'ы понимали насколько это востребованная фича.

Такое к сожалению вообще не годится (и работать врядли будет, расчет идет на то, что nexthop у каждого аплинка уникален и подсети разные), здесь вам нужен не multiwan, а link aggregation скорее - это фича другого уровня.

Если у вас есть реально два провайдера (или хотя бы два подключения к одному провайдеру) - то это просто прекрасно, то что нужно для теста.

Активно занимаюсь проблемой, и по факту выяснилось, что вот так сразу удовлетворительно работать не будет. В ядре по умолчанию не включен multipath для advanced routing, потому балансировка между двумя каналами через несколько nexthop не заработает. Плюс для полностью автоматической работы скриптов не хватает данных, которые может предоставить ndm - а значит все нужно вбивать руками, что недопустимо. Как только эти рабочие вопросы будут улажены - будет создана тема с подробным описанием как и что сделать.

По умолчанию они все в одном VLAN, потому не выделены отдельно. Но это легко делается как через Web, так и через CLI.

interface GigabitEthernet0/6 name port_7 switchport mode access switchport access vlan 7 up ! interface GigabitEthernet0/Vlan7 description "My VLAN at port 7" security-level private ip address 192.168.7.1 255.255.255.0 up !

Вполне. Используйте в качестве последнего (пятого) аргумента в crontab день недели на английском (можно несколько через запятую), например: 00 09 * * Mon,Tue,Wed root ndmq -p "interface WifiMaster0/AccessPoint0 up" -P message 00 21 * * Thu,Fri,Sat,Sun root ndmq -p "interface WifiMaster0/AccessPoint0 down" -P message

Установите прошивку, которая поддерживает opkg... Речь о DD-WRT, OpenWrt? Где скачать оригинальную прошивку Zyxel для Keeдnetic Giga II с поддержкой opkg? NDMS 2.05 с opkg можно взять здесь: viewtopic.php?f=6&t=138 NDMS 2.06 поддерживает opkg искаропки в стандартном выборе компонентов.

Понять бы, как он, этот дефолтный маршрут маршрут меняеться при переходе на резервный канал, например, c помощью pingcheck , какой алгоритм там, то это можно было бы использовать для скрипта. Можно, конечно смотреть через командную строку, как происходит процесс дефолтирования наверно, только есть одна мозгокипучка по поводу того, как оба активных соединения дефолтировать-то. Идея как то не очень понятна. 1) Разве что дефолтировать, что бы загрузка по одному WAN а закачка по другому WAN. А Если WAN-ов три, четыре? 2) Или дефолтировать определенные пакеты или в зависимости от порта на определенный WAN. 3) Чтобы использовать несколько подключений одновременно в качестве бустера скорости, такое решение явно не подойдет. Ведь при этом решении вероятно придется файл при загрузке по пакету хватать то с одного интерфейса то с другого, чтобы суммарно его выкачивать с большей скоростью. Как интересно это отразиться на ресурсах роутера, если это делать софтверно? Как здесь заставить работать аппаратную часть, которая присутствует, чтобы не убивать софтверные ресурсы? Опять же - а если WAN-ов три, четыре? Задачка явно для специалистов высокого уровня которые отлично знают все особенности железки и свой софт. Не для чайников в общем Вообще на эту тему есть прекрасный документ под названием LARTC, но использовать его нужно с умом. Linux поддерживает множественные таблицы маршрутизации и source-based policy routing, потому дефолтных маршрутов может быть несколько, причем столько, сколько вашей душеньке угодно. Насчет распределения нагрузки между каналами: в ядре 2.6.36 используется route cache, поэтому при первом обращении к удаленному адресу будет выбран один из маршрутов по умолчанию, и до конца жизни кэша (определяется динамически ядром) весь трафик на этот адрес будет идти по нему. Поэтому сразу хочу сказать во избежание недоразумений: при двух одновременно поднятых аплинках на 100 Мбит/с качать с одного удаленного адреса по HTTP или FTP со скоростью выше скорости 100 Мбит/сек не выйдет. А вот для торрента и подобной нагрузки ситуация идеальна: качать будет 200 Мбит/сек, также как и при любых загрузках сразу с нескольких адресов. Я сейчас немного занят, но как высвободится время постараюсь написать нужные скрипты.

tun.ko идет в прошивке по умолчанию и поставляется в составе NDMS, а не keenopt: он уже есть в вашей системе, проверьте /lib/modules/2.6.36. Нет его в этой папке. Может саму прошивку надо открывать каким нибудь архиватором чтоб вытащить оттуда tun.ko? tun.ko является обязательной зависимостью ndm, потому его не может не быть в прошивке. Более того, он даже загружается всегда автоматом. Проверьте вывод lsmod и убедитесь сами.

Интересные новости... Значит скорее всего в xl2tpd/pppd есть запасной вариант и работает все через userspace, что в принципе нормально, только заметно медленнее, чем через ядерный l2tp драйвер.

tun.ko идет в прошивке по умолчанию и поставляется в составе NDMS, а не keenopt: он уже есть в вашей системе, проверьте /lib/modules/2.6.36.

Жаль. У меня уже получилось заставить работать xl2tpd (принимает соединения), однако интернета и локалки в туннеле нет. Я полагал дело в iptables, что у меня не получается правильно их настроить. Нет, боюсь дело в ядре.

Учтите, что в keenetic свой ядерный L2TP драйвер, написанный с самым минимальным необходимым набором фич (во имя скорости), и скорее всего он не будет работать сервером вообще - это в него не закладывалось. Плюс его userspace-модуль к pppd тоже самописный, несовместимый с xl2tpd/openl2tpd. Так что скорее всего у вас не получится работоспособного решения.

На мой взгляд проще прошить модем под NDIS, и уже из этой морды работать с sms и ussd. По крайней мере те свистки, на которые есть такой вариант.

Превосходно, что у всех Ultra II. Значит на ней и будем испытывать.

Я смотрю тема актуальна и животрепещуща. Товарищ ndm натолкнул меня на кое-какие идеи, напишите на каких девайсах вы точно сможете проверить Multilink WAN, а я кое-что попробую изобразить.