Возможно, но если память мне не изменяет, скрипт определял
состояние соединения не пингом, а вроде как извлекая какоето
свойство этого соединения. Как я понимаю в глубинах стека
есть информация о состоянии канала.
Что касается моего вопроса, то исходя из того какой функционал заявлен
у DFL, а по сочетанию функционал/произвоительность он сопоставим
с моделями Check Point, хотелось чтобы такого рода проблемы
решались централизовано и именно на стороне сервера, а не на нескольких
десятках, разбросанных, технологических станций работающих по Win, на
которую уж точно никак всерьез в таком вопросе положиться нельзя.
Лично у меня хронические проблемы с сетевой подсистемой на ПК Win 7 и
Win 8 на которых установлены две (а иногда три) сетевых интерфейса.
Пусконаладчики не раз сидели до середины ночи поднимая и переподнимая
службы и программы которые полагаются на работу в разных сетевых
сегментах.
Это конечно лирика, но убежденность что такого рода вопросы обязаны решаться
на стороне железа которое из за этого и выбиралось - стойкая ))

Тут с вами согласен. Хотелось бы.
Но если посмотреть на разницу в цене этих решений, то можно и снизить свои требования.

Именно поэтому я и предлагал вам дешевое и надежное клиентское железячное решение.

Это уже технические детали. Суть в том, чтобы постоянно мониторить (если это вообще нужно) и заново поднимать соединение.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Ну что же, похоже придется все таки "ваять скрипт" ))
Спасибо, всем рекомендации !

поставте микротик - и скрипт наваяйте на нем , заодно можете в логи ссыпать кто когда отвалился и кто когда поднялся

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

А кстати все-таки где-то в логах достоверно выловлено что именно dfl разорвал соединение или наоборот это не он?

ну логика проста, с этого же клиента устанавливается по тому же LTE каналу на хостинговый VPN сервер
с точно такими же настройками VPN на стороне клиента. Причем тестирование производилось на двух
разных хостингах.
Данные VPN организованы на Linux. Соединение не рветься неделю и более. На DFL рвется в соответствии
с его настройками (1800) ))
Как то так...

Konkere_I, вопрос от D-Stream был как раз именно в том, чтобы найти в логах именно тот фрагмент, в котором указан искомый параметр, по которому рвется соединение.
И потом этот параметр мурыжить на DFL.

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Вы пробовали параметр Idle Timeout: удалять или делать больше?

Но независимо от этого клиент должен уметь при обрыве поднимать соединение снова. т.к. причин обрыва без участия сервера и клиента - достаточно.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

у меня стоит 24 часа
микроты сами поднимают туннели , ну и периодично его мониторят - и при необходимости передергивают .

один вообще на Йоте висит ....

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

в логах не указывается такой "параметр", а появляется запись что соединение разорвано. Возможно с флагом Debug, будет
более подробная информация, я сейчас debug поснимал, слишком много информации сыпется.
Но в документации вроде четко определен данный параметр Idle Timeout: 1800 поумолчанию (я его упоминал выше по тексту).
Параметр присутствует во всех PPP соединениях, при определении правила авторизации. Ноль ("0") выставить нельзя, с надеждой
на "вечное" поддержание канала.
Если пинговать не прерывно или иначе обеспечить трафик через PPTP/L2TP то соответственно соединение держится.
Но этот самый трафик необходимо организовать.

Кстати сейчас попробовал вбить значение Idle Timeout как 999999999999999, получил сообщение, что "не более 2147483647" (DFL-260E 10.22.01.04 и DFL-800 2.27.03.25)

Думаю значение 2147483647s (~68лет) вполне окажется вполне "вечным" относительно срока жизни DFL или uptime операционных систем на клиентах и самого железа клиентов

Вам одного года хватит за глаза.

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Мне? Мне и десятка минут вполне достаточно для моих задач -)