Jump to content

nett

Forum Members
  • Posts

    9
  • Joined

  • Last visited

Equipment

  • Keenetic
    KN-2310, KN-1010, Ultra2

nett's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Вы не ошибаетесь, все так. Проблема написана в первом сообщении. Все правильно, и более того, кинетик поддерживает деградацию канала на LTE модеме, когда через него нет трафика. Когда трафик появится, кинетик переведет радио в другое состояние и заново установит быстрый канал с БС. Вы хотите сказать, что у 99,99% пользователей мобильного интернета безлимитный тариф? Допустим, выставил. Каждый час кинетик будет передавать 1 ненужный KeepAlive пакет + пару пакетов на хендшейки. Минимальная тарификация у оператора округляет в бОльшую сторону, не важно, 1кб или 128кб я передал. 128кб стоят $0,5 или 50 рублей в час, или 1200 рублей в сутки за передачу KeepAlive. Вариант 2. Допустим, LTE трафик безлимитный в пакете на 5гб. Каждый KeepAlive interval из пакета будет сниматься минимально тарифицируемый объем трафика, округленный в бОльшую сторону. Вариант 3. Допустим, я параноик, и я прочитал на википедии статью про DPI. Каким образом можно поднять каналы, но не светить их на DPI 24/7? Сетевое молчание - этому посвящена глава в Whitepaper Почините пожалуйста, это баг. qmxocynjca и vasek00 успешно повторили тест кейс и написали эту же проблему другими словами, спасибо им
  2. Мне нужно, чтобы починили тест-кейс из первого сообщения
  3. Up! Подскажите пожалуйста, этот баг можно зарепортить в разработку?
  4. я перечитал свои сообщения и я сделал 2 минорных ошибки, сейчас исправлюсь r13 прав, конечно же у меня есть 2 NAT'a на Кинетике и на ОПСОСе в описанном примере. я думал про белый IP у сервера когда писал. Keepalive вредит т.к если на ОПСОСе платный трафик, то каждый keepalive пакет будет тарифицироваться по минимальному объему трафика (128кб вроде у МФ), а также он будет переводить антенны кинетика и БС в high power state, занимать радиоканал и впустую тратить ресурсы БС, в случае если таймаут станции(кинетика или телефона) на БС меньше, чем keepalive на тоннеле Wireguard. В догонку к предыдущему сообщению: подробности в главе 2.1 Endpoints & Roaming https://www.wireguard.com/papers/wireguard.pdf тут тоже ошибка, я начитался про Кинетик, в котором выключение происходит через удаление значения Persistent keepalive из веб интерфейса. В офф клиенте Wireguard можно не указывать ключ PersistentKeepalive в конфиге, в этом случае моя сборка (последняя офф) дефолтится на 10 минут. Для того, чтобы выключить keepalive полностью нужно указать 0.
  5. Это не так, я дал ссылку на главу 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>
  6. Все верно, хендшейк должен произойти в первых пакетах когда "клиент" отправит данные "серверу", например - пинг.
  7. 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
  8. Если взять офф клиент wireguard и Кинетик, на обоих сторонах выключить Persistent keepalive, то все работает. Если взять два офф клиента, то тоже работает. Подробности по ссылке из моего поста - там рассказывается, почему это должно работать и почему это правильно. Пример с хабра некорректный т.к автор пишет, что ему keepalive нужен для того, чтобы держать соединения открытыми в фаерволлах и натах. У меня нет натов и фаерволлов, по-этому потребности в keepalive нет, и наоборот - keepalive вредит в описанном мной примере.
  9. Документация 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
×
×
  • Create New...