Не могу понять почему ikev2 на роутере keenetic постоянно рвется?

Question

[nebraza]

Всем привет! нужен совет, уже не знаю что делать.

Есть keenetic ultra, на ней поднят ikev2 сервер и клиентов штук 8 (компы винда10), подключаются средствами винды с chapv2.

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

Периодически отваливается ВПН, т.е. сидит человек работает в 1С в терминале, хренак- подключения к RDP нет. Смотрит в подключения VPN - "подключено", но при этом даже пинг до сервера не идёт. Далее пользователь жмет "отключиться" и тут же "подключиться" - и дальше всё нормально, подключение по RPD до сервера проходит. Такое может происходить раз в 10 минут, а может и день нормально всё быть. Вообще никакой системы.

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

В момент отвала подключения, если нажать на сети, то подключение к ВПН как бы есть, винда пишет, что "подключено" в логах ничего.

а со стороны роутера вот такое:

spoiler

[I] Dec 12 09:03:50 ipsec: 11[IKE] received DELETE for ESP CHILD_SA with SPI 0dc687ba
[I] Dec 12 09:03:50 ipsec: 11[IKE] closing CHILD_SA VirtualIPServerIKE2{126} with SPIs cae4f28d_i (3372 bytes) 0dc687ba_o (0 bytes) and TS 0.0.0.0/0 === 192.168.20.4/32
[I] Dec 12 09:03:50 ipsec: 11[IKE] sending DELETE for ESP CHILD_SA with SPI cae4f28d
[I] Dec 12 09:03:50 ipsec: 11[IKE] CHILD_SA closed
[
[I] Dec 12 09:04:59 ndm: IpSec::Netfilter: start reloading netfilter configuration...
[I] Dec 12 09:04:59 ndm: IpSec::Netfilter: netfilter configuration reloading is done.
[I] Dec 12 09:05:29 ipsec: 10[CFG] received proposals: ESP:AES_CBC=256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC=128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:NULL/HMAC_SHA1_96/NO_EXT_SEQ
[I] Dec 12 09:05:29 ipsec: 10[CFG] configured proposals: ESP:AES_CBC=128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC=128/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC=256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC=256/HMAC_SHA2_256_128/NO_EXT_SEQ
[I] Dec 12 09:05:29 ipsec: 10[CFG] selected proposal: ESP:AES_CBC=128/HMAC_SHA1_96/NO_EXT_SEQ
[I] Dec 12 09:05:29 ipsec: 10[IKE] inbound CHILD_SA VirtualIPServerIKE2{129} established with SPIs c77a5cd1_i ceba567a_o and TS 0.0.0.0/0 === 192.168.20.7/32
[W] Dec 12 09:05:29 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map remote client "timerman" @ "192.168.12.98" from "94.73.250.34" disconnected.
[W] Dec 12 09:05:29 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map is up: remote client "xcz" @ "192.168.12.98" with IP "192.168.20.7" connected.
[I] Dec 12 09:05:29 ipsec: 09[IKE] received DELETE for ESP CHILD_SA with SPI 8d54f810
[I] Dec 12 09:05:29 ipsec: 09[IKE] closing CHILD_SA VirtualIPServerIKE2{107} with SPIs c628f2d7_i (271621 bytes) 8d54f810_o (224693 bytes) and TS 0.0.0.0/0 === 192.168.20.7/32
[I] Dec 12 09:05:29 ipsec: 09[IKE] sending DELETE for ESP CHILD_SA with SPI c628f2d7
[I] Dec 12 09:05:29 ipsec: 09[IKE] CHILD_SA closed
[I] Dec 12 09:05:29 ipsec: 09[IKE] outbound CHILD_SA VirtualIPServerIKE2{129} established with SPIs c77a5cd1_i ceba567a_o and TS 0.0.0.0/0 === 192.168.20.7/32
[I] Dec 12 09:05:29 ndm: IpSec::Netfilter: start reloading netfilter configuration...
[I] Dec 12 09:05:29 ndm: IpSec::Netfilter: netfilter configuration reloading is done.
[I] Dec 12 09:07:29 ipsec: 06[CFG] received proposals: ESP:AES_CBC=256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC=128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:NULL/HMAC_SHA1_96/NO_EXT_SEQ
[I] Dec 12 09:07:29 ipsec: 06[CFG] configured proposals: ESP:AES_CBC=128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC=128/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC=256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC=256/HMAC_SHA2_256_128/NO_EXT_SEQ
[I] Dec 12 09:07:29 ipsec: 06[CFG] selected proposal: ESP:AES_CBC=128/HMAC_SHA1_96/NO_EXT_SEQ
[I] Dec 12 09:07:29 ipsec: 06[IKE] inbound CHILD_SA VirtualIPServerIKE2{130} established with SPIs cd1002cc_i 9a2d73ba_o and TS 0.0.0.0/0 === 192.168.20.5/32
[W] Dec 12 09:07:29 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map remote client "aasd" @ "192.168.1.120" from "195.208.156.230" disconnected.
[W] Dec 12 09:07:29 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map is up: remote client "czxc" @ "192.168.1.120" with IP "192.168.20.5" connected.
[I] Dec 12 09:07:29 ipsec: 14[IKE] received DELETE for ESP CHILD_SA with SPI 3cddeaae
[I] Dec 12 09:07:29 ipsec: 14[IKE] closing CHILD_SA VirtualIPServerIKE2{109} with SPIs c74763e9_i (1566668 bytes) 3cddeaae_o (2491632 bytes) and TS 0.0.0.0/0 === 192.168.20.5/32
[I] Dec 12 09:07:29 ipsec: 14[IKE] sending DELETE for ESP CHILD_SA with SPI c74763e9
[I] Dec 12 09:07:29 ipsec: 14[IKE] CHILD_SA closed
[I] Dec 12 09:07:29 ipsec: 14[IKE] outbound CHILD_SA VirtualIPServerIKE2{130} established with SPIs cd1002cc_i 9a2d73ba_o and TS 0.0.0.0/0 === 192.168.20.5/32
[I] Dec 12 09:07:29 ndm: IpSec::Netfilter: start reloading netfilter configuration...
[I] Dec 12 09:07:29 ndm: IpSec::Netfilter: netfilter configuration reloading is done.
[I] Dec 12 09:09:58 ipsec: 15[IKE] received DELETE for ESP CHILD_SA with SPI de1ff75e
[I] Dec 12 09:09:58 ipsec: 15[IKE] closing CHILD_SA VirtualIPServerIKE2{127} with SPIs ccba7671_i (366127 bytes) de1ff75e_o (619078 bytes) and TS 0.0.0.0/0 === 192.168.20.4/32
[I] Dec 12 09:09:58 ipsec: 15[IKE] sending DELETE for ESP CHILD_SA with SPI ccba7671
[I] Dec 12 09:09:58 ipsec: 15[IKE] CHILD_SA closed
[W] Dec 12 09:09:58 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map remote client "fdss" @ "192.168.1.14" from "109.202.23.91" disconnected.
[I] Dec 12 09:09:58 ndm: IpSec::Netfilter: start reloading netfilter configuration...
[I] Dec 12 09:09:58 ndm: IpSec::Netfilter: netfilter configuration reloading is done.
[I] Dec 12 09:10:19 ipsec: 10[IKE] received DELETE for ESP CHILD_SA with SPI ea3a0028
[I] Dec 12 09:10:19 ipsec: 10[IKE] closing CHILD_SA VirtualIPServerIKE2{128} with SPIs c07c691a_i (2665 bytes) ea3a0028_o (2140 bytes) and TS 0.0.0.0/0 === 192.168.20.4/32
[I] Dec 12 09:10:19 ipsec: 10[IKE] sending DELETE for ESP CHILD_SA with SPI c07c691a
[I] Dec 12 09:10:19 ipsec: 10[IKE] CHILD_SA closed
[W] Dec 12 09:10:19 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map remote client "fdssd" @ "192.168.1.140" from "195.208.156.230" disconnected.
[I] Dec 12 09:10:19 ndm: IpSec::Netfilter: start reloading netfilter configuration...
[I] Dec 12 09:10:19 ndm: IpSec::Netfilter: netfilter configuration reloading is done.

Почему происходит получение закрыть этот ESP CHILD SA?

Думал, провайдер (билайн) рвет, обратился к ним, сказали, что с их стороны ничего не режется. Сослались на 100% переодическую утилизацию канала в 10Мбит. Я не поверил. Подключил другого (МТС) на их интернете тоже самое.

Нашел другой ротуер keenetic speedster настроил всё заново - тоже самое. Не знаю что делать? помогите, кто шарит что сделать? какой тест провести, чтобы хоть как-то понять в чем дело.

Answer 1

[asmelnik]

[I] Dec 12 09:05:29 ipsec: 10[CFG] selected proposal: ESP:AES_CBC=128/HMAC_SHA1_96/NO_EXT_SEQ
[I] Dec 12 09:05:29 ipsec: 10[IKE] inbound CHILD_SA VirtualIPServerIKE2{129} established with SPIs c77a5cd1_i ceba567a_o and TS 0.0.0.0/0 === 192.168.20.7/32
[W] Dec 12 09:05:29 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map remote client "timerman" @ "192.168.12.98" from "94.73.250.34" disconnected.
[W] Dec 12 09:05:29 ndm: IpSec::CryptoMapInfo: "VirtualIPServerIKE2": crypto map is up: remote client "timerman" @ "192.168.12.98" with IP "192.168.20.7" connected.

И что тут не понятно???
Клиент ходил с одного IP "94.73.250.34", и вдруг решил заглянуть с "192.168.20.7".
Естественно все переинициализировалось.

Ищите почему ваши клиенты прыгают по IP как зайцы.

Кстати, если "192.168.20.7" -- IP "внутри" туннеля, то вы трафик туннельный "заворачиваете" опять же в туннель.
А Бутылка клейна в сетях плохой вариант.

Comments

[nebraza]

Не хватает ума понять. Смотрите, 192.168.12.98 это адрес моего ноутбука, который он получает от роутера моего с адресом 94.73.250.34. Далее при коннекте в VPN, ему VPN сервер выдает 192.168.20.7 - из пула ВПН-сервера.

Что не так? Разверните свой вопрос для начинающих пожалуйста, хочу понять в чем проблема? или может подскажете что почитать чтобы разобраться?

[nebraza]

даже более того, вот тут в статье https://help.keenetic.ru/hc/ru/articles/3600170229... написано:
"Важно! Указываемая подсеть IP-адресов не должна совпадать или пересекаться с IP-адресами других интерфейсов интернет-центра Keenetic, так как это может привести к конфликту адресов."

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

[asmelnik]

"На пальцах":
состояние 1: нет туннеля.
У вас есть IP 192.168.12.98, есть адрес VPN сервера пусть 1.2.3.4, есть адрес шлюза по умолчанию скорее всего 192.168.12.1 (это адрес LAN интерфейса роутера) и вы в интернет "ходите" именно по адресу "шлюза".

Состояние 2: подключаем туннель
IP пакет улетает на шлюз (ваш роутер), шлюз отправляет его дальше.
VPN сервер отвечает вам опять же через ваш роутер.
Туннель установлен

Состояние 3: конфигурация туннеля
VPN сервер передает вам набор параметров для туннельного интерфейса, как то ip/mask, может быть DNS и ... новый ШЛЮЗ!

Состояние 4: трафик в туннеле.
Ваш компьютер обнаруживает, что IP VPN сервера теперь доступен через другой шлюз.
И отправляет пакет "VPN внутри VPN" и все рассыпается.

состояние 5: VPN "гаснет", возвращается на место родной "шлюз", переход к п.1

Если это так, то для windows в командной строке попробуйте прописать

route add IP_VPN_SERVER mask 255.255.255.255 192.168.12.1

[nebraza]

asmelnik, спасибо вам за просвещение! стало понятнее! единственное я не понимаю, почему тогда иногда люди могут работать и половину дня и всё норм, а иногда отвалы каждые 5-10 минут. Ведь получается, что компьютер должен мгновенно понять, что шлюз изменился?

upd: сейчас посмотрел, при подключении к VPN, состояние адаптера вот такое:
Адаптер PPP MH:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : MH
Физический адрес. . . . . . . . . :
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 192.168.20.7(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз. . . . . . . . . :
DNS-серверы. . . . . . . . . . . : 78.47.125.180
NetBios через TCP/IP. . . . . . . . : Включен

т.е. основной шлюз как бы не передается и галка "использовать основной шлюз удаленной сети" снята.

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

А если в удаленной сети (где ротуер с впн) домашняя сеть 192.168.1.х и сервер RDP имеет адрес 192.168.1.5, а сеть из которой подключаются тоже 192.168.1.0/24, то как таким (route add IP_VPN_SERVER mask 255.255.255.255 192.168.12.1)статическим маршрутом я могу решить проблему? ведь любой пакет с компьютера проходит через основной шлюз, как он поймет куда пакет послать? в туннель или в свою местную?

[asmelnik]

route print
(Кажется)
Вам выдаст текущее состояние таблицы маршрутов.
Шлюзом может быть интерфейс в теории и для ppp интерфейса это скорее нормально, чем нет.

Соединить 2 сети с одинаковой адрессацией ( в вашем случае 192.168.1.х) чтоб они ПОЛНОСТЬЮ видели друг друга НЕЛЬЗЯ.
Есть костыли, через которые типа можно, но они имеют гору своих ограничений.

Так или иначе сообщение в логе говорят, что к серверу пытаются построить впн через тоже ВПН.
Причина требует более детального разбора и выходит за рамки формата вопрос/ответ

[ValdikSS]

asmelnik, Это мало того, что L3-туннель, где нет шлюза как такового (нет L2-связности), да еще и IPsec, который работает как прослойка между маршрутизацией и IP-стеком.

Клиент ходил с одного IP "94.73.250.34", и вдруг решил заглянуть с "192.168.20.7".

Это не так. Лог отображает назначенный IP-адрес внутри IPsec-туннеля: 192.168.20.7. Соединение устанавливается с адреса 94.73.250.34. Вы неверно читаете лог.

Скорее всего, проблема вызвана неудавшимся renegotiation'ом, возможно, из-за проблем с выбором шифра во время renegotiation. Автор, см. https://wiki.strongswan.org/projects/strongswan/wi... и https://docs.strongswan.org/docs/5.9/interop/windo...

[asmelnik]

ValdikSS Если есть назначение ip внутри туннеля, то это почти наверняка l2tp+ipsec.
И l2 таки там есть со всеми вытекающими.
Кстати "Адаптер PPP" говорит именно об этом

Возможно я и не прав.

[ValdikSS]

asmelnik,

Если есть назначение ip внутри туннеля, то это почти наверняка l2tp+ipsec.

Наоборот: IPsec-соединение в случае L2TP устанавливливается в транспортном режиме (без выдачи IP-адреса), а само PPP-соединение обслуживал бы сторонний демон, вроде xl2tpd, чего не видно в логах.

И l2 таки там есть со всеми вытекающими

L2TP тоже туннелирует только IP, несмотря на вводящее в заблуждение название — протокол создавался для установки туннеля поверх L2-инфраструктуры других операторов, чтобы пробросить пользователя в свою сеть.
Технически в L2TP есть поддержка bridging protocol, а в L2TPv3 поддержка туннелирования Ethernet-фреймов, но в Windows и то, и то не поддерживается.

Кстати "Адаптер PPP" говорит именно об этом

Это действительно странно, не помню, чтобы Windows отображал IPsec-соединение как PPP.