Перейти к содержанию

Рекомендуемые сообщения

Опубликовано

Имеем Экстру 2 и Омни 1 на 2.13.A.5.0-4. Между ними установлено IPsec соединение, где Экстра сервер, а Омни клиент, соединение успешно устанавливается и стабильно работает. Но в случае смены ip адреса Экстры туннель не поднимается и в логах клиента видим это:

 

IpSec::Configurator: remote peer of crypto map "w" is down.
Авг 20 18:51:41
ndm
IpSec::Configurator: "w": crypto map active IKE SA: 0, active CHILD SA: 0.
Авг 20 18:51:41
ndm
IpSec::Configurator: fallback peer is not defined for crypto map "w", retry.
Авг 20 18:51:41
ndm
IpSec::Configurator: "w": schedule reconnect for crypto map.
Авг 20 18:51:41
ipsec
09[IKE] establishing IKE_SA failed, peer not responding
Авг 20 18:51:57
ndm
IpSec::Configurator: reconnecting crypto map "w".
Авг 20 18:51:59
ndm
IpSec::Configurator: "w": crypto map shutdown started.
Авг 20 18:51:59
ipsec
09[CFG] received stroke: unroute 'w'
Авг 20 18:51:59
ipsec
05[CFG] received stroke: terminate 'w{*}'
Авг 20 18:51:59
ipsec
05[CFG] no CHILD_SA named 'w' found
Авг 20 18:51:59
ndm
IpSec::Configurator: "w": crypto map shutdown complete.
Авг 20 18:51:59
ipsec
08[CFG] received stroke: terminate 'w[*]'
Авг 20 18:51:59
ipsec
08[CFG] no IKE_SA named 'w' found
Авг 20 18:52:01
ipsec
09[CFG] received stroke: initiate 'w'
Авг 20 18:52:01
ndm
IpSec::Configurator: "w": crypto map initialized.
Авг 20 18:52:01
ipsec
05[IKE] initiating IKE_SA w[4] to 88.81.58.211
Авг 20 18:52:09
ipsec
07[IKE] retransmit 1 of request with message ID 0
Авг 20 18:52:18
ipsec
08[IKE] retransmit 2 of request with message ID 0
Авг 20 18:52:28
ipsec
06[IKE] retransmit 3 of request with message ID 0
Авг 20 18:52:38
ipsec
07[IKE] retransmit 4 of request with message ID 0
Авг 20 18:52:50
ipsec
06[IKE] retransmit 5 of request with message ID 0
Авг 20 18:53:03
ipsec
07[IKE] retransmit 6 of request with message ID 0
Авг 20 18:53:17
ipsec
07[IKE] retransmit 7 of request with message ID 0
Авг 20 18:53:33
ipsec
05[IKE] retransmit 8 of request with message ID 0
Авг 20 18:53:50
ipsec
07[IKE] giving up after 8 retransmits
Авг 20 18:53:50
ndm
IpSec::Configurator: remote peer of crypto map "w" is down.

Причина оказалась в том, что клиент после смены адреса сервера вместо того чтобы узнать новый адрес пытается подключиться по старому. Ни дёрганье рубильника соединения, ни перезагрузка не понуждают клиент узнать новый адрес сервера. Но если забить вместо доменного имени ip адрес сервера в настройки клиента, то он сразу подключается.

В итоге ситуация оказалась даже ещё веселее, чем казалась вначале. Допустим мы создали подключение с указанием доменного имени сервера, клиент обратился к DNS (в данном случае KeenDNS) и узнал, что адрес сервера допустим 1.1.1.1 и подключился по этому адресу. Далее сервер сменил ip, туннель упал, а клиент безрезультатно пытается подключиться по адресу 1.1.1.1. Мы в настройках клиента указываем вместо доменного имени сервера его текущий ip адрес, допустим 2.2.2.2 и клиент тут же подключается по этому адресу. Меняем ip сервера и туннель снова падает. Заменяем ip адрес обратно на доменное имя и клиент вместо того, чтобы отрезолвить ip адрес сервера, снова подключается по адресу 1.1.1.1!!! Понятное дело если у сервера статический ip, то данной проблемы не будет, но с динамическим как быть?

Все же если клиента не трогать, то в конце концов он подключится, но ждать придётся очень долго.

Также обнаружился забавный глюк в виде того, что нельзя задать имя подключения, если оно содержит чётное количество символов, Кинетик пишет "недопустимые символы".

dgdg.PNG.2a9506ceb4ec1341601b59f567842490.PNG

Также глючит выключатель соединения, но это уже глюки web и другая тема.

 

 

 

Опубликовано
58 минут назад, Кинетиковод сказал:

Все же если клиента не трогать, то в конце концов он подключится, но ждать придётся очень долго.

Значит, клиент пользуется такими DNS-серверами и/или игнорирует время жизни DNS-записи.

~$ dig +nocmd +noall +answer gpoint.keenetic.pro
gpoint.keenetic.pro.     60      IN      A       46.125.185.53

Как видите, DNS-запись имеет TTL 60 секунд.

УМВР.

Опубликовано
1 час назад, Кинетиковод сказал:

Имеем Экстру 2 и Омни 1 на 2.13.A.5.0-4. Между ними установлено IPsec соединение, где Экстра сервер, а Омни клиент, соединение успешно устанавливается и стабильно работает. Но в случае смены ip адреса Экстры туннель не поднимается и в логах клиента видим это:

 


IpSec::Configurator: remote peer of crypto map "w" is down.
Авг 20 18:51:41
ndm
IpSec::Configurator: "w": crypto map active IKE SA: 0, active CHILD SA: 0.
Авг 20 18:51:41
ndm
IpSec::Configurator: fallback peer is not defined for crypto map "w", retry.
Авг 20 18:51:41
ndm
IpSec::Configurator: "w": schedule reconnect for crypto map.
Авг 20 18:51:41
ipsec
09[IKE] establishing IKE_SA failed, peer not responding
Авг 20 18:51:57
ndm
IpSec::Configurator: reconnecting crypto map "w".
Авг 20 18:51:59
ndm
IpSec::Configurator: "w": crypto map shutdown started.
Авг 20 18:51:59
ipsec
09[CFG] received stroke: unroute 'w'
Авг 20 18:51:59
ipsec
05[CFG] received stroke: terminate 'w{*}'
Авг 20 18:51:59
ipsec
05[CFG] no CHILD_SA named 'w' found
Авг 20 18:51:59
ndm
IpSec::Configurator: "w": crypto map shutdown complete.
Авг 20 18:51:59
ipsec
08[CFG] received stroke: terminate 'w[*]'
Авг 20 18:51:59
ipsec
08[CFG] no IKE_SA named 'w' found
Авг 20 18:52:01
ipsec
09[CFG] received stroke: initiate 'w'
Авг 20 18:52:01
ndm
IpSec::Configurator: "w": crypto map initialized.
Авг 20 18:52:01
ipsec
05[IKE] initiating IKE_SA w[4] to 88.81.58.211
Авг 20 18:52:09
ipsec
07[IKE] retransmit 1 of request with message ID 0
Авг 20 18:52:18
ipsec
08[IKE] retransmit 2 of request with message ID 0
Авг 20 18:52:28
ipsec
06[IKE] retransmit 3 of request with message ID 0
Авг 20 18:52:38
ipsec
07[IKE] retransmit 4 of request with message ID 0
Авг 20 18:52:50
ipsec
06[IKE] retransmit 5 of request with message ID 0
Авг 20 18:53:03
ipsec
07[IKE] retransmit 6 of request with message ID 0
Авг 20 18:53:17
ipsec
07[IKE] retransmit 7 of request with message ID 0
Авг 20 18:53:33
ipsec
05[IKE] retransmit 8 of request with message ID 0
Авг 20 18:53:50
ipsec
07[IKE] giving up after 8 retransmits
Авг 20 18:53:50
ndm
IpSec::Configurator: remote peer of crypto map "w" is down.

Причина оказалась в том, что клиент после смены адреса сервера вместо того чтобы узнать новый адрес пытается подключиться по старому. Ни дёрганье рубильника соединения, ни перезагрузка не понуждают клиент узнать новый адрес сервера. Но если забить вместо доменного имени ip адрес сервера в настройки клиента, то он сразу подключается.

В итоге ситуация оказалась даже ещё веселее, чем казалась вначале. Допустим мы создали подключение с указанием доменного имени сервера, клиент обратился к DNS (в данном случае KeenDNS) и узнал, что адрес сервера допустим 1.1.1.1 и подключился по этому адресу. Далее сервер сменил ip, туннель упал, а клиент безрезультатно пытается подключиться по адресу 1.1.1.1. Мы в настройках клиента указываем вместо доменного имени сервера его текущий ip адрес, допустим 2.2.2.2 и клиент тут же подключается по этому адресу. Меняем ip сервера и туннель снова падает. Заменяем ip адрес обратно на доменное имя и клиент вместо того, чтобы отрезолвить ip адрес сервера, снова подключается по адресу 1.1.1.1!!! Понятное дело если у сервера статический ip, то данной проблемы не будет, но с динамическим как быть?

Все же если клиента не трогать, то в конце концов он подключится, но ждать придётся очень долго.

Также обнаружился забавный глюк в виде того, что нельзя задать имя подключения, если оно содержит чётное количество символов, Кинетик пишет "недопустимые символы".

dgdg.PNG.2a9506ceb4ec1341601b59f567842490.PNG

Также глючит выключатель соединения, но это уже глюки web и другая тема.

 

 

 

https://wiki.strongswan.org/projects/strongswan/wiki/StrongswanConf

Я что-то тут не вижу настроек DNS. Да и скорее всего там используется системный резолвер из uclibc-ng, который хранит записи по TTL.

Опубликовано
11 час назад, Le ecureuil сказал:

https://wiki.strongswan.org/projects/strongswan/wiki/StrongswanConf

Я что-то тут не вижу настроек DNS. Да и скорее всего там используется системный резолвер из uclibc-ng, который хранит записи по TTL. 

Здесь кое-что. Может допустить указание

right = %domain.com

наряду с

right = domain.com

?

Опубликовано
15 часов назад, Le ecureuil сказал:

https://wiki.strongswan.org/projects/strongswan/wiki/StrongswanConf

Я что-то тут не вижу настроек DNS. Да и скорее всего там используется системный резолвер из uclibc-ng, который хранит записи по TTL.

Странные они эти разработчики IPsec. Но может тогда инвалиду костыль прикрутить? Тут вот коллеги по цеху калеке соорудили трость https://habr.com/post/252917/ Теперь хоть и прихрамывая, но ходит. Может и нашему больному подсобить по аналогии? Без динамического ip ну совсем некошерно получается.

 

3 часа назад, Александр Рыжов сказал:

Здесь кое-что. Может допустить указание


right = %domain.com

наряду с


right = domain.com

?

Если надо в CLI что-то прописать, то поделитесь секретом, дайте конфиг, тут все свои.;)

Опубликовано
3 часа назад, Кинетиковод сказал:

Странные они эти разработчики IPsec. Но может тогда инвалиду костыль прикрутить? Тут вот коллеги по цеху калеке соорудили трость https://habr.com/post/252917/ Теперь хоть и прихрамывая, но ходит. Может и нашему больному подсобить по аналогии? Без динамического ip ну совсем некошерно получается.

 

Если надо в CLI что-то прописать, то поделитесь секретом, дайте конфиг, тут все свои.;)

Лучше покажите TTL записи, и что strongswan не реагирует на смену адреса после истечения TTL. Это будет продуктивнее.

Опубликовано
14 минуты назад, Le ecureuil сказал:

Лучше покажите TTL записи, и что strongswan не реагирует на смену адреса после истечения TTL. Это будет продуктивнее.

Поясните, где взять эти записи?

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.