Openvpn - как получить сообщение о недоступности клиента?

[linadmin]

Добрый день.
есть linux server fedora 8 - впн сервер
eth0 - реальный инет айпишник, по которому впн клиенты подсоединяются к серверу
tun0 inet addr:10.1.0.1 P-t-P:10.1.0.2 - впн тунель

ниже маршрутизация
192.168.1.0 10.1.0.2 255.255.255.0 UG 0 0 0 tun0

linux server fedora 8 впн клиент
tun0 10.0.1.1 P-t-P:10.0.1.2
eth1 - 192.168.1.0 локалка

Если клиент подключен, то с впн сервера я пингую 192.168.1.0\24 нормально
Если впн клиент пропал, то пинг ничего не сообщает

Мне нужно, чтобы моё оборудование при попытке обратиться к сети клиента, который сейчас недоступен, получало какое-то сообщение о недоступности.
Разве маршрутизатор на котором установлен впн сервер не должен выдавать ошибку пинга по таймауту?

Заранее благодарен за любой совет.

[sash-kan]

Если впн клиент пропал, то пинг ничего не сообщает

как так ничего? он сообщает код ошибки. а чтобы не ждать у моря погоды, можно ключик -c или даже -w использовать.

[Sleeping Daemon]

Добрый день.
есть linux server fedora 8 - впн сервер
eth0 - реальный инет айпишник, по которому впн клиенты подсоединяются к серверу
tun0 inet addr:10.1.0.1 P-t-P:10.1.0.2 - впн тунель

ниже маршрутизация
192.168.1.0 10.1.0.2 255.255.255.0 UG 0 0 0 tun0

linux server fedora 8 впн клиент
tun0 10.0.1.1 P-t-P:10.0.1.2
eth1 - 192.168.1.0 локалка

Если клиент подключен, то с впн сервера я пингую 192.168.1.0\24 нормально
Если впн клиент пропал, то пинг ничего не сообщает

Мне нужно, чтобы моё оборудование при попытке обратиться к сети клиента, который сейчас недоступен, получало какое-то сообщение о недоступности.
Разве маршрутизатор на котором установлен впн сервер не должен выдавать ошибку пинга по таймауту?

Заранее благодарен за любой совет.

fping

[linadmin]

Мне главное даже не пинг, а то, чтобы при попытке создать соединение через впн сервер (который выступает как шлюз) на клиент (его подсеть), который в данный момент отвалился, запросившему это соединение приходила хоть какая-то ошибка на TCP запрос. А так, не получив ответа, устройство пославшее запрос засыпает, не получив никакого ответа.

[sash-kan]

можно при падении туннеля добавлять в netfilter правило, reject-ящее все обращения к требуемой подсети.
а при поднятии туннеля это правило, соответственно, удалять.
или наоборот.
reject-ящее правило пусть всегда болтается в конце цепочки input.
а при поднятии туннеля в начало цепочки ставить accept-ящее правило.
и при падении его удалять.

[linadmin]

У впн сервера много клиентов. Отпадает только один (например). По какому критерию будет правило срабатывать?

[sash-kan]

хорошо. начнём сначала.
когда клиент с сетью из приватного диапазона (rfc1918) отваливается, куда идут пакеты, адресованные в такую сеть этого клиента?
скорее всего, ваш маршрутизатор, он же pptp-сервер, отправляет их провайдеру.
который их благополучно drop-ает. и правильно делает.
а у вас при обращении к этим адресам, естественно, нет мгновенного отклика.
так почему бы вам не настроить ваш маршрутизатор немножко правильнее?
т.е. не отправлять пакеты, адресованные в сети из приватного диапазона, вашему провайдеру.
а если вы будете их не drop-ать, а reject-ить, то убьёте сразу и второго зайца.
первый заяц: разгрузите провайдера (и, соответственно, связывающую вас сеть, которая обычно не безразмерна) от этого мусора.
второй заяц: будете получать мгновенный отклик в случае, когда клиент отваливается.

p.s. уж извините, примеры правил приводить не буду. потрудитесь полистать учебник по iptables.

[linadmin]

Согласен, но как это сделать? Фаерволом?

[linadmin]

Спасибо. Хотелось бы не прибегая средствам фаервола.

[sash-kan]

Хотелось бы не прибегая средствам фаервола.

если придумаете, _как_, подели́тесь с общественностью.
p.s. а что тут такого страшного в использовании iptables? все что нужно — три правила netfilter-а. для 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 (http://www.faqs.org/rfcs/rfc1918.html). для полноты картины неплохо бы еще резать 127.0.0.0/8. а то временами страдают рассылкой таких пакетов некоторые альтернативные (улыбка) операционные системы.
p.p.s. кстати, то, что ваш маршрутизатор эти пакеты отправляет провайдеру, в общем-то, моветон.
и по правилам хорошего тона вам все-таки надо их прибивать на своей стороне. заодно и себе облегчите задачу.

[linadmin]

Я уже на финальной стадии. Решаю средствами Openvpn --client-connect --client-disconnect. Осталось скрипт написать. Получится - выложу полностью решение.