Jump to content

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


Recommended Posts

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

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

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

Link to comment
Share on other sites

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

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

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

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

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

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

Edited by ValdikSS
  • Thanks 1
Link to comment
Share on other sites

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

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

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

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

  • Thanks 1
Link to comment
Share on other sites

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

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

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

  • Thanks 1
Link to comment
Share on other sites

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

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

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

Edited by ValdikSS
  • Thanks 1
Link to comment
Share on other sites

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

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

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

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

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

 

Edited by Denis P
  • Y'r wrong 1
Link to comment
Share on other sites

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

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

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

  • Thanks 1
Link to comment
Share on other sites

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

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

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

  • Y'r wrong 1
Link to comment
Share on other sites

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 адрес на интерфейсе выхода в интернет

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

-3.jpg.80fb42cdb8a9164ea004327689b43524.jpg

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

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

Link to comment
Share on other sites

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

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

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

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

Edited by ValdikSS
  • Thanks 1
Link to comment
Share on other sites

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

no ppe hardware

no ppe software

system configuration save

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

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

  • Thanks 1
Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

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

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

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

Link to comment
Share on other sites

Добрый день.

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


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

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

Edited by divinepredecessor
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...