Jump to content

nett

Forum Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by nett

  1. 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 успешно повторили тест кейс и написали эту же проблему другими словами, спасибо им

  2. я перечитал свои сообщения и я сделал 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.

  3. 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>

     

  4. 11 minutes ago, vasek00 said:

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

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

  5. 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

     

     

     

  6. 6 hours ago, vasek00 said:

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

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

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

  7. Документация 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...