Russian Users MikroTik | Форум пользователей MikroTik

Приветствую!
Два микротике, между ними поднят ipsec tunnel.
Для контроля канала необходимо выполнять периодический пинг, логично это делать пингуя на самом роутере шлюз для второй локальной сети с источником пакетов в виде шлюза для своей локальной сети, так как они всегда подняты.
Т.е. , ping src-address=172.15.15.1 192.168.3.1
где 192.168.3.1 - адрес для дефолтного маршрута в сети 192.168.3.0/хх
172.16.15.1 - шлюз для сети , в которой нахожусь я

Успешно пингуются только хосты в другой сети, например
ping src-address=172.15.15.1 192.168.3.18
ping src-address=172.15.15.1 192.168.3.19
etc
но не их шлюз.
Прошивка 6.45.6

Почему?

То есть, R-1 с маршрутом по умолчанию 192.168.3.1, а R-2 с маршрутом по умолчанию 172.15.15.1?
Пинг с R-1, где src = 192.168.3.1 и to = 172.15.15.1?
В packet sniffer посмотрите как ходят пакеты.
А вообще у вас R-1 ведомый, раз шлюз с хостами в одной подсети?

Если они связаны только посредством VPN, то создайте в netwatch правило для обоих роутеров.
На R1 с пингом адреса бриджа R-2, а на R-2 с пингом адреса бриджа R-1 - в случае обвала один из них пришлет Вам уведомление на почту.
Или опишите вашу сеть подробнее.

Затупил я. У меня же запрет в firewall, только с разрешенных. Ведь правильная подпись у одного из модераторов - "ты Файр отключил??? Нет? Тогда зачем спрашиваешь???)))
А вообще, суть в следующем.
Один филиал имеет R1, второй - R2.
Между ними ipsec на публичные адреса с политиками, определяющими, что из одной локальной сети пакеты ходят в другую. Оба маршрутизатора в протоколе ipsec в первой фазе выступают как инициаторы, так и респондеры.
Недавно даже при наличии установленного канала стали появляться глюки - канал в состоянии established, а пакеты не ходят, убиваешь канал, он поднимается, но пакеты все равно не идут. Пока не перезагрузишь один роутер. Уж на нем и по обновлял, хотя rourerboard не обновился. Он далековато, так что не рискую ему прошивку лить.

Так вот, встаёт задача сейчас контролировать фактическое функционирование канала. Но в сети может не быть (например, ночью) ни одного работающего хоста. Есть только бридж, который есть шлюз для локальной сети.
Если не пойму, почему глючит канал, придется ребутить автоматом порезультату пинга

/ip ipsec prof pri

А зачем?
Sha1, aes-256, время жизни 1 день, dpd-interval 2m , dpd-max-fail 5.
Как все это началось, поставил в задание на 5 утра перезагрузку. Канал после этого устанавливается и работает. Перед выходом из дома в 7 часов проверяю - пакеты идут. Каждое утро около 7:40-7:50 , когда все в филиале выходят на работу, мне звонят с претензией, что не могут подключиться к ресурсам в головном. Силовое оборудование, которое могло бы ставить электрические помехи, если грешить на них, по их словам сейчас не запускается.

мне помогло lifetime=3h.

За время удаленной работы обновил и routerboard до версии 6.46.4, какая как и версия ROS.
Все дни удачно пинговал с самого уд.микротика
ping src=192.168.2.1 192.168.0.хх
где 192.168.2.1- адрес , назначенный бриджу микротике в удаленном филиале
пинг шли успешно.
Уд.микротик автоматически перезагружается по расписанию в 6 часов утра
Сегодня в филиале сотрудники пришли и попытались достучаться по ipsec до ресурсов сети 192.168.0.хх и - неудачно.
Пинг на уд.микротике
ping src=192.168.2.1 192.168.0.хх
тоже неудачен.
Убиваю установленный канал ipsec, он сразу переустанавливается, на уд.микротике среди active peers есть только responder, пинги по каналу не идут.
Помогает только ребут , причем нужна перезагрузка именно удаленного микротика.

Если постоянно пинговать какой-нибудь узел в сети 192.168.2.хх, то никаких проблем не наблюдается.

И что, dpd не срабатывает?

Так состояние канала established . И Lifetime гораздо больше, чем время, прошедшее с момента установления. Самое загадочное, это то, что со стороны сети основного офиса, где все информационные ресурсы, пакеты инициируют фазу и проходят нормально. Проблема только тогда, когда пакет идёт с той стороны.
Пока вышел из положения путем периодического пинга по расписанию, чтоб канал был в постоянной готовности.