clever2v

Вы имеете ввиду встроенный DDNS (IP Cloud)?

Всем доброго времени суток. Дано: Два микротика: один из них с белым внешним IP, другой с серым. Между ними OVPN тоннель, где сервером является микротик с белым IP адресом. Из за политики провайдера (или по какой то другой причине) на микротике с белым IP раз в два-три месяца меняется этот самый белый IP. (раздается на wan порт через DHCP от провайдера). Задача: Сделать так, что бы один микротик каким то образом сообщал другому о смене его внешнего IP. Заранее спасибо)

Будет ли это работать, вот вопрос. Вот цитата из английской вики микротик: Routes with interface name as the value of gateway are not used for nexthop lookup. If route has both interface nexthops and active IP address nexthops, then interface nexthops are ignored.

Dahua DHI-HCVR5432L

В работающей конфигурации (просмотр одной камеры) с регистратором всего два tcp соединения: адрес_устройства_отображения:рандомный_порт --- Белый_ip_микротика:37777 (1-500кб/с управляющее) адрес_устройства_отображения:рандомный_порт --- Белый_ip_микротика:37777 (3-5 Мб/с поток камеры) И все работает, но это при пробросе портов с одинаковыми номерами. А при пробросе с разными только одно соединение: адрес_устройства_отображения:рандомный_порт --- Белый_ip_микротика:37777 (1-500кб/с управляющее) Прога регистратор видит, но показывает ошибку видеопотока

Всем доброго дня, запутался в трех соснах. Дано: В локальной сети есть два видеосервера 192.168.15.240 и 192.168.15.241. на интерфейсе eth1 у микротика есть белый ip адрес и вся сеть 192.168.15.0/24 сидит за натом. На регистраторах по умолчанию для TCP подключений открыт порт 37777, и следовательно необходимо пробросить этот порт в интернет. сделано это таким образом: add action=dst-nat chain=dstnat comment="Camera" dst-port=37177 protocol=tcp \ to-addresses=192.168.15.240 to-ports=37777 add action=dst-nat chain=dstnat comment="Camera2" dst-port=37188 protocol=tcp \ to-addresses=192.168.15.241 to-ports=37777 В настройках приложения для просмотра камер добавляем два регистратора с одинаковым ip адресом, но разными портами. На работающей связке регистратор-приложение (в другой организации) выяснено: Приложение устанавливает несколько TCP соединений с рандомных портов на порт 37177 при подключении к первому регистратору или на порт 37188 при подключении ко второму регистратору. одно из этих соединение видимо управляющее (оно поднимается первым) другие - для видеопотока каждой камеры (их кол-во равно кол-ву просматриваемых камер в данный момент). Однако у нас поднимается не более одного TCP соединения (обычно это первое управляющее). но если делать проброс на тот же самый номер порта в лок машине например так: add action=dst-nat chain=dstnat comment="Camera" dst-port=37777 protocol=tcp \ to-addresses=192.168.15.240 to-ports=37777 То все работает. но порту поднимется более одного tcp соединения и видеопотоки приходят на удаленное устройство. Не проблема поменять порты у регистраторов и делать пробросы на одинаковые номера портов, Но из спортивного интереса пытался понять почему так происходит, Понимаю что все просто, поэтому прошу сетевых гуру ткнуть носом в нужный абзац мануалов или в двух словах объяснить причины такого поведения dst-nat. Спасибо.

Спасибо!

Судя по англоязычной Вики в разделе ip/firewall/address lists доступны только два параметра "ADDRESS" и "LIST" с Ipшником и именем листа соответственно. Как скриптом забрать значение таймаута ума не приложу.

Всем доброго времени суток, гуру скриптинга прошу вас о помощи: стоит задача организовать оповещение на эл. почту при появлении нового адреса в Адрес листе. Адрес лист пополняется с помощью правила в firewall, тайм аут записи 60 мин. Необходимо что бы каждый раз при появлении в адрес листе новой записи, отправлять на почту оповещения с тем IP который появился. Я дилетант в скриптописании, но код скрипта для отправки на почту осилил, в других скриптах он работает. Интересует прежде всего основная идея скрипта (как опрашивать адрес лист на предмет новой записи, или можно как то другим путем получать эти значения). Заранее спасибо за ответы

Я сам только начал осваивать скрипты, но тем не менее попробую помочь. Для начала зайдите в system/scheduler и удалите задание wlanchecking, оно не понадобится. В system/scripts создайте скрипт с именем down (имена везде пишите с маленькой буквы) и текстом: /delay 40s :local check [/ping 10.0.0.2 count=3 interval=1000ms]; :local status [ /interface wireless get [find name=wlan1] comment]; :if (check =0 and status="Connected") do={ /interface wireless set [find name=wlan1] comment="Disconnected"; / log error "Connection to 10.0.0.2 down..Rebooting" /delay 1s /system reboot } Затем создайте второй скрипт с именем up и текстом /interface wireless set [find name=wlan1] comment="Connected"; зайдите в tools/netwatch и отредактируйте хост 10.0.0.2. Во вкладке Dowm напишите down (это имя вашего первого скрипта) во вкладке Up соответственно up Также рекомендую поставить интервал проверки не более 1 минуты. Перезагрузите микротик Скрипт работает очень просто: Netwatch с определенным интервалом проверяет хост 10.0.0.2 и как только хост стал недоступен, срабатывает событие Down и запускается скрипт down Скрипт проверяет комментарий к интерфейсу wlan1 и если он установлен "Connected" скрипт считает что это первая перезагрузка устройства с момента потери беспроводного соединения и еще раз проверяет доступность хоста и если хост по прежнему недоступен, то он перезагружает роутер и при этом добавляет к интерфейсу Wlan1 коммент Disconnected и пишет в лог инфу про перезагрузку. после перезагрузки соединение восстановилось и срабатывает скрипт UP котрый добавляет коммент"connected" к интерфейсу wlan1. и роутер готов снова перезагрузится в случае потери соединения. Если после перезагрузки соединение не восстановилось, (например вы сами отключились от базы), то скрипт перезагрузки не сработает , так как коммент на интерфейсе wlan1 так и остался "Disconnected". Так реализована защита от постоянной перезагрузки при потере соединения. Минус у этого способа контроля: роутер будет один раз перегружаться при потере соединения, и неважно вы его разорвали или нет. Но лишняя перезагрузка раз в сутки не помешает=)

Всем доброго времени суток, Контора переезжает в новое помещение ("кишка" длиною 140 метров на 16 метров ширины, потолки метров 10). Стоит задача обеспечить стабильное покрытие WIFI. Возможно в будущем появятся некапитальные перекрытия. Из старого помещения достаются две точки Cisco WAP321 и роутер микротик RB750GL. так же на складе в старом помещении работал простой роутер TP-link TL-WR841N. Он обеспечивал доступ в интернет девайсам кладовщиков, девайсы эти очень древние и корректно работают только с сетью b/g и без шифрования WPA. У меня есть большие сомнения что две циски покроют такую большую территорию. В планах купить три-четыре штуки микротиковских AP, например, MikroTik cAP 2n и подцепить их к роутеру 750GL через CAPsMan. а циски перевести в режим b/g отключить шифрование и использовать на складе, который после переезда в новое помещение увеличится в два раза и ТП линка уже не будет хватать. Планируется невысокая нагрузка на сеть, не более 10 клиентов одновреммено, без большого потребления траффика. В связи с этим есть несколько вопросов к знающим людям: 1) Как работает капсман в плане переключения клиента между точками? уменьшится ли время перехода по сравнению с цисками, которые сейчас работают независимо друг от друга, с одинаковыми SSID и паролями доступа к сети? 2) Почитав форум я сделал вывод что капсман может только централизованно управлять настройками AP, добавляя виртуальные интерфейсы в контролирующий роутер и не в состоянии сократить время переключения клиента между AP, например за счет какой-нибудь упрощенной авторизации, и клиент при переключении между точками выполняет ровно те же процедуры авторизации как если он переключался между независимыми AP. Так ли это? 3) Нет возможности подключить точки напрямую к портам микротика, они будут подключены к L3 коммутатору управляющему локальной сетью в которую раздает интернет микротик. Что нужно включить через микротик не проходил траффик клиентов (всем клиентам будет раздаваться IP адрес из одной офисной подсети)? 4) Насколько я понял что реализовать псевдобесшовный роуминг можно лишь за счет настройки, которая пинает клиентов если уровень сигнала от них ниже определенного значения и клиент сканирует эфир и переподключается к другой AP если от нее сигнал сильнее. За счет этого решается проблема непереключения клиентов к AP с более высоким уровнем сигнала в данной точке помещения. Но этот способ никак не уменьшает задержки при переключении связанные с поиском AP и перерегистрацией клиента в новой AP. Так ли это?