Перейти к содержанию

lighting

Участники форума
  • Постов

    100
  • Зарегистрирован

  • Посещение

Весь контент lighting

  1. Пользователь: vpn IPSec идентификатор: realme12 Стандартный клиент, который в настройках телефона. Если откат к 4.2.1, то всё нормально подключается. На 4.2.2 и 4.2.3 тоже норм.
  2. После обновления на 4.3а6 провайдер потребовал повторного логина (подключаюсь по IPoE) и выдал другой IP. После следующих перезагрузок на этой версии не потребовал. После отката на 4.2.1 заново потребовал авторизацию, после авторизации выдал IP до обновления на 4.3а6. Почему-то между этими версиями стал отличаться MAC-адрес на последний символ (на 4.3а6 последний символ на MAC-адресе стал c, на 4.2.1 - d).
  3. Проблема с подключением не исправлена. Высылаю self-test на 4.3а6.
  4. Когда-то наверно выпустят 4.2.x на delta, там будет версия повыше 4.2.1. Тут только ждать. Я бы сам был не против на Omni (KN-1410) сидеть на 4.2.3, вместо пока-что 4.3, которая на альфе с постоянными багами. Через несколько месяцев будет бета и последующие релизы. Пока-что альфа, очень нестабильный релизы. Беты уже будут с небольшим риском.
  5. @soft_warrior На ZK Ultra II всё правильно. Канал stable и preview поддержка закончилась, поэтому и 3.5. Теперь только поддержка от коммьюнити, если хочешь стейбл от коммьюнити, переходи на дельту или рискуй на драфте
  6. Провайдера КАБiNET уже нету больше 10 лет (вроде как с ноября 2013 всех перевели на Ростелеком, а с февраля 2017 бренд ликвидировали). Есть ли вообще смысл держать модуль "Авторизатор провайдера КАБіNET"? Вряд-ли уже этот модуль используют (тут на форуме особо даже про этот авторизатор не слышно). Предлагаю 2 варианта, либо удалить этот модуль, т. к. пользы в нём особой нет (провайдеры используют PPPoE, IPoE, PPTP и т. д.), либо переименовать его в альтернативное название, не связанное с давно мёртвым брендом (если модуль имеет какую-то ценность).
      • 5
      • Лайк
  7. Ну если HTTP/2 уже давно релизовали (хоть странно что не на всех роутерах это работает), то из идеи осталась только реализация HTTP/3.
  8. Так. По поводу омни, вне зависимости откуда стучимся (хоть с мобильного интернета на телефоне), KeenDNS идёт через HTTP/1.1. Если стучаться к пику (тоже вне зависимости откуда стучимся), то KeenDNS выдаёт HTTP/2. Если стучаться через локальные IP, то всегда будет HTTP/1.1 KeenDNS всюду работает через прямой доступ, внешние IP выдаёт корректные.
  9. Проверил на Keenetic Peak. С локалки идёт 1.1, с KeenDNS - 2. Но всё таки странно, почему на омни всюду 1.1. Баг или слабый роутер?
  10. На giga.demo HTTP/2 через Firefox, на омни HTTP/1.1.
  11. Ну у меня на Omni 4.2.1 так выходит
  12. тоже самое)) на KeenDNS на 1.1 лезет
  13. Ну не знаю, на 4.2.1 всё идёт через 1.1 😃
  14. Хотелось бы увидеть поддержку HTTP/2 и/или HTTP/3 на Web-интерфейсе. Сейчас если заходить на Web-интерфейс можно заметить, что версия протокола HTTP/1.1, а это не супер идеально со стороны скорости. Возможно ли Web-интерфейс перенести на HTTP/2, ибо это даст прирост производительности, т. к. во 2-ой версии добавили мультиплексирование запросов (да, там есть и другие нововведения, но как по мне это самое главное). Но если возможно добавить поддержку HTTP/3, то почему бы и нет? Web-интерфейс держится на nginx, там поддержка этой версии протокола "с коробки". Если добавят, то будет возможность сидеть через KeenDNS по UDP/443 через QUIC.
  15. Допустим мне нужен модуль ядра подсистемы Netfilter. Он привязан к модулю IPv6. Из-за чего это вообще связано? Например мне также не нужен вообще IPv6, а лишние модули держать на роутере ну не особо хочется.
  16. Всё сказанное ниже является лишь моей гипотезой. Рассказываю как понял. Предлагаю выслать селф-тест с Keenetic Omni (IKEv2-сервер) с корректным подключением к IKEv2 через Android и с неудачными попытками подключения с Keenetic Peak (4.2.2) на Omni (4.2.1) для сравнения, а также лог неудачного подключения с Keenetic Peak (IKEv2-клиент). Может чем-то поможет. Объяснение "на пальцах" вряд-ли поможет решить данный кейс. Также если возможно, можете сказать, смогли ли проверить репорт? Скорее всего чуть поторопился с выводами 😒. Хоть параметра Идентификатор IPSec нет, но он отправляется как IP клиента. Если конечно добавят поле "Идентификатор IPSec", то это всего-лишь увеличит функционал клиента (ну вместо идентификатора, например 78.47.125.180 можно будет указать свой, например KEENETIC-ROUTER). Если идентификатор IPSec для VPN на телефоне заменить на его внешний IP, то соединение пройдёт удачно, поэтому скорее всего поторопился. В настройках VPN-подключения IKEv2 MSCHAPv2 на Android требуют обязательно: 1) Имя соединения 2) Адрес сервера 3) Идентификатор IPSec (типа имя устройства, но в VPN-подключении) 4) Сертификаты. По поводу сертификатов, на KeenDNS выдаётся сертификат Let's Encrypt R10. В бинарнике сертификат ISRG Root X1, так что скорее всего проблема не в нём. На моём смартфоне указаны параметры для сертификатов "Не проверять сервер", "Принимать сертификат от сервера" (по умолчанию вписывается) 5) Логин и пароль В это время Keenetic требует обязательно всё кроме пункта 3 и 4. По поводу пункта 4, роутер лишь предлагает добавить сертификат (как я понял если используется типа самописного сертификата).
  17. Попозже смогу вернуться на 4.3а4, попробую словить баг, вышлю селф-тест в скрытом сообщении
  18. По умолчанию будет проставляться 78.47.125.180? Просто я не смог со смартфона подключиться к роутеру через IKEv2. Откат до 4.2.1 помог.
  19. Скорее всего понял в чём проблема. Для клиентов нужен "Индентификатор IPSec", а данного параметра нет.
  20. В Web-интерфейсе не сохраняются настройки DNS-сервера, в CLI команда crypto map VirtualIPServerIKE2 virtual-ip dns-server x.x.x.x не выполняется. Настройка dns-server в CLI внезапно пропала, а она является одной из обязательной частью IKE-серверов, поэтому к роутеру через IKE-протоколы становиться подключиться невозможно. P.S. На предыдущих версиях, если попытаться убрать DNS в IKE через Web-интерфейс, то кнопка "Сохранить" перестаёт быть активной, а если убрать через CLI, то IKE-сервер переходит в состояние "Не настроено", а обязательные пункты перекрашиваются в красный цвет. С 4.3а3 поле "DNS-сервер" стал почему-то опциональным (т.е. пустое поле позволяет сохранить)
  21. С 4.3а4 на 4.2.2 - не подключается, пишет неправильный пароль (хотя для того же пользователя на PPTP подключает) С 4.2.2 на 4.3а4 - не подключается.
  22. Внезапно стал гнать трафик к провайдеру 400-500 мбит, иногда 5 гбит, 18 гбит на 100-мегабитном Keenetic Omni. Периодически сильно нагружает роутер, иногда нагрузка процессора возрастает до 100%. Отключение модулей не помогает. Могу выслать self-test с Alpha 4.
  23. 1. На сайтах для проверки утечки DNS постоянно видны резолверы, исходящие от PPTP. Конкретнее, я подключаюсь к Keenetic Peak сейчас через PPTP. При тестировании на разных ресурсах (например, возьмём browserleaks.com/dns), то от VPN-подключения (хотя указано что не использовать для интернета) утекают DNS-запросы (роутер-клиент и роутер-сервер подключены к разным провайдерам, поэтому было понять откуда течёт очень легко). Вне зависимости от настроек сервера и клиента утечка DNS-запросов продолжается. 2. Мой топик по поводу невозможности подключения к IKEv2
  24. Добавлю про утечку. Могу точно сказать, что проявляется с 4.2 Beta 4 DNS течёт если есть VPN-подключение по PPTP (независимо от наличия шифрования, на других протколах не проверял, смогу проверить если решится проблема с IKEv2-клиентом, подключение только для доступа к локальной сети другого устройства)
×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.