dimon27254
-
Posts
555 -
Joined
-
Last visited
-
Days Won
18
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by dimon27254
-
-
1 минуту назад, SySOPik сказал:
Тогда в чем проблема? На кинетике сервере меняется IP, keendns обновляется, клиент переподключится автоматически. Ну да несколько минут не будет связи, но то вполне адекватно.
Потеря связи на несколько минут вообще не проблема.
В моем случае без привязки профиля ping-check клиент продолжает "стучаться" на старый адрес, пока Wireguard-интерфейс не будет перезапущен. После перезапуска системой выполняется повторный резолвинг домена и подключение идет по новому IP. Так работает на KeeneticOS 4.0 и ниже.
На KeeneticOS 4.1 система резолвит домен однократно, при первом запуске интерфейса или после изменения его настроек. Далее, сколько угодно раз можно выключать-включать интерфейс, IP-адрес конечной точки остается от первого резолвинга, повторно эта операция не выполняется. В итоге, клиент никогда не "достучится" до сервера, т.к. IP остается старый и не обновляется
-
1
-
-
8 минут назад, SySOPik сказал:
А создать keendns имя типа firma.keenetic.pro на сервере и прописать его в клиенте, вместо IP адреса не?
Именно так у меня и настроено:
1 час назад, dimon27254 сказал:Клиентом является KN-3010, на котором в качестве конечной точки указан домен сервера.
На сервере имеется домен вида *.keenetic.link, а на клиенте этот же домен прописан в конечной точке.
-
Поздравляю всех с наступающим Новым годом!
Мне потребовалось связать два Кинетика с помощью Wireguard-туннеля.
В роли сервера выступает KN-3610 с доменом KeenDNS и динамическим белым IP-адресом. Клиентом является KN-3010, на котором в качестве конечной точки указан домен сервера.На KN-3610 периодически меняется IP. Чтобы KN-3010 не терял связь в такой ситуации, создал профиль ping-check, в котором указан внутренний адрес сервера для постоянной проверки. Профиль назначен для Wireguard-интерфейса с параметром restart.
Когда сервер перестает отвечать на ping из-за смены внешнего IP, на клиенте автоматически перезапускается Wireguard-интерфейс. В таком случае происходит повторный резолвинг конечной точки, после чего соединение с сервером идет уже по новому IP-адресу.
На KeeneticOS 4.0 и более ранних версиях эта "схема" корректно отрабатывала. В 4.1 же обнаружил, что клиент после перезапуска интерфейса продолжает использовать "старый" IP-адрес конечной точки. Перезапуск интернет-соединения, ручной перезапуск интерфейса (в том числе, выключение на некоторое время и затем повторное включение) не исправляет ситуацию.
Туннель возможно вернуть "в строй", если изменить любую настройку в Wireguard-интерфейсе, или же полностью перезагрузить KN-3010.Теперь конечная точка туннеля будет резолвиться системой однократно за весь период работы, или это баг? Было бы неплохо, чтобы резолвинг выполнялся при каждом запуске Wireguard-интерфейса, как раньше.
При наличии статического IP на сервере, разумеется, не было бы и проблемы, но перейти на статику нет возможности.
Скрытым сообщением прикрепил self-test с клиента на 4.0.7 и 4.1 Beta 2.
-
1
-
-
На актуальной 4.1 Beta 2 все аналогично.
Предположил, что влиять на логику работы dns-proxy может исправление NDM-2990. Но там были правки для статических DNS-серверов, тогда как в моем случае получение идет через DHCP.
Если перезагрузить резервное подключение, то полученный DNS-сервер начинает использоваться. При назначении устройству политики доступа в интернет через это подключение - никаких проблем с DNS не наблюдается.
-
@hellonow @Le ecureuil в 4.1 Beta 2 отметки времени стали положительными, но значения продолжают быть нереалистичными:
wireguard: Wireguard1: retrying handshake with peer "*" (8) (*) because we stopped hearing back after 2166337568 seconds wireguard: Wireguard1: handshake for peer "*" (8) (*) did not complete after 2368404880 seconds, retrying (try 0)-
1
-
-
@eralde @Anna Zhelankina сейчас при переходе в веб-интерфейс ретранслятора из "Списка клиентов" требуется вручную проходить авторизацию, т.к. переход идет по IP-адресу.
Было бы удобно, чтобы прямо с этой страницы имелась возможность попасть на ретранслятор по доменному имени без необходимости ввода логина и пароля, как это реализовано на странице "Wi-Fi-система". Если же на ретрансляторе, например, нет SSL-сертификата, тогда переходить по IP без автоматической авторизации.
Это, конечно, мелочь, но в таком случае переход займет чуть меньше времени, т.к. не потребуется открывать отдельно страницу "Wi-Fi-система" и там кликать по нужному Кинетику или же вручную авторизовываться на нем при переходе из "Списка устройств".
-
2
-
1
-
-
В 30.09.2023 в 20:37, dimon27254 сказал:
в 4.1 Alpha 10 увидел упоминание об исправлении плавного нарастания графиков скорости.
Но, к сожалению, подтвердить не могу. Все также удается иногда словить ситуации, когда происходит то же самое.
Более того, теперь появился новый баг: почему-то сразу после подключения отображаются данные не за 3 минуты, а с момента запуска кинетика и по настоящее время:
@eralde по этому поводу были правки?
В changelog не увидел упоминаний, но на последних версиях перестало воспроизводиться.
-
Стоит отметить, что новый веб-интерфейс доступен только на прошивках draft-ветки (канал разработчика):
В 19.12.2023 в 17:18, eralde сказал:Насколько я понимаю, компонент с новым веб-интерфейсом пока будет доступен только в драфтах.
В preview (предварительном) он отсутствует, только что проверил у себя на KN-3610.
-
2
-
-
В 03.12.2023 в 22:36, dimon27254 сказал:
В текущем же все-таки залипло активированное.
@eralde спасибо! В 4.1 Beta 2 состояние чекбокса отображается корректно.
-
6 часов назад, lterr сказал:
Служба отключена, но порт по прежнему открыт? Или служба отключится только после перезагрузки?
Служба отключается сразу же после ввода команды, но порты, которые были открыты еще во время её работы - остаются. Перезагрузите Кинетик и все записи удалятся.
-
@eralde для пользовательских статических маршрутов, которые настроены на любой интерфейс, потерялась подпись "любой":
Скрытый текст
Параметры одного из таких маршрутов:
Скрытый текст
В текущем веб-интерфейсе отображение корректное:
Скрытый текст
-
1
-
-
По каким-то причинам у вас нет доступа к серверу обновлений, из-за чего и недоступно удаление службы UPnP.
Без полного удаления её можно выключить с помощью пары команд в CLI:
no service upnp system configuration save-
1
-
-
@eralde в продолжение темы о предупреждающих диалогах:
Нашел аналогичный недочет и в диалоге подтверждения извлечения USB-устройства:
Скрытый текст
-
1
-
-
@eralde в диалоге подтверждения выключения Wi-Fi сети, через которую подключено устройство, управляющее Кинетиком, затерялось описание:
Скрытый текст
Если эту же сеть попытаться выключить из карточки в dashboard, оно выводится корректно:
Скрытый текст
Проверял на 4.1 Beta 1.
-
1
-
-
@hellonow @Padavan возникла необходимость на KN-3610 отключить 256-QAM для диапазона 2.4 ГГц из-за проблем со стабильностью подключения некоторых старых устройств.
В новом веб-интерфейсе произвел отключение. Убедился, что 256-QAM не работает - канальные скорости клиентов снизились до "стандартных" значений, а из startup-config и running-config для WifiMaster0 удалился параметр vht.
Перезагружаю Кинетик, и вижу, что 256-QAM снова включился - стал активным флажок в вебе, канальные скорости подросли. В running-config появился vht, тогда как в startup-config его нет. Получается, его автоматически включила система.
В чем возможна причина такого поведения? Стандарт сети для 2.4 ГГц выставлен 802.11b/g/n, для 5 ГГц 802.11a/n/ac/ax.
Использую KeeneticOS 4.1 Beta 1.
Скрытым сообщением прикрепил self-test до и после перезагрузки.
-
@eralde нашел парочку небольших багов в поп-апе добавления/изменения правила.
1. Выбираю протокол TCP/UDP, вариант номера порта назначения указал как "равен"/ "меньше..."/ "больше..."/ "диапазон":
Скрытый текст
Далее, не вводя номер(а) портов, выбираю другой протокол, в котором не требуется ввод номера порта или же он "зашит". Кнопка сохранения изменений остается неактивна:
Скрытый текст
2. Иногда вместо стилизованного выпадающего списка с протоколами отображается стандартный браузерный:
Скрытый текст
-
1
-
-
В настоящее время не сохраняется выбор версии интерфейса, всегда открывается новый.
Можно обращаться к Кинетику по ссылке вида:
http://ip_адрес_или_доменное_имя/index2.html
Например:
http://192.168.1.1/index2.html
https://mykeenetic.keenetic.pro/index2.htmlВ таком случае будет сразу открываться старый веб-интерфейс и им можно будет полноценно пользоваться до следующего входа. Затем снова придется переходить по приведенной выше ссылке.
-
1
-
1
-
-
@eralde @Anna Zhelankina в мобильной версии диалог подтверждения выглядит не совсем красиво:
Скрытый текст
Хотелось бы, чтобы текст предупреждения полностью отображался без необходимости его раскрытия.
-
2
-
1
-
-
Без изменений в 4.1 Beta 0.1.
-
1
-
-
@eralde после нескольких повторных переключений чекбокса, в новом вебе состояние нормализовалось. В текущем же все-таки залипло активированное.
-
1
-
-
Возникла необходимость на KN-3610 выключить 256-QAM в 2.4 ГГц.
Перешел на страницу "Мои сети и Wi-Fi", открыл поп-ап настроек Wi-Fi 2.4 ГГц. Деактивировал чекбокс и сохранил настройки. Повторно захожу в поп-ап и вижу, что чекбокс также остался активным, хотя из конфигурации для интерфейса WifiMaster0 удалился параметр vht.
Проявляется как в новом, так и в текущем веб-интерфейсе. Проверял на версии 4.1 Beta 0.
-
1
-
-
В 4.1 Beta 0 обратил внимание, что dns-proxy Кинетика не использует DNS-серверы резервного подключения, пока оно не является основным по приоритету.
С одной стороны, DNS-запросы не "утекают" на резервный интерфейс. С другой, если возникает необходимость "завернуть" одно из устройств на резервное подключение с помощью политики доступа, то оно не может разрешить ни один из доменов, т.к. "резервный" DNS игнорируется Кинетиком.
Были ли какие-то изменения на этот счет в логике работы dns-proxy на последних сборках 4.1?
При откате на стабильную 4.0.7 с имеющейся конфигурацией, проблема перестает воспроизводиться - начинают использоваться одновременно DNS-серверы как основного, так и резервного подключения. Устройство, "завернутое" политикой в резервное, не испытывает проблем с DNS.
-
1
-
1
-
-
@eralde @Anna Zhelankina при использовании выпадающих меню имеют место быть ситуации, когда визуально сложно различить, где еще меню, а где уже элемент на самой странице. Например, настройка кнопок и светодиодов на странице "Параметры системы", где в одном блоке несколько таких меню.
В светлой теме, в целом, ситуацию спасает небольшое затенение вокруг:
Скрытый текст
В темной теме это затенение менее заметно, особенно при невысокой яркости экрана:
Скрытый текст
Предлагаю немного изменить цвет фона в выпадающих меню, чтобы они не сливалось с фоном страницы. Или же, как вариант, сделать более заметным их выделение.
По большей части это относится к мобильному вебу, где ширина выпадающего меню всегда фиксирована, в отличие от десктопного.
-
1
-
1
-
-
В 25.08.2023 в 00:01, dimon27254 сказал:
В пунктах меню, содержимое которых не умещается в одну строку, имеется абзацный отступ. Он довольно мал, но все же заметно, что первая строка расположена чуть правее второй.
В 17.09.2023 в 17:07, dimon27254 сказал:Было бы неплохо, если есть возможность сделать как в 3.х вебе.
В новом опрос с учетом таймаута соединения идет с периодом около 14 секунд, а в текущем 7-8.@eralde в 4.1 Beta 0 подправлено. Спасибо!
В 25.08.2023 в 00:01, dimon27254 сказал:Образовался лишний интервал после подписи обработчика нажатия кнопки "выключатель светодиодов"
После этой подписи лишний интервал пропал, но я его нашел в парочке других мест:
Скрытый текст
-
1
-
4.1: резолвинг конечных точек в Wireguard
in Тестирование Dev-сборок
Posted · Edited by dimon27254
У вас трафик в туннеле идет непрерывно, т.е. имеется постоянная активность? Клиент имеет белый или серый адрес?
У меня активность туннеля большую часть времени поддерживается лишь с помощью keepalive-пакетов, которые клиент посылает серверу.
К работе KeenDNS вопросов нет - он корректно отрабатывает смену IP, т.к. уже через пару минут веб-интерфейс сервера становится снова доступен из интернета, а nslookup для домена показывает новый IP. Причем, эту проверку я провожу на устройстве, находящемся в локальной сети KN-3010. То есть, встроенный dns-proxy этого Кинетика уже знает новый IP и отдает его клиентам.
В 4.1 при первом запуске Wireguard или изменении его настроек, происходит резолвинг и определение IP-адреса конечной точки:
ndm: Wireguard::Interface: "Wireguard2": resolved peer "*" endpoint to "ip_сервера". ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": remote endpoint is "ip_сервера". ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": connecting via "PPPoE0" (PPPoE0). ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": local endpoint is "внешний_ip_клиента".При перезапуске Wireguard не появляется запись вида "resolved peer", продолжается использование ранее полученного IP без повторного резолвинга:
kernel: wireguard: Wireguard2: peer "*" (15) (старый_ip_сервера:порт) destroyed ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": remote endpoint is "старый_ip_сервера". ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": connecting via "PPPoE0" (PPPoE0). ndm: Network::Interface::EndpointTracker: "Wireguard2": "*": local endpoint is "внешний_ip_клиента". kernel: wireguard: Wireguard2: peer "*" (16) created kernel: wireguard: Wireguard2: handshake for peer "*" (16) (старый_ip_сервера:порт) did not complete after 2164841720 seconds, retrying (try 5)Далее лог забивается записями о неудачных попытках завершения хэндшейка.
В 4.0 и более ранних резолвинг происходит при каждом запуске Wireguard:
kernel: wireguard: Wireguard2: peer "*" (11) (старый_ip_сервера:порт) destroyed kernel: wireguard: Wireguard2: peer "*" (12) created ndm: Wireguard::Interface: "Wireguard2": added a host route to peer "*" (новый_ip_сервера) via PPPoE0 (PPPoE0). ndm: Wireguard::Interface: "Wireguard2": peer "*" went offline, update configuration. kernel: wireguard: Wireguard2: handshake for peer "*" (12) (новый_ip_сервера:порт) did not complete after 5 seconds, retrying (try 2)Затем туннель поднимается и все работает корректно.