Denis P Posted June 6 Share Posted June 6 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 Share Posted June 6 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 Share Posted June 6 (edited) Поотлаживал еще. Баг заключается в том, что туннель, после того, как сессия WireGuard «закрылась» (прошло 180 секунд с последнего handshake), не поднимается, когда клиент сегмента начинает отправлять пакеты в туннель. Если отправить какой-либо пакет с самого роутера (например, ping'ом через CLI), либо же с сервера — туннель сразу же поднимается. Некорректно работает какая-то подсистема, возможно, fastvpn. Edited June 6 by ValdikSS 2 Quote Link to comment Share on other sites More sharing options...
ANDYBOND Posted June 6 Share Posted June 6 no ppe hardware no ppe software system configuration save Это через CLI. И, получается, если после этого перезагрузить маршрутизатор, то проблема должна исчезнуть. Но это предположение: при возможности прошу проверить. Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 6 Share Posted June 6 10 минут назад, ANDYBOND сказал: no ppe hardware no ppe software system configuration save Это через CLI. И, получается, если после этого перезагрузить маршрутизатор, то проблема должна исчезнуть. Но это предположение: при возможности прошу проверить. Ничего не изменилось. 2 Quote Link to comment Share on other sites More sharing options...
ANDYBOND Posted June 6 Share Posted June 6 @ValdikSS Понял. Спасибо. Но попытаться стоило. Quote Link to comment Share on other sites More sharing options...
ANDYBOND Posted June 7 Share Posted June 7 (edited) 19 часов назад, ValdikSS сказал: не поднимается Понятно, что лучше, чтоб он сам возобновлял свою работу. Баг или особенность протокола WG - затрудняюсь сказать, ибо по документации разработчиков WG оно там само должно работать. Но можно сделать так, чтобы он не падал. Ибо всё же есть keep-alive, пусть и 600 секунд. Кардинальное решение такое: system set net.netfilter.nf_conntrack_udp_timeout 1800 system set net.netfilter.nf_conntrack_udp_timeout_stream 1800 system configuration save И перезагрузка. Так установленные UDP-сессии и стриминговые UDP-сессии станут жить не 30 секунд и 3 минуты соответственно, как по умолчанию, а 30 минут. Благо, ОЗУ достаточно, чтобы такое себе позволить. Edited June 7 by ANDYBOND Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 7 Share Posted June 7 23 минуты назад, ANDYBOND сказал: Кардинальное решение такое Не знаю, как это должно помочь. У меня нет NAT, и проблема не сетевая. 1 Quote Link to comment Share on other sites More sharing options...
ANDYBOND Posted June 7 Share Posted June 7 14 минуты назад, ValdikSS сказал: это должно помочь Я помню об отсутствии NAT. Но пользователям Кинетика это поможет, если что. Quote Link to comment Share on other sites More sharing options...
ValdikSS Posted June 7 Share Posted June 7 Только что, ANDYBOND сказал: Но пользователям Кинетика это поможет, если что. Нет, не поможет. Отключения туннеля никак не связаны с conntrack. 1 Quote Link to comment Share on other sites More sharing options...
ANDYBOND Posted June 7 Share Posted June 7 1 минуту назад, ValdikSS сказал: Отключения туннеля никак не связаны с conntrack. Разрывы связи по VoIP тоже вроде как с этим не связаны, но тот рецепт помогает их решить: клиенты становятся способны восстанавливать оборванное соединение. Потому теоретически может помочь. По крайней мере, больше мыслей в этом направлении лично у меня нет ни с какой стороны. Quote Link to comment Share on other sites More sharing options...
divinepredecessor Posted June 13 Share Posted June 13 (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 by divinepredecessor Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted June 15 Share Posted June 15 Спасибо за репорт, будет поправлено в следующих выпусках. 2 2 Quote Link to comment Share on other sites More sharing options...
ANDYBOND Posted July 6 Share Posted July 6 (edited) В 01.06.2023 в 22:50, ANDYBOND сказал: Но с времён возникновения тех проблем, о которых выше сказано, я понял, что клиент WG в Кинетике почему-то нестандартный, соответственно, узкоприменимый, а в моём случае просто неприменимый. И вот ещё пример сюда же. И хороший вопрос сюда же. Цитата не так давно использую Модель Viva (KN-1912) RU Версия ОС 3.9.8 Настроил wireguard через него на своей впс, заметил что стабильно каждые пару недель он перестает работать, вкл-выкл в админке не помогает, чтобы снова заработал необходимо полностью перезагружать роутер. Что же надо сделать чтобы такого более не происходило? https://4pda.to/forum/index.php?showtopic=929843&view=findpost&p=123691569 В Кинетике WG не использовать, ибо WG реализован странно и нестандартно. Но, нет, вы не понимаете: "это - другое". Тоже самое. Edited July 7 by ANDYBOND 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.