В головном офисе Cisco ASA 3000, к нему подключаются филиалы посредством рутеров собраных на базе PC - linux, ipsec-tools-0.7.2. Впринципе все настроено и работает.
Но часто возникает следующая ситуация (думаю, что из-за паршивости клиентских каналов, микрообрывы или еще что-то), так вот - со стороны Cisco отваливается туннель, а клиентская сторона ничего не замечает.
SAD и SPD записи в порядке, в логе racoon.log никаких намеков на обрыв туннеля. Весь туннелированый трафик пытается идти через туннель. Смотрим через tcpdump proto ESP и видим трафик только в исходящем направлении. В этом блокированом состоянии туннель стоит до окончания lifetime какой-нибудь из фаз. Потом все нормализуется, до следующего обрыва.

Вопрос.
Как бы мониторить реальное состояние туннеля со стороны клиента? Варианты с ping-ом трудноосуществимые, так как нет постояных хостов для пинга на стороне сервера.

Спасибо.

• мониторить, что ipsec тунель жив (linux, ipsec-tools),Николай, 17:37 , 12-Июн-09
  • мониторить, что ipsec тунель жив (linux, ipsec-tools),alphil, 23:35 , 12-Июн-09
• мониторить, что ipsec тунель жив (linux, ipsec-tools),Serge, 22:52 , 12-Июн-09
  • мониторить, что ipsec тунель жив (linux, ipsec-tools),alphil, 23:37 , 12-Июн-09
  • мониторить, что ipsec тунель жив (linux, ipsec-tools),alphil, 23:41 , 13-Июн-09
• мониторить, что ipsec тунель жив (linux, ipsec-tools),alphil, 19:15 , 14-Июн-09

на ASA видно что ипсек лег?

>на ASA видно что ипсек лег?

Да, на ASA ипсек отсутствует (устанавливается и со временем отключается).

Вопрос, как определить со стороны клиента что тунель жив ??? Нет ли в самом пакете ipsec-tools возможности контролировать туннель ??? Ведь CISCO сразу определяет обрыв.

man racoon

dpd_delay delay;
                     This option activates the DPD and sets the time (in seconds) allowed between 2 proof of liveliness requests. The default value is 0, which disables DPD monitoring, but still negotiates DPD support.

dpd_retry delay;
                     If dpd_delay is set, this sets the delay (in seconds) to wait for a proof of liveliness before considering it as failed and send another request.  The default value is 5.

dpd_maxfail number;
                     If dpd_delay is set, this sets the maximum number of liveliness proofs to request (without reply) before considering the peer is dead.  The default value is 5.

>man racoon
>
> dpd_delay delay;

Ой, как раз отвечал на предыдущий вопрос. Сейчас попробую проэкспериментировать с dpd.

>man racoon
>
> dpd_delay delay;
>            

По описанию  - как раз то что мне нужно, но это не работает. Сегодня пол-дня записывал результаты tcpdump и racoon.log с разными значениями dpd_delay от 0 до 60.

Обобщенные результаты:
1. Туннель жив и функционирует:
      #tcpdump src host $REMOTE_PEER or dst host $REMOTE_PEER
каждые (приблизительно) 20 секунд (не зависит от параметра dpd_delay)
IP XXX.XXX.XXX.XXX.isakmp > YYY.YYY.YYY.YYY.isakmp:isakmp:phase2/others I inf[E]
IP YYY.YYY.YYY.YYY.isakmp > XXX.XXX.XXX.XXX.isakmp:isakmp:phase2/others R inf[E]
IP XXX.XXX.XXX.XXX.isakmp > YYY.YYY.YYY.YYY.isakmp:isakmp:phase2/others I inf[E]
IP YYY.YYY.YYY.YYY.isakmp > XXX.XXX.XXX.XXX.isakmp:isakmp:phase2/others R inf[E]

2. Туннель упал на ASA, но со стороны Linux-клиента жив:
      #tcpdump src host $REMOTE_PEER or dst host $REMOTE_PEER
периодичность пакетов не поддается класификации (не зависит от параметра dpd_delay)
IP XXX.XXX.XXX.XXX.isakmp > YYY.YYY.YYY.YYY.isakmp:isakmp:phase2/others I oakley-quick[E]
IP XXX.XXX.XXX.XXX.isakmp > YYY.YYY.YYY.YYY.isakmp:isakmp:phase2/others I oakley-quick[E]
IP XXX.XXX.XXX.XXX.isakmp > YYY.YYY.YYY.YYY.isakmp:isakmp:phase2/others I oakley-quick[E]

в racoon.log синхронно с отправкой этих пакетов наблюдаем ...resend phase2... когда истекает время у второй фазы (а оно истекает раньше чем у первой) получаем -  IPSec-SA expired,...,ERROR YYY.YYY.YYY.YYY give up to get IPSec-SA due to time up to wait....

соответственно ответа от ASA нет и эта ситуация продолжается до тех пор пока не истечет время первой фазы, тогда в racoon.log - ISAKMP-SA expired, ISAKMP-deleted - снова восстанавливаются первая и вторые фазы и все повторяется заново.

Перед началом экспериметов пересобрал ipsec-tools-0.7.2 с нуля со следующими параметрами:
--enable-natt --enable-adminport --enable-stats --enable frag --enable-dpd --enable-fastquit --disable-ipv6 --disable-security-context
Также попробовал на версии ipsec-tools-0.7. И на разных ядрах 2.6.24.4 и 2.6.27.8.

  

>Как бы мониторить реальное состояние туннеля со стороны клиента? Варианты с ping-ом
>трудноосуществимые, так как нет постояных хостов для пинга на стороне сервера.

Пока что выставил в первой фазе lifetime time 120 sec; а во второй lifetime time 60 sec;
Удерживаю тунель в рабочем состоянии (максимальная потеря связи небольше двух минут =)) три часа. Иногда стопорится весь процесс с записями в лог

ERROR: long lifetime proposed: my:60 peer:28800  
ERROR: not matched
ERROR: no suitable policy found

Пришлось сделать скрипт проверяющий лог и если находит ERROR,
#tail -n 5 /var/log/racoon/log | grep ERROR
то передергивает весь сценарий. Флушит все SPD SAD (на всякий случай) убивает racoon и поднимает туннель заново.

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

Спасибо.