Не поднимается IPIP туннель в автоматическом режиме из-за NAT

[r13]

Попробовал поднять IPIP(остальные думаю тоже ибо ipsec транспорт не поднимается) в автоматическом режиме  из-за NAT

Гига2 и Ультра2 подключены к интернетам, у обоих белый IP

К Ультре2 подключена Экстра2 как точка доступа. Если пытаюсь поднять туннель в автоматическом режиме с Экстры на Гигу то не работает. ipsec транспорт не устанавливается.

Если просто с Ультры на Гигу то все ок

Селфтесты далее.

Изменено 19 января, 2017 пользователем r13

[Le ecureuil]

10 часов назад, r13 сказал:

Попробовал поднять IPIP(остальные думаю тоже ибо ipsec транспорт не поднимается) в автоматическом режиме  из-за NAT

Гига2 и Ультра2 подключены к интернетам, у обоих белый IP

К Ультре2 подключена Экстра2 как точка доступа. Если пытаюсь поднять туннель в автоматическом режиме с Экстры на Гигу то не работает. ipsec транспорт не устанавливается.

Если просто с Ультры на Гигу то все ок

Селфтесты далее.

Ваша проблема исправлена, появится в новой сборке.

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

Проблема связана не с NAT, а с неподгрузкой ключей в некоторых случаях.

[r13]

Такой срочности нет, подожду вечерней сборки, проверю, или надо сейчас проверить?

Изменено 20 января, 2017 пользователем r13

[Le ecureuil]

2 минуты назад, r13 сказал:

Такой срочности нет, подожду вечерней сборки, проверю, или надо сейчас проверить?

Не хотелось бы на неделю затягивать еще + скоро выйдет стабильная версия 2.08, и чем больше туда багфиксов войдет, тем всем же лучше.

[r13]

Тогда давайте, протестирую. Нужно только гигу обновить или и экстру?

На гиге с pptp компонентом пожалуйста.

[Le ecureuil]

6 минут назад, r13 сказал:

Тогда давайте, протестирую. Нужно только гигу обновить или и экстру?

На гиге с pptp компонентом пожалуйста.

Только giga2.

Сейчас вам в личку ссылку пришлю.

[Le ecureuil]

15 минут назад, r13 сказал:

Тогда давайте, протестирую. Нужно только гигу обновить или и экстру?

На гиге с pptp компонентом пожалуйста.

https://www.dropbox.com/s/u8sr29qoc2i60cq/20170120_1104_Firmware-Keenetic_Giga_II-v2.09[AAFS.1]A1.bin?dl=0

[r13]

Да, подключилось, и  null в логе для IKE_SA теперь пропал, вместо него нормальный IP. селфтесты нужны?

Изменено 20 января, 2017 пользователем r13

[Le ecureuil]

1 минуту назад, r13 сказал:

Да, подключилось, и  null в логе для IKE_SA теперь пропал, вместо него нормальный IP. селфтесты нужны?

Попрошу вас проверить несколько раз, желательно прям кнопкой выключать и включать устройство.

Если все будет работать, то отлично,  так и выпустим.

[r13]

Ну кнопкой вряд ли  . Я по ней по телефону удаленно лазию, сча через интерфейс поперезагружаю.. только сервер или обоих?

[Le ecureuil]

2 минуты назад, r13 сказал:

Ну кнопкой вряд ли  . Я по ней по телефону удаленно лазию, сча через интерфейс поперезагружаю.. только сервер или обоих?

Только сервер, на клиентах все равно багифксов нет, а там тоже довольно много изменений (надеюсь в лучшую сторону :)).

[r13]

А вот сейчас не переподключилось

[r13]

Полагаю это уже проблема на клиенте была? Перезагрузка сервиса ipsec на клиенте не помогла, полная перезагрузка клиента помогла.

Продолжаю ребутить сервер с данной точки.

[r13]

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

[Le ecureuil]

28 минут назад, r13 сказал:

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

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

35 минут назад, r13 сказал:

Полагаю это уже проблема на клиенте была? Перезагрузка сервиса ipsec на клиенте не помогла, полная перезагрузка клиента помогла.

Продолжаю ребутить сервер с данной точки.

Да, там предположительно из-за багов в клиенте.

[r13]

@Le ecureuil

Тогда все ок, за 10ок перезагрузок туннель переподключился.

Клиента после того как он заработал не трогал.

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

Изменено 20 января, 2017 пользователем r13

[r13]

@Le ecureuil

Продолжаем разговор...

Обновил гигу и экстру до 2.09.A.1.0-2

После загрузки роутеров туннель поднялся.

Далее пропал канал(перезагрузка ультра2)

После восстановления канала роутеры не смогли восстановить туннель, перезагрузка клиента помогла его восстановить.

Повторно не восроизвелось.

Селфтесты далее.

[Le ecureuil]

В 1/21/2017 в 00:05, r13 сказал:

@Le ecureuil

Продолжаем разговор...

Обновил гигу и экстру до 2.09.A.1.0-2

После загрузки роутеров туннель поднялся.

Далее пропал канал(перезагрузка ультра2)

После восстановления канала роутеры не смогли восстановить туннель, перезагрузка клиента помогла его восстановить.

Повторно не восроизвелось.

Селфтесты далее.

У вас на сервере (Giga) судя по всему бардак с default route.

Сами смотрите.

Extra все делает правильно, предпринимая попытки открыть IKE SA с Giga, это видно как в ее логе, так и в логе Giga (видим в логе Giga начиная с Jan 20 23:47:20 постоянные получаемые от Extra пакеты и отправляемые ей ответы, которые уходят не в GigabitEthernet0/Vlan2, а неизвестно куда, потому что Extra их не получает обратно).

А то, что у вас запасным default route становится USB-модем хорошо видно вот здесь:

Jan 20 23:38:44 ndm: Dhcp::Client: adding a default route via 192.168.0.1.

После чего сразу отваливается PPTP по таймауту и IPsec.

Возможно стоит создать отдельную тему по поводу маршрутизации и приоритетов на default route, но сперва проверьте как вообще все это работает, в какой интерфейс реально идут пакеты и что при этом наблюдается в Web и логах.

[r13]

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

[r13]

Поэкспериментировал, отключив все лишнее (туннели, pptp) c гигой.

Сообщение в логе ndm: Dhcp::Client: adding a default route via 192.168.0.1.  Не меняет default route а только видимо запоминает информацию о нем. Так что проблема в чем то другом.

Далее несмотря на отключенное состояние туннеля он продолжает резолвить IP.

ЗЫ так же в логе не как не отражено переключение на резервное модемное соединение, хотя по факту интернет через оде работал.

Селфтест с экспериментом далее.

[Le ecureuil]

19 часов назад, r13 сказал:

Поэкспериментировал, отключив все лишнее (туннели, pptp) c гигой.

Сообщение в логе ndm: Dhcp::Client: adding a default route via 192.168.0.1.  Не меняет default route а только видимо запоминает информацию о нем. Так что проблема в чем то другом.

Далее несмотря на отключенное состояние туннеля он продолжает резолвить IP.

ЗЫ так же в логе не как не отражено переключение на резервное модемное соединение, хотя по факту интернет через оде работал.

Селфтест с экспериментом далее.

Принято, посмотрим.

[r13]

@Le ecureuil

Еще пара вопросов по автоматическому туннелю.

Не понятно зачем столько rekey

При обычном голом ipsec их вроде меньше,

Здесь же на rekey 2 итерации СHILD_SA и 2 Итерации IKE_SA

Не понятно.

Для примера селфтесты с rekey начиная с Feb  1 05:17:39

 

Изменено 1 февраля, 2017 пользователем r13

[Le ecureuil]

11 минуту назад, r13 сказал:

@Le ecureuil

Еще пара вопросов по автоматическому туннелю.

Не понятно зачем столько rekey

При обычном голом ipsec их вроде меньше,

Здесь же на rekey 2 итерации СHILD_SA и 2 Итерации IKE_SA

Не понятно.

Для примера селфтесты с rekey начиная с Feb  1 05:17:39

 

Это из-за сочетания сразу двух особенностей.

Во-первых, используется небольшой fuzz для определения времени rekey. То есть если задано например 86400 секунд, то настоящий rekey начнется за 86400 - 8640 + 4320 * (rand() % 1) секунд. Это специально сделано, чтобы не было ситуации, когда IKE/CHILD SA удаляются по истечении времени жизни и только потом начинается rekey, что ведет к пропаданию трафика на время + чтобы избежать перегрузки канала и процессора, если настроено сразу несколько туннелей с одинаковым интервалом rekey. Потому в вашем случае rekey может быть инциирован любой из сторон, возможно двумя сторонами сразу, возможно с небольшим лагом друг от друга. Это может выглядеть как излишний rekey. Но в итоге это все равно отработает правильно.

Во-вторых, SA в ядре полудуплексные, но из-за особенностей настройки ядра в случае транспортного режима необходимо пересогласовывать каждую SA индивидуально, а для туннельного режима можно обойтись одним разом.

[r13]

@Le ecureuil Понял, спасибо.