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 Спасибо за репорт, будет поправлено в следующих выпусках. 2 2 Quote Link to comment Share on other sites More sharing options...
stefbarinov Posted August 22 Share Posted August 22 (edited) Со вчерашнего дня пошли обрывы 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 Edited August 22 by stefbarinov Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted August 22 Share Posted August 22 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 Есть уверенность, что это не "внешние силы"? Quote Link to comment Share on other sites More sharing options...
SySOPik Posted August 22 Share Posted August 22 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 Quote Link to comment Share on other sites More sharing options...
stefbarinov Posted August 22 Share Posted August 22 6 минут назад, SySOPik сказал: Оно уже давно так. Вчера после массового отвала Телеграмм отвалился и Warp. До вчерашнего дня долгое время беспроблемно работал Quote Link to comment Share on other sites More sharing options...
stefbarinov Posted August 22 Share Posted August 22 18 минут назад, Le ecureuil сказал: Есть уверенность, что это не "внешние силы"? Есть такое. Найти бы пути решения.....без ютьюба тяжко Quote Link to comment Share on other sites More sharing options...
vasek00 Posted August 22 Share Posted August 22 41 минуту назад, SySOPik сказал: Оно уже давно так. У меня на всех роутерах где Warp такое появляется. Давно такое не появляется. 35 минут назад, stefbarinov сказал: Вчера после массового отвала Телеграмм отвалился и Warp. До вчерашнего дня долгое время беспроблемно работал В моем случае не было такого. Quote Link to comment Share on other sites More sharing options...
stefbarinov Posted August 22 Share Posted August 22 6 минут назад, vasek00 сказал: В моем случае не было такого В моем случае на всех роутерах Warp "потух"...... Quote Link to comment Share on other sites More sharing options...
mega1volt Posted August 22 Share Posted August 22 Аналогично со вчерашнего дня Warp не работает. Провайдер ТТК. Башкортостан. Quote Link to comment Share on other sites More sharing options...
vasek00 Posted August 22 Share Posted August 22 3 часа назад, stefbarinov сказал: В моем случае на всех роутерах Warp "потух"...... Думаю вы в курсе как его поднимать + генерите новые ключи и скорей всего он заработает. Quote Link to comment Share on other sites More sharing options...
stefbarinov Posted August 22 Share Posted August 22 3 минуты назад, vasek00 сказал: генерите новые ключи и скорей всего он заработает. Пробовал генерить новые ключи. На одном маршрутизаторе "взлетело" (ISP Ростелеком), на другом (ISP Beeline) - ни в какую. Соединение поднимается и через минуту в логах побежали хэндшейки.... Quote Link to comment Share on other sites More sharing options...
AlexeyVes Posted August 22 Share Posted August 22 Не поднимается, даже после генерации нового конфига Quote Link to comment Share on other sites More sharing options...
stefbarinov Posted August 22 Share Posted August 22 6 часов назад, vasek00 сказал: В моем случае не было такого. Наблюдаю следующее: сгенерировал (уже ни раз) новый конфиг, соединение устанавливается и "живет" до тех пор, пока не применена политика Warp хотя бы к одному клиенту. Как только закинул клиента в эту политику (пошёл трафик), сразу хендшейки. Скрытый текст 1 Quote Link to comment Share on other sites More sharing options...
vasek00 Posted August 22 Share Posted August 22 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 Посмотрю еще в одном месте Quote Link to comment Share on other sites More sharing options...
FLK Posted August 22 Share Posted August 22 Да, что-то пучит WARP, но не везде Quote Link to comment Share on other sites More sharing options...
avn Posted August 22 Share Posted August 22 1 минуту назад, FLK сказал: Да, что-то пучит WARP, но не везде На 4.2.3 можно будет попробовать client_id прописать. interface Wireguard2 wireguard peer bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo= client-id send 1234567 1 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.