Периодически отваливается VPN‐соединение через Wireguard

[zyxmon]

34 минуты назад, ValdikSS сказал:

В логах при этом абсолютно никаких записей об изменении состояния соединения.

А что в логах сервера? Может там что полезное?

[ValdikSS]

26 минут назад, zyxmon сказал:

А что в логах сервера? Может там что полезное?

А что там должно быть? Я никаких пакетов не отправляю, соответственно, никаких пакетов и не ходит. Это же stateless-туннель. Но если соединение перешло в состояние неактивного (серая иконка вместо зелёной), то Keenetic и не пытается отправить пакеты на сервер, когда их начинает отправлять какое-либо устройство в сети.

Поясню, чтобы развеять возможное недопонимание: у меня для VPN заведен отдельный сегмент со своей сетью Wi-Fi. Wireguard-туннель добавлен в качестве единственного соединения в этом сегменте.
В обычном режиме трафик этой сети маршрутизируется через Wireguard. Однако если, например, подключиться к сети Wi-Fi в момент, когда индикатор туннеля серый, то интернета на устройствах нет.

Я не понимаю, по какой причине туннель может становиться неактивным: не вижу какой-либо функциональности heartbeat'а у WireGuard (кроме keep-alive), не вижу никаких попыток heartbeat'а в шифрованном трафике на порту WireGuard на сервере. Туннель просто переходит в неактивное состояние без видимых причин и без записей в журнале.

Keep-alive установлен в 600 секунд. Падает через 186 секунд.

Изменено 5 июня, 2023 пользователем ValdikSS

[ValdikSS]

3 минуты назад, ANDYBOND сказал:

а вот клиенту он нужен, причём не более 30 секунд

Keep-alive нужен, чтобы поддерживать NAT-маппинг к серверу, для того, чтобы сервер мог обратиться к клиенту. У меня нет ни NAT'а, ни необходимости сервера обращаться к клиенту.

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

[ValdikSS]

3 минуты назад, ANDYBOND сказал:

Ни у маршрутизатора, ни у провайдера и вообще нигде?

Нет, нигде. Да даже если бы был, это бы никак не помешало отправить пакет с роутера на сервер, а они не отправляются, когда туннель становится неактивным.

[ValdikSS]

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

Keep-alive равен нулю

Keep-alive установлен в 600. Вы теоретизируете, или действительно разбираетесь, как всё работает в Keenetic? Я сообщаю о проблеме, помочь я себе и сам могу.

Изменено 6 июня, 2023 пользователем ValdikSS

[Denis P]

3 часа назад, ValdikSS сказал:

Keep-alive нужен, чтобы поддерживать NAT-маппинг к серверу, для того, чтобы сервер мог обратиться к клиенту. У меня нет ни NAT'а, ни необходимости сервера обращаться к клиенту.

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

Попробуйте указать принудительно (с учетом вашего порта и интерфейса естественно)
ip static udp GigabitEthernet1 12345 127.0.0.1 12345

Убрал keepalive с обоих сторон, подождал 10 минут от последнего handshake, пакеты ходят

 

Изменено 6 июня, 2023 пользователем Denis P

[ValdikSS]

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

Попробуйте указать принудительно (с учетом вашего порта и интерфейса естественно)

Добавил, заменив только порт на тот, что указан как listening в настройке клиента. Увы, ничего не поменялось: 187 секунд и серый значок, при том, что какой-то трафик в течение 187 секунд в туннеле ходил (ACK'и и FIN-ACK'и от незакрытых соединений), но он не обновляет счётчик latest handshake.

[Denis P]

19 минут назад, ValdikSS сказал:

Добавил, заменив только порт на тот, что указан как listening в настройке клиента. Увы, ничего не поменялось: 187 секунд и серый значок, при том, что какой-то трафик в течение 187 секунд в туннеле ходил (ACK'и и FIN-ACK'и от незакрытых соединений), но он не обновляет счётчик latest handshake.

Да, действительно, проверил еще раз, работает только если кинетик выступает в качестве условно "сервера" а клиент другое устройство с официальным приложением wg которое и инициирует передачу данных.

[vasek00]

3 часа назад, ValdikSS сказал:

Keep-alive нужен, чтобы поддерживать NAT-маппинг к серверу, для того, чтобы сервер мог обратиться к клиенту. У меня нет ни NAT'а, ни необходимости сервера обращаться к клиенту.

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

Если брать конкретно Wireguard cloudflare warp то имеем по habr.com

Скрытый текст

Цитата

2022год

...что по всей видимости DPI нацелен на WireGuard Handshake Initiate пакеты, которые имеют фиксированный размер (148 байт) и узнаваемую структуру (первые четыре байта UDP пакета [0x01, 0x00, 0x00, 0x00]).

...

Сам по себе WireGuard протокол предельно простой, трафик упаковывается в совершенно типовой UDP с добавлением небольшого заголовка. Для согласования WireGuard туннеля, как правило, достаточно двух (трех, если считать Keepalive) пакетов:

• Сторона желающая установить туннель (клиент) отправляет Hadshake Initiation другой стороне (сервер).

• Если сервер в данный момент готов к подключению, то он отвечает клиенту пакетом Handshake Response.

• Клиент получает Handshake Response и отвечает Keepalive пакетом, который представляет собой UDP пакет с WireGuard заголовком типа "данные" нулевого размера. В дальнейшем ключи обновляются повторяя описанную процедуру примерно каждые две минуты.

Таким образом, кажется, что для блокировки WireGuard DPI достаточно отслеживать UDP пакеты размером в 148 байт и проверять в них первые четыре байта на соответствие сигнатуре [0x01, 0x00, 0x00, 0x00]. Однако, стоит упомянуть, что корпоративные реализации WireGuard могут использовать зарезервированные три байта (поле Reserved) для собственных нужд (например, в Jamf Private Access они используются как идентификатор сессии). К тому же не исключено, что рано или поздно им найдется применение и в официальном клиенте. Так что для большей точности имеет смысл ограничиться только первым байтом UDP пакета. С другой стороны блокировка всех UDP пакетов размером в 148 байт с первым байтом 0x01 выглядит довольно рискованно. То же самое можно сказать и о Handshake Response пакете, который так же имеет фиксированный размер (92 байта) и схожую сигнатуру с тремя зарезервированными байтами [0x02, 0x00, 0x00, 0x00].

.... https://habr.com/ru/articles/585962/

Цитата

...

wireguard_tick - данная функция должна периодически быть вызываема для каждого активного WireGuard туннеля. Рекомендуемый разработчиками интервал составляет 100ms. Функция может вернуть handshake (каждые две минуты) или keepalive пакет (в зависимости от значения параметра PersistentKeepalive), который надлежит отправить серверу.

wireguard_force_handshake - генерирует пакет WireGuard handshake. Функция обычно используется при первом подключении к серверу (в дальнейшем handshake пакеты генерирует функция wireguard_tick) или когда необходимо переподключиться к серверу в следствие изменения сетевого подключения, IP адреса и т.д. и т.п..

wireguard_stats - запрашивает текущую статистику по туннелю, которая включает в себя время происшедшее с последнего handshake, количество принятых/отправленных байт, оценочное значение потерь пакетов и RTT (Round-trip delay time)

...

 

Вот что реально при установленном значение Keep-Alive в 120 на роутере клиенте Keenetic все отрабатывает штатно (для проверки поднят туннель, но не одного клиента на нем нет). Ниже UDP пакетики где cloud warp адрес сервера 162.159.193.х а Keenetic IP адрес на интерфейсе выхода в интернет

Скрытый текст

при установке значения в 600 тут "бзик" по WEB и то что в реале.

В моем случае keep-alive стоит 120с.

[ValdikSS]

Поотлаживал еще.

Баг заключается в том, что туннель, после того, как сессия WireGuard «закрылась» (прошло 180 секунд с последнего handshake), не поднимается, когда клиент сегмента начинает отправлять пакеты в туннель.

Если отправить какой-либо пакет с самого роутера (например, ping'ом через CLI), либо же с сервера — туннель сразу же поднимается.

Некорректно работает какая-то подсистема, возможно, fastvpn.

Изменено 6 июня, 2023 пользователем ValdikSS

[ValdikSS]

10 минут назад, ANDYBOND сказал:

no ppe hardware

no ppe software

system configuration save

Это через CLI. И, получается, если после этого перезагрузить маршрутизатор, то проблема должна исчезнуть. Но это предположение: при возможности прошу проверить. 

Ничего не изменилось.

[ValdikSS]

23 минуты назад, ANDYBOND сказал:

Кардинальное решение такое

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

[ValdikSS]

Только что, ANDYBOND сказал:

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

Нет, не поможет. Отключения туннеля никак не связаны с conntrack.

[divinepredecessor]

Добрый день.

Hero (KN-1011) EU.
Кто-нибудь встречался с такой проблемой с NTP.
Заметил недавно галочку SNTP Server. Поставил, на нескольких устройствах настроил. Через какое-то время заметил, что время везде неправильное, в том числе на роутере. Речь идёт про минуты. Поставил на кинетике период синхронизации 1 час.
Стало лучше, но вылезла проблема с разрывом WireGuard каждый час. Видимо он и раньше рвался, но раз в 7 дней.
Лог выглядит примерно вот так:

Скрытый текст

Jun 12 16:44:30
Ntp::Client: time synchronized with "time.euro.apple.com".
Jun 12 16:44:30
Wireguard::Interface: "Wireguard0": triggering peers to reinitiate handshakes.
Jun 12 16:44:30
wireguard: Wireguard0: peer "blablabla=" (439) (ipaddress:port) destroyed
Jun 12 16:44:30
wireguard: Wireguard0: peer "blablabla=" (445) created
Jun 12 16:44:45
wireguard: Wireguard0: receiving handshake initiation from peer "blablabla=" (445) (ipaddress:port)
Jun 12 15:44:45
wireguard: Wireguard0: sending handshake response to peer "blablabla=" (445) (ipaddress:port)

На другом конце (Giga SE (KN-2410) RU):

Скрытый текст

Jun 12 16:44:45
kernelwireguard: Wireguard0: retrying handshake with peer "blablabla2=" (596) (ipaddress2:port2) because we stopped hearing back after 15 seconds

Как-то можно сделать чтобы не рвался туннель при синхронизации времени? Или так и должно быть?

Наблюдаю подобное на нескольких девайсах.

Изменено 13 июня, 2023 пользователем divinepredecessor

[Le ecureuil]

Спасибо за репорт, будет поправлено в следующих выпусках.

[stefbarinov]

Со вчерашнего дня пошли обрывы Warp (WG) с ошибкой в логе:

Wireguard1: handshake for peer "bmXOC+F1FxEMF9dyiK2H5/1drgdgtdgdrgr+dgd=" (163) (162.159.193.5:2408) did not complete after 2164852204 seconds, retrying (try 5)

Соответственно вся маршрутизация через Warp встала......при чем на двух маршрутизаторах в разных городах на разных ISP

Изменено 22 августа пользователем stefbarinov

[Le ecureuil]

42 минуты назад, stefbarinov сказал:

Со вчерашнего дня пошли обрывы Warp (WG) со ошибкой в логе:

Wireguard1: handshake for peer "bmXOC+F1FxEMF9dyiK2H5/1drgdgtdgdrgr+dgd=" (163) (162.159.193.5:2408) did not complete after 2164852204 seconds, retrying (try 5)

Соответственно вся маршрутизация через Warp встала......при чем на двух маршрутизаторах в разных городах на разных ISP

Есть уверенность, что это не "внешние силы"?

[SySOPik]

52 минуты назад, stefbarinov сказал:

Wireguard1: handshake for peer "bmXOC+F1FxEMF9dyiK2H5/1drgdgtdgdrgr+dgd=" (163) (162.159.193.5:2408) did not complete after 2164852204 seconds, retrying (try 5)

Оно уже давно так. У меня на всех роутерах где Warp такое появляется.

Скрытый текст

Сер 22 10:52:29

 

kernel

wireguard: Wireguard1: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (3) (162.159.192.1:2408) because we stopped hearing back after 2214756448 seconds

 

[stefbarinov]

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

Оно уже давно так.

Вчера после массового отвала Телеграмм отвалился и Warp. До вчерашнего дня долгое время беспроблемно работал

[stefbarinov]

18 минут назад, Le ecureuil сказал:

Есть уверенность, что это не "внешние силы"?

Есть такое. Найти бы пути решения.....без ютьюба тяжко

[vasek00]

41 минуту назад, SySOPik сказал:

Оно уже давно так. У меня на всех роутерах где Warp такое появляется.

Давно такое не появляется.

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

Вчера после массового отвала Телеграмм отвалился и Warp. До вчерашнего дня долгое время беспроблемно работал

В моем случае не было такого.

[stefbarinov]

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

В моем случае не было такого

В моем случае на всех роутерах Warp "потух"......

[mega1volt]

Аналогично со вчерашнего дня Warp не работает. Провайдер ТТК. Башкортостан.

[vasek00]

3 часа назад, stefbarinov сказал:

В моем случае на всех роутерах Warp "потух"......

Думаю вы в курсе как его поднимать + генерите новые ключи и скорей всего он заработает.

[stefbarinov]

3 минуты назад, vasek00 сказал:

генерите новые ключи и скорей всего он заработает.

Пробовал генерить новые ключи. На одном маршрутизаторе "взлетело" (ISP Ростелеком), на другом (ISP Beeline) - ни в какую. Соединение поднимается и через минуту в логах побежали хэндшейки....

[AlexeyVes]

Не поднимается, даже после генерации нового конфига

[stefbarinov]

6 часов назад, vasek00 сказал:

В моем случае не было такого.

Наблюдаю следующее: сгенерировал (уже ни раз) новый конфиг, соединение устанавливается и "живет" до тех пор, пока не применена политика Warp хотя бы к одному клиенту. Как только закинул клиента в эту политику (пошёл трафик), сразу хендшейки.

Скрытый текст

 

[vasek00]

27 минут назад, stefbarinov сказал:

Наблюдаю следующее: сгенерировал (уже ни раз) новый конфиг, соединение устанавливается и "живет" до тех пор, пока не применена политика Warp хотя бы к одному клиенту. Как только закинул клиента в эту политику (пошёл трафик), сразу хендшейки.

Как то хитро у вас

Скрытый текст

interface Wireguard0
    description Cloud
...
    keepalive-interval 120

ip policy Policy0
    description Cl
    permit global Wireguard0

ip hotspot

    host MAC_Клиент1 permit
    host MAC_Клиент1 policy Policy0

 

На лог не обращаю внимания

Скрытый текст

Авг 22 19:26:40 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 19:17:00 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 19:10:28 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 19:07:59 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 19:07:38 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 18:56:34 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 18:53:49 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 18:52:26 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 18:50:06 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 
Авг 22 18:48:36 kernel wireguard: Wireguard0: retrying handshake with peer "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=" (39) (ххх.ххх.ххх.ххх:хххх) because we stopped hearing back after 15 seconds 

 

Посмотрю еще в одном месте

[FLK]

Да, что-то пучит WARP, но не везде

[avn]

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

Да, что-то пучит WARP, но не везде

На 4.2.3 можно будет попробовать client_id прописать.

interface Wireguard2 wireguard peer bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= client-id send 1234567