Форум русскоязычного сообщества Ubuntu


Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!

Автор Тема: Не работает переподключение в IPSec (после обрыва)  (Прочитано 3285 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн andreww

  • Автор темы
  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Добрый день! Поделитесь пожалуйста опытом внедрения L2TP over IPSec на базе Openswan – есть ли у кого удачные решения?

Я решил дома поднять VPN сервер, чтоб можно было извне подключаться. Конфигурация такая – Ubuntu 10.04.3 Desktop, Openswan 2.6.38, сервер спрятан за NAT'ом, внешний IP постоянный. Удаленные клиенты: Mac OS X 10.7, iPad. Клиенты могут подключаться или с другой сети (на работе) или с публичного IP через сотового 3G оператора.

В целом все работает, но до поры до времени. Через несколько часов работы (или наоборот от частого подключения-отключения) обрывается коннект. И заново подключиться уже невозможно, пока не зайдешь на сервак по ssh и не передернешь IPSec. Самое интересное, что можно сменить точку выхода в интернет – и соединение установится! Например, если через сеть в офисе произошел обрыв, я беру iPad подключаю через сотовый 3G и все работает. Но через некоторое время будет сбой, и уже переподключаться не будет.

То есть оно как-бы запоминает старое соединение, и новое такое-же создавать не хочет. Dead Peer Detection включен и работает (я проверял), так что дело здесь не в этом.

Дабы не быть голословным, приведу логи :)

Вот /var/log/auth.log удачного подключения:

(Нажмите, чтобы показать/скрыть)

Здесь 11.22.33.44 – внешний IP моего сервера, 12.34.56.78 – внешний IP сети из которой подключается клиент.

А вот /var/log/auth.log неудачного подключения:

(Нажмите, чтобы показать/скрыть)

Здесь 11.22.33.44 – внешний IP моего сервера, 12.34.56.78 – внешний IP сети из которой подключается клиент.

Чтобы было проще, приведу только последние строки, которыми эти логи отличаются. Эти строки есть в логе неудачного подключения в конце:

May  4 13:57:02 Atom pluto[12092]: "L2TP-PSK-NAT"[19] 12.34.56.78 #21: received Delete SA(0x089f8308) payload: deleting IPSEC State #22
May  4 13:57:02 Atom pluto[12092]: "L2TP-PSK-NAT"[19] 12.34.56.78 #21: ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete included errno 2: No such file or directory
May  4 13:57:02 Atom pluto[12092]: "L2TP-PSK-NAT"[19] 12.34.56.78 #21: received and ignored informational message
May  4 13:57:02 Atom pluto[12092]: "L2TP-PSK-NAT"[19] 12.34.56.78 #21: received Delete SA payload: deleting ISAKMP State #21
May  4 13:57:02 Atom pluto[12092]: "L2TP-PSK-NAT"[19] 12.34.56.78: deleting connection "L2TP-PSK-NAT" instance with peer 12.34.56.78 {isakmp=#0/ipsec=#0}
May  4 13:57:02 Atom pluto[12092]: packet from 12.34.56.78:39196: received and ignored informational message

Пробовал я гуглить, что-то находится, но ничего способного помочь в решении проблемы.

Поэтому прошу сообщество поделиться своими наблюдениями, наверняка у многих Openswan успешно работает, все-таки проект развивающийся, известный.

Напоследок еще конфиг-файл IPSec (/etc/ipsec.conf):

(Нажмите, чтобы показать/скрыть)

Оффлайн andreww

  • Автор темы
  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Экспериментальным путем обнаружил, что обрыв напрямую связан с параметром salifetime (он же keylife) в файле ipsec.conf.
Например, если поставить salifetime=15m, то обрыв произойдет через 15 мин, если salifetime=10m то через 10.

Судя из мануала:

salifetime
           how long a particular instance of a connection (a set of encryption/authentication keys for user
           packets) should last, from successful negotiation to expiry; acceptable values are an integer optionally
           followed by s (a time in seconds) or a decimal number followed by m, h, or d (a time in minutes, hours,
           or days respectively) (default 8h, maximum 24h). Normally, the connection is renegotiated (via the
           keying channel) before it expires. The two ends need not exactly agree on salifetime, although if they
           do not, there will be some clutter of superseded connections on the end which thinks the lifetime is
           longer.

           The keywords "keylife" and "lifetime" are aliases for "salifetime."

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

Кто-нибудь в курсе какие еще параметры могут быть связаны и влиять на salifetime?

Пока поставил salifetime=24h, наблюдаю.

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 27563
    • Просмотр профиля
Смотри rekey interval, или как оно там называется.
Он должен быть меньше connection lifetime.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн andreww

  • Автор темы
  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Значит установил я такие параметры:

rekey=yes
keyingtries=3
ikelifetime=2h
salifetime=8h

Сначала все было хорошо, коннект продержался около 9 часов, потом я его сам отключил. Но после этого подключиться уже не смог. Приехал на работу – несколько раз подключился-отключился, потом окончательно подключился, продержалось минут 15 и выбило. После чего подключиться уже невозможно. Таким образом изначальная проблема повторяется.

Dead Peer Detection здесь не помогает.

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 27563
    • Просмотр профиля
Поднимать уровень лога и смотреть, почему не удаётся переподключиться.
У меня была похожая проблема с PPTP, авторизоваться можно было только один раз сразу после холодной перезагрузки сервера. Потом проблема сама куда-то ушла... я так и не нашел причину, к сожалению.
Проверяй, где точно рвётся связь... Оттуда уже по обстоятельствам.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн andreww

  • Автор темы
  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Я смотрю auth.log (самый первый пост) и вижу чем отличается лог удачного подключения от неудачного. Но к сожалению по этим отличиям ничего не могу понять.
А есть ли у IPSec/Pluto какой-то свой лог? Я погуглил, но что-то ничего внятного не нашел...

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 27563
    • Просмотр профиля
Извини, тут я помочь не могу. Сам с IPsec начал разбираться, но за недостатком знаний бросил это дело нафиг.
Скоро, наверное, буду разбираться по-новой, но это будет не сегодня и не завтра...
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн andreww

  • Автор темы
  • Новичок
  • *
  • Сообщений: 6
    • Просмотр профиля
Я, сорри за оффтоп, вернулся к этой задаче через год. Тогда у меня вообще ничего не хотело работать, а сейчас уже хоть кое-что :)

 

Страница сгенерирована за 0.12 секунд. Запросов: 24.