
lighting
Участники форума-
Постов
100 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент lighting
-
После обновления на 4.3а6 провайдер потребовал повторного логина (подключаюсь по IPoE) и выдал другой IP. После следующих перезагрузок на этой версии не потребовал. После отката на 4.2.1 заново потребовал авторизацию, после авторизации выдал IP до обновления на 4.3а6. Почему-то между этими версиями стал отличаться MAC-адрес на последний символ (на 4.3а6 последний символ на MAC-адресе стал c, на 4.2.1 - d).
-
Когда-то наверно выпустят 4.2.x на delta, там будет версия повыше 4.2.1. Тут только ждать. Я бы сам был не против на Omni (KN-1410) сидеть на 4.2.3, вместо пока-что 4.3, которая на альфе с постоянными багами. Через несколько месяцев будет бета и последующие релизы. Пока-что альфа, очень нестабильный релизы. Беты уже будут с небольшим риском.
-
Провайдера КАБiNET уже нету больше 10 лет (вроде как с ноября 2013 всех перевели на Ростелеком, а с февраля 2017 бренд ликвидировали). Есть ли вообще смысл держать модуль "Авторизатор провайдера КАБіNET"? Вряд-ли уже этот модуль используют (тут на форуме особо даже про этот авторизатор не слышно). Предлагаю 2 варианта, либо удалить этот модуль, т. к. пользы в нём особой нет (провайдеры используют PPPoE, IPoE, PPTP и т. д.), либо переименовать его в альтернативное название, не связанное с давно мёртвым брендом (если модуль имеет какую-то ценность).
-
- 5
-
-
Так. По поводу омни, вне зависимости откуда стучимся (хоть с мобильного интернета на телефоне), KeenDNS идёт через HTTP/1.1. Если стучаться к пику (тоже вне зависимости откуда стучимся), то KeenDNS выдаёт HTTP/2. Если стучаться через локальные IP, то всегда будет HTTP/1.1 KeenDNS всюду работает через прямой доступ, внешние IP выдаёт корректные.
-
Хотелось бы увидеть поддержку HTTP/2 и/или HTTP/3 на Web-интерфейсе. Сейчас если заходить на Web-интерфейс можно заметить, что версия протокола HTTP/1.1, а это не супер идеально со стороны скорости. Возможно ли Web-интерфейс перенести на HTTP/2, ибо это даст прирост производительности, т. к. во 2-ой версии добавили мультиплексирование запросов (да, там есть и другие нововведения, но как по мне это самое главное). Но если возможно добавить поддержку HTTP/3, то почему бы и нет? Web-интерфейс держится на nginx, там поддержка этой версии протокола "с коробки". Если добавят, то будет возможность сидеть через KeenDNS по UDP/443 через QUIC.
-
Всё сказанное ниже является лишь моей гипотезой. Рассказываю как понял. Предлагаю выслать селф-тест с 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, роутер лишь предлагает добавить сертификат (как я понял если используется типа самописного сертификата).
-
4.3a3-a4. Не сохраняются настройки DNS в IKE-серверах
lighting опубликовал вопрос в Тестирование Dev-сборок
В 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-сервер" стал почему-то опциональным (т.е. пустое поле позволяет сохранить) -
1. На сайтах для проверки утечки DNS постоянно видны резолверы, исходящие от PPTP. Конкретнее, я подключаюсь к Keenetic Peak сейчас через PPTP. При тестировании на разных ресурсах (например, возьмём browserleaks.com/dns), то от VPN-подключения (хотя указано что не использовать для интернета) утекают DNS-запросы (роутер-клиент и роутер-сервер подключены к разным провайдерам, поэтому было понять откуда течёт очень легко). Вне зависимости от настроек сервера и клиента утечка DNS-запросов продолжается. 2. Мой топик по поводу невозможности подключения к IKEv2
-
Добавлю про утечку. Могу точно сказать, что проявляется с 4.2 Beta 4 DNS течёт если есть VPN-подключение по PPTP (независимо от наличия шифрования, на других протколах не проверял, смогу проверить если решится проблема с IKEv2-клиентом, подключение только для доступа к локальной сети другого устройства)