r13

@des Поправьте в пресете Мультифон параметр Таймаут регистрации на 60 секунд В описании на сайте услуги это максимальное значение. Зы ну и профиль ОнЛайм Москва добавьте пожалуйста.

Веб каждый раз пересоздает по моим наблюдениям, только cli создается в точности как вводил команды.

Если свитч не управляемый тогда на всех клиентах надо будет конкретный vlan указывать По инструкцииям надо базу знаний zyxel шерстить

Копать в сторону vlan, но или подключенный свитч должен быть управляемым чтоб vlan`ы по портам раскрыть

С 2.08 и так вроде прямой путь в официальную техподдержку

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

Так это и не для него. Ему все это arp по боку. Интернет есть, вконтактик работает и слава богу

Да какая разница в какой ценовой категории, главное что кому надо ее можно отключить!

@Le ecureuil В продолжение нашей беседы Есть Eoip включенный в бридж (security level public) на бридже висит статический ip и acl на пропуск icmp (пинги между сайтами проходят, все ок) такая сжема с 2х сторон туннеля По вашему совету удалил ip адрес непосредственно с eoip интерфейса, ip есть только на бридже Теперь хочу реализовать перезапуск туннеля по ping-check. Создаю профиль ping-check и привязываю его к eoip туннелю при этом в cli по команде show ping-check _EoIP10 ошибка: pingcheck: profile: _EoIP10 host: 10.10.1.10 update-interval: 30 max-fails: 3 timeout: 2 mode: icmp interface: name: EoIP10 successcount: 0 failcount: 0 status: not ready Network::Interface::IP error[72220772]: "EoIP10": address is not available. При этом соответственно ping-check не работает. Если ping-check привязать к самому бриджу то он работает но насколько я понимаю при обрыве желаемого перезапуска туннеля не произойдет. Вопрос как реализовать данную схему? Добавить еще 1 фиктивный ip на eoip интерфейс или это не поможет? ЗЫ селфтест далее

@Le ecureuil Я так понимаю на роутере может быть только 1 автоматический over ipsec туннель в режиме сервера и если надо больше, то нужно создавать транспорт вручную? Или я не прав?

Ок.

Автоматика, автоматикой, но по логике ip static команда для проброса портов, ip nat команда для управления NAT. Нам по сути нужна автоматика только более гибкая. По минимуму натить не по условию интерфейса источника а по интерфейсу назначения. Если усложнять, то еще добавить в эту схему адрес источника. То есть по сути то что была попытка реализовать с помощью ip static ИМХО что то вроде: ip nat {interface | ip address/mask | any} {out interface}

Может тогда стоит не эту команду обвешивать новыми функциями, а расширять команду ip nat ?

Значит клиентов без интефейса типа VirtualIP выборочно натить не получится? А то я уже губу раскатал, но глядя на iptables начинаю закатывать обратно ЗЫ надо бы к команде в первом предикате значение any прикрутить

Маршруты подтягиваются после переподключения клиентов

@Le ecureuil Спасибо за разъяснения, а то начал пробовать без отключения nat на интерфейсе( думал новая команда наоборот работает, а так еще лучше!)

В RT2860APi.dat есть упоминания о WDS, так что видимо железо поддерживает, но в ndms не используется. Так что тема скорее для раздела развитие.

https://forum.keenetic.net/announcement/5-где-взять-тестовые-прошивки/

До релиза 2.09 еще как до луны. Имется ввиду draft версия.

На текущий момент штатными средствами таких возможностей нет. Только руками или opkg.

Передергивание питания поможет не всем поддерживаемым устройствам, так как среди заявленных в том числе есть мобильные роутеры с автономным питанием. Думаю для данной задачи правильнее думать в сторону передачи команд дисконнект/коннект мобильному устройству. ЗЫ но по трудоемкости это конечно на порядок сложнее нежели добавить отключение питания устройства, для начала можно и его добавить.

Правила фильтрации выполняются после трансляции. Соответственно надо в фильтре порт после трансляции указывать. ЗЫ Информация об этом есть в базе знаний zyxel

Должно отрабатывать, чтото не так делаете. хвастайтесь настройками.

В таком случае поставить там где серый IP и ddns и keendns. 1 для работы при присвоении белого адреса, второй для управления через облако. Та как через облако только HTTP ходит, то трафик не велик и при хождении через ваш туннель проблем я думаю не создаст.

Вручную естественно будет ходить. Но как бы вы тогда ограниченны только этими прописанными сетями. Запросы из других сетей не заработают. Раз у вас белый может на него обычный ddns повесить? В отличие от кееndns он на конкретный интерфейс вешается.