zyxmon Posted June 5, 2023 Share Posted June 5, 2023 34 минуты назад, ValdikSS сказал: В логах при этом абсолютно никаких записей об изменении состояния соединения. А что в логах сервера? Может там что полезное? Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 5, 2023 Share Posted June 5, 2023 (edited) 26 минут назад, zyxmon сказал: А что в логах сервера? Может там что полезное? А что там должно быть? Я никаких пакетов не отправляю, соответственно, никаких пакетов и не ходит. Это же stateless-туннель. Но если соединение перешло в состояние неактивного (серая иконка вместо зелёной), то Keenetic и не пытается отправить пакеты на сервер, когда их начинает отправлять какое-либо устройство в сети. Поясню, чтобы развеять возможное недопонимание: у меня для VPN заведен отдельный сегмент со своей сетью Wi-Fi. Wireguard-туннель добавлен в качестве единственного соединения в этом сегменте. В обычном режиме трафик этой сети маршрутизируется через Wireguard. Однако если, например, подключиться к сети Wi-Fi в момент, когда индикатор туннеля серый, то интернета на устройствах нет. Я не понимаю, по какой причине туннель может становиться неактивным: не вижу какой-либо функциональности heartbeat'а у WireGuard (кроме keep-alive), не вижу никаких попыток heartbeat'а в шифрованном трафике на порту WireGuard на сервере. Туннель просто переходит в неактивное состояние без видимых причин и без записей в журнале. Keep-alive установлен в 600 секунд. Падает через 186 секунд. Edited June 5, 2023 by ValdikSS 1 Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 6, 2023 Share Posted June 6, 2023 3 минуты назад, ANDYBOND сказал: а вот клиенту он нужен, причём не более 30 секунд Keep-alive нужен, чтобы поддерживать NAT-маппинг к серверу, для того, чтобы сервер мог обратиться к клиенту. У меня нет ни NAT'а, ни необходимости сервера обращаться к клиенту. Аналогично настроенный туннель на OpenWrt к тому же серверу работает корректно, даже если по нему не передаются пакеты сутками, без Keep-Alive. 1 Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 6, 2023 Share Posted June 6, 2023 3 минуты назад, ANDYBOND сказал: Ни у маршрутизатора, ни у провайдера и вообще нигде? Нет, нигде. Да даже если бы был, это бы никак не помешало отправить пакет с роутера на сервер, а они не отправляются, когда туннель становится неактивным. 1 Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 6, 2023 Share Posted June 6, 2023 (edited) 2 минуты назад, ANDYBOND сказал: Keep-alive равен нулю Keep-alive установлен в 600. Вы теоретизируете, или действительно разбираетесь, как всё работает в Keenetic? Я сообщаю о проблеме, помочь я себе и сам могу. Edited June 6, 2023 by ValdikSS 1 Quote Link to comment Share on other sites More sharing options...
Denis P Posted June 6, 2023 Share Posted June 6, 2023 (edited) 3 часа назад, ValdikSS сказал: Keep-alive нужен, чтобы поддерживать NAT-маппинг к серверу, для того, чтобы сервер мог обратиться к клиенту. У меня нет ни NAT'а, ни необходимости сервера обращаться к клиенту. Аналогично настроенный туннель на OpenWrt к тому же серверу работает корректно, даже если по нему не передаются пакеты сутками, без Keep-Alive. Попробуйте указать принудительно (с учетом вашего порта и интерфейса естественно) ip static udp GigabitEthernet1 12345 127.0.0.1 12345 Убрал keepalive с обоих сторон, подождал 10 минут от последнего handshake, пакеты ходят Edited June 6, 2023 by Denis P 1 Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 6, 2023 Share Posted June 6, 2023 15 минут назад, Denis P сказал: Попробуйте указать принудительно (с учетом вашего порта и интерфейса естественно) Добавил, заменив только порт на тот, что указан как listening в настройке клиента. Увы, ничего не поменялось: 187 секунд и серый значок, при том, что какой-то трафик в течение 187 секунд в туннеле ходил (ACK'и и FIN-ACK'и от незакрытых соединений), но он не обновляет счётчик latest handshake. 1 Quote Link to comment Share on other sites More sharing options...
Denis P Posted June 6, 2023 Share Posted June 6, 2023 19 минут назад, ValdikSS сказал: Добавил, заменив только порт на тот, что указан как listening в настройке клиента. Увы, ничего не поменялось: 187 секунд и серый значок, при том, что какой-то трафик в течение 187 секунд в туннеле ходил (ACK'и и FIN-ACK'и от незакрытых соединений), но он не обновляет счётчик latest handshake. Да, действительно, проверил еще раз, работает только если кинетик выступает в качестве условно "сервера" а клиент другое устройство с официальным приложением wg которое и инициирует передачу данных. 1 Quote Link to comment Share on other sites More sharing options...
vasek00 Posted June 6, 2023 Share Posted June 6, 2023 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с. Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 6, 2023 Share Posted June 6, 2023 (edited) Поотлаживал еще. Баг заключается в том, что туннель, после того, как сессия WireGuard «закрылась» (прошло 180 секунд с последнего handshake), не поднимается, когда клиент сегмента начинает отправлять пакеты в туннель. Если отправить какой-либо пакет с самого роутера (например, ping'ом через CLI), либо же с сервера — туннель сразу же поднимается. Некорректно работает какая-то подсистема, возможно, fastvpn. Edited June 6, 2023 by ValdikSS 1 Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 6, 2023 Share Posted June 6, 2023 10 минут назад, ANDYBOND сказал: no ppe hardware no ppe software system configuration save Это через CLI. И, получается, если после этого перезагрузить маршрутизатор, то проблема должна исчезнуть. Но это предположение: при возможности прошу проверить. Ничего не изменилось. 1 Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 7, 2023 Share Posted June 7, 2023 23 минуты назад, ANDYBOND сказал: Кардинальное решение такое Не знаю, как это должно помочь. У меня нет NAT, и проблема не сетевая. Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 7, 2023 Share Posted June 7, 2023 Только что, ANDYBOND сказал: Но пользователям Кинетика это поможет, если что. Нет, не поможет. Отключения туннеля никак не связаны с conntrack. Quote Link to comment Share on other sites More sharing options...
divinepredecessor Posted June 13, 2023 Share Posted June 13, 2023 (edited) Добрый день. 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 June 13, 2023 by divinepredecessor Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted June 15, 2023 Share Posted June 15, 2023 Спасибо за репорт, будет поправлено в следующих выпусках. 1 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.