Вася Пупкин, Руководителю строго наплевать на риски. Главное, что будет ответственный, за которым будет закреплены обязанности и ответственность, которую ответственный будет обязательно нести.
Вернулся к задаче. После танцев с бубном, форумов и ГПТ наваял следующее. Скрипт пингует удаленный хост за IpSec. Если пинг отвалился, перезапускает политику с именем :local ipsecPolicyName "your_name". Проверяет снова, если пинга нет - второй раз перезапускает политику через :local initialRetryDelay 10s - интервал между 1ым и 2ым перезапуском . Если снова пинга нет, перезапускает политику :local maxRetries 3 (минус 1) - количество раз через :local subsequentRetryDelay 1m - интервал между 2ым и следующими перезапусками. Если после всех перезапусков пинг не появился, висит до появления пинга. После появления пинга скрипт перезапускается. Если политика отключена руками (до или во время выполнения скрипта), скрипт сообщает об этом и не трогает политику.
:local pingSourceAddress "192.168.5.1" - адрес с которого идет пинг (у меня мост микрота)
:local pingAddress "192.168.2.75" - адрес удаленного хоста
:local ipsecDstAddressA "192.168.2.0/24" - удаленная подсеть для определения политики. Тут поясню - у политики нет имени (имя только у пира), но у политики есть dst/src address, именно так и определяем именно тут политику, которая Вам нужна. Т.к. если подсетей несколько, то и политик будет несколько, но "имена" политик будут одинаковые. В случае отсутствия параметра - будет перезапускать все политики с именем пира, что нежелательно. Можно смотреть где параметр ph2-state = no-phase2, но у меня часто бывают ситуации, когда ipsec лежит, а статус established - так что не вариант.
Сам скрипт:
# Parameters
:local pingSourceAddress "192.168.5.1"
:local pingAddress "192.168.2.75"
:local ipsecDstAddressA "192.168.2.0/24"
:local ipsecPolicyName "your_name"
:local isPingSuccessful true
# Telegram data
:local chatID "-01234567899"
:local botToken "99876543210:AAHTtyLVF3jjHyPvXVHOMoHe-QNvOkra7q0"
# Number of restarts
:local maxRetries 3
:local retryCount 0
# First interval for potics restart
:local initialRetryDelay 10s
# Secondary interval for potics restart
:local subsequentRetryDelay 1m
Keffer, Вычитал, что это нормальная ситуация, в случае не получения ответа от сервера, андроид может удалить сертификаты как сомнительные, для повышения безопасности. Полагаю проблема в ТД, т.е. если запросы идут во время, допустим, перехода от точки к точке, теряется сигнал и сертификаты отваливаются. Решения пока не нашел.
Юрий MikroTik, ставлю два сертификата, rootca и с ключом для самого устройства. Да вроде проблема не только в старой версии, такая есть и на 10 -11 андроидах
Данная проблема наблюдается у разных производителей как сетевого оборудования, так и производителей смартфонов.
Возможные причины у Mikrotik: авторизация и согласование скорости у Mikrotik происходит в диапазоне b, а уже потом он поднимает скорость и переходит в диапазон n.
Это подтверждалось в Mikrotik.
Другие производители данную проблему и решения к ней не комментировали. Рекомендуют использовать режимы b\g\n.
