Выключить Persistent keepalive в Wireguard

[nett]

Документация Wireguard говорит Silence is a Virtue, сетевое молчание - это хорошо, https://www.wireguard.com/papers/wireguard.pdf

Я подтверждаю, молчание - это действительно хорошо, особенно в KN-2310 с LTE модемом. Базовые станции могут "усыплять" соединения, переводя антенны в low power mode, когда от станции(модема) нет трафика. Тем самым мы экономим ресурс радиоканала, ресурсы БС и Кинетика.

Тест кейс:

2 кинетика объединены в сеть при помощи тоннеля Wireguard как в примере https://help.keenetic.com/hc/ru/articles/360012075879-Настройка-WireGuard-VPN-между-двумя-роутерами-Keenetic

при этом на обоих кинетиках выключен Persistent keepalive

 

Ожидаемый результат: VPN соединение работает

Фактический результат: VPN соединение не работает, ping из веб-интерфейса одного Кинетика не получает ответ от второго Кинетика, в логах ничего не происходит, счетчики переданного и полученного трафика по VPN тоннелю равны 0

[vasek00]

1 час назад, nett сказал:

Документация Wireguard говорит Silence is a Virtue, сетевое молчание - это хорошо, https://www.wireguard.com/papers/wireguard.pdf

при этом на обоих кинетиках выключен Persistent keepalive

 

Ожидаемый результат: VPN соединение работает

Фактический результат: VPN соединение не работает, ping из веб-интерфейса одного Кинетика не получает ответ от второго Кинетика, в логах ничего не происходит, счетчики переданного и полученного трафика по VPN тоннелю равны 0

Познавательно почитать https://habr.com/ru/company/indriver/blog/586006/

Цитата

ZakharovAV 2 ноября 2021 в 14:39

Wireguard. How it was

 

...

PersistentKeepalive — об этом упомяну отдельно...

...

Еще одна проблема возникает при мониторинге состояния WireGuard. Оказалось, что если сервер A не обращается какое-то время к серверу B, handshake не происходит! Как быть?

Можно повесить задачу на пинги всех пиров раз в минуту. Но это не самое лучшее решение. На помощь приходит вышеупомянутый параметр PersistentKeepalive. Примечательно, что в документации указано, что он нужен для сохранения состояния в файрволе (имеются в виду таймауты соединений) при работе через NAT:

PersistentKeepalive — a seconds interval, between 1 and 65535 inclusive, of how often to send an authenticated empty packet to the peer for the purpose of keeping a stateful firewall or NAT mapping valid persistently.

На деле же раз в указанный промежуток пиру посылается пакет нулевого размера. Это позволяет поддерживать соединение постоянно открытым.

Заметил, что при отсутствии этого параметра возникал неприятный баг. При отсутствии соединения, даже если пинговать пир, рукопожатия не возникало, пока вручную с обратной стороны не начать пинговать пир в ответ. Сервер пытается установить рукопожатие, а с той стороны ответа нет, так как взаимодействия с сервером отсутствует. Чтобы такого не происходило, нужно использовать PersistentKeepalive на всех хостах или на центральном шлюзе.

Принято! Выходит, что:

• PersistentKeepalive не должен быть равен нулю.

• Резюме

  Моей изначальной целью было поглубже раскрыть, что такое WireGuard и что надо помнить, когда с ним работаешь. Данная статья — результат тщательного исследования работы этого VPN.

И как итого по вашему вопросу

Цитата

 

Ожидаемый результат: VPN соединение работает

Фактический результат: VPN соединение не работает, ping из веб-интерфейса одного Кинетика не получает ответ от второго Кинетика, в логах ничего не происходит, счетчики переданного и полученного трафика по VPN тоннелю равны 0

 

Если на стороне сервера стоит 0 а на стороне клиента любое отличное от 0 то все работает, если оба 0 то не работает.

Edited May 13, 2022 by vasek00

[nett]

6 hours ago, vasek00 said:

Если на стороне сервера стоит 0 а на стороне клиента любое отличное от 0 то все работает, если оба 0 то не работает

Если взять офф клиент wireguard и Кинетик, на обоих сторонах выключить Persistent keepalive, то все работает. Если взять два офф клиента, то тоже работает. Подробности по ссылке из моего поста - там рассказывается, почему это должно работать и почему это правильно.

Пример с хабра некорректный т.к автор пишет, что ему keepalive нужен для того, чтобы держать соединения открытыми в фаерволлах и натах. У меня нет натов и фаерволлов, по-этому потребности в keepalive нет, и наоборот - keepalive вредит в описанном мной примере.

[vasek00]

7 часов назад, nett сказал:

Если взять офф клиент wireguard и Кинетик, на обоих сторонах выключить Persistent keepalive, то все работает. Если взять два офф клиента, то тоже работает. Подробности по ссылке из моего поста - там рассказывается, почему это должно работать и почему это правильно.

Вчера проверил два Keenetic Wireguard при 0 на сервере и на клиенте не работает, как только на клиенте любое значение отличное от 0 то сразу все ок. Провайдеры провод и pppoe.

[nett]

6 hours ago, vasek00 said:

Вчера проверил два Keenetic Wireguard при 0 на сервере и на клиенте не работает, как только на клиенте любое значение отличное от 0 то сразу все ок. Провайдеры провод и pppoe.

1. Persistent keepalive выключается удалением строчки из конфига или удалением значения из веб интерфейса Кинетик, туда не нужно писать 0

2. Исключите провайдера и проверьте в локалке, например так:

server.conf

[Interface]
PrivateKey = qIsE62MCrjyo9rtMqENes9EMx3LUMSjOtc9sOqwb3XI=
Address = 172.16.1.1/25
ListenPort = 1234

[Peer]
PublicKey = VpmqIsUyTjxRBgLeT2hpGgWNi4Jh9b1pkiYWFrBreTE=
AllowedIPs = 172.16.1.2/32

 

client.conf

[Interface]
PrivateKey = qO9crTj5QtpwhQa67KnKIyoYES938zKcDe75XpRI43w=
Address = 172.16.1.2

[Peer]
PublicKey = w43+hTKikiyN0lNWC0h4t3qlQ3n7JVD8dWXhcwRooEs=
AllowedIPs = 172.16.1.1/32
Endpoint = 192.168.0.1:1234

 

 

 

[vasek00]

1 час назад, nett сказал:

1. Persistent keepalive выключается удалением строчки из конфига или удалением значения из веб интерфейса Кинетик, туда не нужно писать 0

Тест кейс:

2 кинетика объединены в сеть при помощи тоннеля Wireguard как в примере https://help.keenetic.com/hc/ru/articles/360012075879-Настройка-WireGuard-VPN-между-двумя-роутерами-Keenetic

при этом на обоих кинетиках выключен Persistent keepalive

 

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

 

0 - имелось ввиду конечно же "пустая строка", а в ответ тишина и лог пустой даже показать не чего.

При установленном значение например 30

На клиенте установка параметра в 30

....
Май 14 16:29:27 ndm Wireguard::Interface: "Wireguard2": set peer "fxrW....bxBo=" endpoint to "ххх.ххх.ххх.ххх:65101".
Май 14 16:29:27 ndm Wireguard::Interface: "Wireguard2": set peer "fxrW....bxBo=" keepalive interval to "30".
Май 14 16:29:27 ndm Wireguard::Interface: "Wireguard2": reset preshared key for peer "fxrW....bxBo=".
Май 14 16:29:27 ndm Wireguard::Interface: "Wireguard2": add allowed IPs "10.16.131.1/255.255.255.255" from peer "fxrW....bxBo=".
Май 14 16:29:27 ndm Wireguard::Interface: "Wireguard2": add allowed IPs "192.168.1.0/255.255.255.0" from peer "fxrWfxrW....bxBo=".
Май 14 16:29:27 ndm Wireguard::Interface: "Wireguard2": set listen port to "65101". 


И как итог сразу же на серервере в логе

Май 14 16:29:30 kernel wireguard: Wireguard0: receiving handshake initiation from peer "zGZ5...............Q00=" (12) (ххх.ххх.ххх.ххх:хххх) 
Май 14 16:29:30 kernel wireguard: Wireguard0: sending handshake response to peer "zGZ5....................4Q00=" (12) (ххх.ххх.ххх.ххх:хххх) 

Без handshake initiation и handshake response канала между двумя роутерами нет.

[nett]

11 minutes ago, vasek00 said:

0 - имелось ввиду конечно же "пустая строка", а в ответ тишина и лог пустой даже показать не чего.

Все верно, хендшейк должен произойти в первых пакетах когда "клиент" отправит данные "серверу", например - пинг.

[vasek00]

21 минуту назад, nett сказал:

Все верно, хендшейк должен произойти в первых пакетах когда "клиент" отправит данные "серверу", например - пинг.

Какие ping вы о чем?

 

Смотрел почему проблемы были на Cloudflare warp при подключение Keenetic к нему. Кееnetic уже несколько минут как поднял соединение но не работает (т.е. не кто не использует поднятый канал WG) далее смотрим что в итоге, через некоторое время начинает работать клиент просто что-то скачивая через данный канал WG.

Настройка на роутере Keenetic значения keepalive равное 15сек.

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

 

Edited May 14, 2022 by vasek00

[r13]

В 13.05.2022 в 16:55, nett сказал:

Документация Wireguard говорит Silence is a Virtue, сетевое молчание - это хорошо, https://www.wireguard.com/papers/wireguard.pdf

Я подтверждаю, молчание - это действительно хорошо, особенно в KN-2310 с LTE модемом. Базовые станции могут "усыплять" соединения, переводя антенны в low power mode, когда от станции(модема) нет трафика. Тем самым мы экономим ресурс радиоканала, ресурсы БС и Кинетика.

Это применимо в случае белых ip c обоих сторон и при этом требуется указывать порт и сервера и клиента с обоих сторон

В случае LTE модема не взлетит, keep alive нужен для поддержания nat сессии у сотового оператора

[nett]

9 hours ago, r13 said:

Это применимо в случае белых ip c обоих сторон и при этом требуется указывать порт и сервера и клиента с обоих сторон

В случае LTE модема не взлетит, keep alive нужен для поддержания nat сессии у сотового оператора

Это не так, я дал ссылку на главу Silence is Virtue в спеке Wireguard, в той же спеке написано подробнее про протокол на примере роаминга между мобильными операторами - клиент может переключиться между операторами без разрыва соединения Wireguard и без необходимости хендшейка при переключении - когда новый пакет придет из другой сети, в Cryptokey Routing таблице появится новая строчка "последний раз этого клиента видели с такого ip:port" - необходимости поддерживать "сессию" нет т.к Wireguard пытается быть Stateless

 

Более того, это работает в примере, который я привел. То, как ведет себя Кинетик - это баг Кинетика, так не должно быть.

Давайте продемонстрирую на примере ("сервер" на Кинетике, "клиент" на ноутбуке, PersistentKeepalive не задан на Кинетике, PersistentKeepalive = 0 у клиента):

03:05 подняли тоннель, хендшейка не происходит
03:07 ping -c 1 передано 2 пакета, хендшейк произошел:

May 15 03:07:09
kernel
wireguard: Wireguard0: receiving handshake initiation from peer <public key>
May 15 03:07:09
kernel
wireguard: Wireguard0: sending handshake response to peer <public key>

3:16 прошло 10 минут, Кинетик-"сервер" говорит, что давно не видел трафика от клиента и сбрасывает ключи:
May 15 03:16:18
kernel
wireguard: Wireguard0: zeroing out all keys for peer <public key>, since we haven't received a new one in 540 seconds
  
пакетов все-еще не передается, ни от "клиента", ни от "сервера", единственные пакеты мы передали в 03:07
  
3:20 ping -c 1 передано 3 пакета, произошел хендшейк:
  
May 15 03:20:58
kernel
wireguard: Wireguard0: receiving handshake initiation from peer <public key>
May 15 03:20:58
kernel
wireguard: Wireguard0: sending handshake response to peer <public key>

 

[nett]

я перечитал свои сообщения и я сделал 2 минорных ошибки, сейчас исправлюсь

On 5/14/2022 at 12:13 AM, nett said:

У меня нет натов и фаерволлов, по-этому потребности в keepalive нет, и наоборот - keepalive вредит в описанном мной примере.

r13 прав, конечно же у меня есть 2 NAT'a на Кинетике и на ОПСОСе в описанном примере. я думал про белый IP у сервера когда писал.

Keepalive вредит т.к если на ОПСОСе платный трафик, то каждый keepalive пакет будет тарифицироваться по минимальному объему трафика (128кб вроде у МФ), а также он будет переводить антенны кинетика и БС в high power state, занимать радиоканал и впустую тратить ресурсы БС, в случае если таймаут станции(кинетика или телефона) на БС меньше, чем keepalive на тоннеле Wireguard.

В догонку к предыдущему сообщению: подробности в главе 2.1 Endpoints & Roaming https://www.wireguard.com/papers/wireguard.pdf

 

13 hours ago, nett said:

1. Persistent keepalive выключается удалением строчки из конфига или удалением значения из веб интерфейса Кинетик, туда не нужно писать 0

тут тоже ошибка, я начитался про Кинетик, в котором выключение происходит через удаление значения Persistent keepalive из веб интерфейса. В офф клиенте Wireguard можно не указывать ключ PersistentKeepalive в конфиге, в этом случае моя сборка (последняя офф) дефолтится на 10 минут. Для того, чтобы выключить keepalive полностью нужно указать 0.

[nett]

Up!

Подскажите пожалуйста, этот баг можно зарепортить в разработку?

[Le ecureuil]

Не очень понял что именно вам нужно. Много воды, а смысла - не очень.

[qmxocynjca]

Автор поднял действительно существующую проблему, когда неактивная WG сессия не должна быть равна мёртвому интерфейсу. На примере ниже кинетик-клиент, т.е. тот кто инициирует соединение, в свойствах указан keepalive 3600. Без трафика это соединение становится "сереньким" после нескольких минут, то же самое получаем сразу, если поле keepalive просто оставить пустым:

В таком состоянии я не могу достучаться до удалённых адресов, хотя они прописаны в интерфейсе, статические маршруты на эти адреса добавлены, сам интерфейс включён переключателем слева. Я ожидаю что любой запрос на прописанные подсети должен идти через WG, даже если кружок серый, т.е. WG должен начать хендшейк в этот момент.

Судя по-всему, имплементация WG в кинетике немного отличается от подхода WG на обычном линуксе - там если wg up выполнен, то интерфейс всегда доступен и трафик пытается идти через него, даже если сам WG с другой стороной не связан (не важно - таймаут или просто выключен свет). В кинетике же, если WG связности нет (серый кружок вместо зеленого на пире), то интерфейс считается оффлайн и трафик через него перестаёт роутиться.

Кажется, суть сводится к тому, чтобы иметь опцию а-ля "Пир всегда доступен" как раз на этот случай, чтобы маршруты были живы, но чтобы WG-пир мог быть в "оффлайне", пока через него не пойдёт трафик. Вполне вероятно что эта опция может быть автоматически установлена при пустом значении "Порт прослушивания", но надо быть аккуратным с "Использовать для выхода в интернет", т.к. в этом случае отвалившийся WG-пир всё-таки должен сносить маршруты, чтобы интернет мог фолбэкнуться на основного провайдера.

Edited June 8, 2022 by qmxocynjca

[nett]

On 6/3/2022 at 5:32 PM, Le ecureuil said:

Не очень понял что именно вам нужно. Много воды, а смысла - не очень.

Мне нужно, чтобы починили тест-кейс из первого сообщения

[SySOPik]

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

держал сессию с сервером в активном состоянии при нулевом (пустое поле) keep-alive

а в чем проблема поставить хх секунд?

[SySOPik]

 

Если гасить VPN то уже и гасить весь интернет или весь роутер, экономить ресурс, ну а че?

Хотелка Имхо гемморойная будет, там подводных камней будет уйма, сомневаюсь из-за 1 человека кто-то будет городить костыли. 

1 час назад, ANDYBOND сказал:

 клиент WG перманентно держал сессию с сервером в активном состоянии при нулевом (пустое поле) keep-alive

Я думаю, что keep-alive собсно потому и есть, потому что протокол не умеет или не понимает данное условие.

Edited July 15, 2023 by SySOPik

[SySOPik]

Видимо разработчики протопитировали ситуацию и с 0 проверкой, вполне реально канал работал и зависал, так как нету проверки состояния канала. Посему решили кардинально выставив обязательный keep-alive. Она устаивает 99,99% пользователей, потому видимо так и будет. Как вариант выставить там 3600 секунд с двух сторон.

Edited July 15, 2023 by SySOPik

[Sovakot]

8 часов назад, ANDYBOND сказал:

Вот как! Не может клиент без keepalive, оказывается. Сервер - может.

если не ошибаюсь, то обоим пирам до лампочки какие-то keepalive, т.е. обменялись рукопожатиями, потом один отправляет другой принимает, в случае сбоя отправки, процедура рукопожатия повторяется. keepalive это костыль, с одной стороны это некий мониторинг состояния туннеля, т.к. см.пред. обоим пирам пофигу что там с другим, жив или нет, с другой стороны это имитация жизни подключения, если на оное влияют посторонние участники маршрутизации, там NAT провайдера, DDoS защита хостера, и т.п. ерунда

[nett]

On 7/16/2023 at 12:01 AM, Sovakot said:

если не ошибаюсь, то обоим пирам до лампочки какие-то keepalive, т.е. обменялись рукопожатиями, потом один отправляет другой принимает, в случае сбоя отправки, процедура рукопожатия повторяется. keepalive это костыль, с одной стороны это некий мониторинг состояния туннеля, т.к. см.пред. обоим пирам пофигу что там с другим, жив или нет

Вы не ошибаетесь, все так.
 

On 7/15/2023 at 11:49 AM, SySOPik said:

а в чем проблема поставить хх секунд?

Проблема написана в первом сообщении.

 

On 7/15/2023 at 12:50 PM, SySOPik said:

Если гасить VPN то уже и гасить весь интернет или весь роутер, экономить ресурс, ну а че?

Все правильно, и более того, кинетик поддерживает деградацию канала на LTE модеме, когда через него нет трафика. Когда трафик появится, кинетик переведет радио в другое состояние и заново установит быстрый канал с БС.

 

On 7/15/2023 at 1:03 PM, SySOPik said:

Она устаивает 99,99% пользователей

Вы хотите сказать, что у 99,99% пользователей мобильного интернета безлимитный тариф?

 

 

On 7/15/2023 at 1:03 PM, SySOPik said:

выставить там 3600 секунд

Допустим, выставил. Каждый час кинетик будет передавать 1 ненужный KeepAlive пакет + пару пакетов на хендшейки. Минимальная тарификация у оператора округляет в бОльшую сторону, не важно, 1кб или 128кб я передал. 128кб стоят $0,5 или 50 рублей в час, или 1200 рублей в сутки за передачу KeepAlive.

Вариант 2. Допустим, LTE трафик безлимитный в пакете на 5гб. Каждый KeepAlive interval из пакета будет сниматься минимально тарифицируемый объем трафика, округленный в бОльшую сторону.

 

Вариант 3. Допустим, я параноик, и я прочитал на википедии статью про DPI. Каким образом можно поднять каналы, но не светить их на DPI 24/7? Сетевое молчание - этому посвящена глава в Whitepaper

Почините пожалуйста, это баг.

qmxocynjca и vasek00 успешно повторили тест кейс и написали эту же проблему другими словами, спасибо им

Edited March 18 by nett

[Le ecureuil]

Я считаю, что постановка 3600 - отличное решение. Проверять канал хотя бы раз в час - нужно, иначе мы не можем считать его "даже в теории рабочим". Плюс почти у всех по этому каналу бегает куча служебной информации, хотя бы DNS - в таком случае рассчеты "а сколько же сожрет у меня KA для WG" считаю слегка неуместными.

Цитата

128кб стоят $0,5 или 50 рублей в час

Простите, а если вы реальный трафик пустите, и скажем, мегабайт 20-30 скачаете (в принципе дело десятка секунд на LTE), то без штанов-то не останетесь? Это ж 50 долларов вам будет стоить. В таком случае вам возможно вообще нужны другие подходы, и все распространенные протоколы частных сетей не устроят.