
r13
Участники форума-
Постов
5 254 -
Зарегистрирован
-
Посещение
-
Победитель дней
66
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент r13
-
С 2.08 и так вроде прямой путь в официальную техподдержку
-
исправлено Настройка ping-check на интерфейс включенный в Bridge
r13 опубликовал вопрос в Обмен опытом
@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 интерфейс или это не поможет? ЗЫ селфтест далее -
Ок.
-
Автоматика, автоматикой, но по логике 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 не используется. Так что тема скорее для раздела развитие.
-
На текущий момент штатными средствами таких возможностей нет. Только руками или opkg.
-
Передергивание питания поможет не всем поддерживаемым устройствам, так как среди заявленных в том числе есть мобильные роутеры с автономным питанием. Думаю для данной задачи правильнее думать в сторону передачи команд дисконнект/коннект мобильному устройству. ЗЫ но по трудоемкости это конечно на порядок сложнее нежели добавить отключение питания устройства, для начала можно и его добавить.
-
Правила фильтрации выполняются после трансляции. Соответственно надо в фильтре порт после трансляции указывать. ЗЫ Информация об этом есть в базе знаний zyxel
- 6 ответов
-
- nat
- проброс портов
-
(и ещё 1 )
C тегом:
-
Должно отрабатывать, чтото не так делаете. хвастайтесь настройками.
- 6 ответов
-
- nat
- проброс портов
-
(и ещё 1 )
C тегом:
-
В таком случае поставить там где серый IP и ddns и keendns. 1 для работы при присвоении белого адреса, второй для управления через облако. Та как через облако только HTTP ходит, то трафик не велик и при хождении через ваш туннель проблем я думаю не создаст.
-
Вручную естественно будет ходить. Но как бы вы тогда ограниченны только этими прописанными сетями. Запросы из других сетей не заработают. Раз у вас белый может на него обычный ddns повесить? В отличие от кееndns он на конкретный интерфейс вешается.
-
1 кинетик использует для регистрации маршрут по умолчанию. Ваше предложение будет костылем, так как ответы на запросы по вашему белому адресу пойдут все равно в маршрут по умолчанию. 2 почему кинетик должен решать ваши сугубо личные взаимоотношения с провайдером и ваше нежелание оплачивать белый IP адрес? Не хотите оплачивать - решение со скриптами в entware лежит.
-
Сегмент домашних устройств. Прочий бред про лампочки и тому подобное за развитие вообще не считаю