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) Затем туннель поднимается и все работает корректно.

Потеря связи на несколько минут вообще не проблема. В моем случае без привязки профиля ping-check клиент продолжает "стучаться" на старый адрес, пока Wireguard-интерфейс не будет перезапущен. После перезапуска системой выполняется повторный резолвинг домена и подключение идет по новому IP. Так работает на KeeneticOS 4.0 и ниже. На KeeneticOS 4.1 система резолвит домен однократно, при первом запуске интерфейса или после изменения его настроек. Далее, сколько угодно раз можно выключать-включать интерфейс, IP-адрес конечной точки остается от первого резолвинга, повторно эта операция не выполняется. В итоге, клиент никогда не "достучится" до сервера, т.к. IP остается старый и не обновляется

Именно так у меня и настроено: На сервере имеется домен вида *.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.

На актуальной 4.1 Beta 2 все аналогично. Предположил, что влиять на логику работы dns-proxy может исправление NDM-2990. Но там были правки для статических DNS-серверов, тогда как в моем случае получение идет через DHCP. Если перезагрузить резервное подключение, то полученный DNS-сервер начинает использоваться. При назначении устройству политики доступа в интернет через это подключение - никаких проблем с DNS не наблюдается. @hellonow @sergeyk

@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)

@eralde @Anna Zhelankina сейчас при переходе в веб-интерфейс ретранслятора из "Списка клиентов" требуется вручную проходить авторизацию, т.к. переход идет по IP-адресу. Было бы удобно, чтобы прямо с этой страницы имелась возможность попасть на ретранслятор по доменному имени без необходимости ввода логина и пароля, как это реализовано на странице "Wi-Fi-система". Если же на ретрансляторе, например, нет SSL-сертификата, тогда переходить по IP без автоматической авторизации. Это, конечно, мелочь, но в таком случае переход займет чуть меньше времени, т.к. не потребуется открывать отдельно страницу "Wi-Fi-система" и там кликать по нужному Кинетику или же вручную авторизовываться на нем при переходе из "Списка устройств".

@eralde по этому поводу были правки? В changelog не увидел упоминаний, но на последних версиях перестало воспроизводиться.

Стоит отметить, что новый веб-интерфейс доступен только на прошивках draft-ветки (канал разработчика): В preview (предварительном) он отсутствует, только что проверил у себя на KN-3610.

@eralde спасибо! В 4.1 Beta 2 состояние чекбокса отображается корректно.

Служба отключается сразу же после ввода команды, но порты, которые были открыты еще во время её работы - остаются. Перезагрузите Кинетик и все записи удалятся.

@eralde для пользовательских статических маршрутов, которые настроены на любой интерфейс, потерялась подпись "любой": Параметры одного из таких маршрутов: В текущем веб-интерфейсе отображение корректное:

По каким-то причинам у вас нет доступа к серверу обновлений, из-за чего и недоступно удаление службы UPnP. Без полного удаления её можно выключить с помощью пары команд в CLI: no service upnp system configuration save

@eralde в продолжение темы о предупреждающих диалогах: Нашел аналогичный недочет и в диалоге подтверждения извлечения USB-устройства:

@eralde в диалоге подтверждения выключения Wi-Fi сети, через которую подключено устройство, управляющее Кинетиком, затерялось описание: Если эту же сеть попытаться выключить из карточки в dashboard, оно выводится корректно: Проверял на 4.1 Beta 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. Иногда вместо стилизованного выпадающего списка с протоколами отображается стандартный браузерный:

В настоящее время не сохраняется выбор версии интерфейса, всегда открывается новый. Можно обращаться к Кинетику по ссылке вида: http://ip_адрес_или_доменное_имя/index2.html Например: http://192.168.1.1/index2.html https://mykeenetic.keenetic.pro/index2.html В таком случае будет сразу открываться старый веб-интерфейс и им можно будет полноценно пользоваться до следующего входа. Затем снова придется переходить по приведенной выше ссылке.

@eralde @Anna Zhelankina в мобильной версии диалог подтверждения выглядит не совсем красиво: Хотелось бы, чтобы текст предупреждения полностью отображался без необходимости его раскрытия.

Без изменений в 4.1 Beta 0.1.

@eralde после нескольких повторных переключений чекбокса, в новом вебе состояние нормализовалось. В текущем же все-таки залипло активированное.

@eralde Возникла необходимость на KN-3610 выключить 256-QAM в 2.4 ГГц. Перешел на страницу "Мои сети и Wi-Fi", открыл поп-ап настроек Wi-Fi 2.4 ГГц. Деактивировал чекбокс и сохранил настройки. Повторно захожу в поп-ап и вижу, что чекбокс также остался активным, хотя из конфигурации для интерфейса WifiMaster0 удалился параметр vht. Проявляется как в новом, так и в текущем веб-интерфейсе. Проверял на версии 4.1 Beta 0.

В 4.1 Beta 0 обратил внимание, что dns-proxy Кинетика не использует DNS-серверы резервного подключения, пока оно не является основным по приоритету. С одной стороны, DNS-запросы не "утекают" на резервный интерфейс. С другой, если возникает необходимость "завернуть" одно из устройств на резервное подключение с помощью политики доступа, то оно не может разрешить ни один из доменов, т.к. "резервный" DNS игнорируется Кинетиком. Были ли какие-то изменения на этот счет в логике работы dns-proxy на последних сборках 4.1? При откате на стабильную 4.0.7 с имеющейся конфигурацией, проблема перестает воспроизводиться - начинают использоваться одновременно DNS-серверы как основного, так и резервного подключения. Устройство, "завернутое" политикой в резервное, не испытывает проблем с DNS.

@eralde @Anna Zhelankina при использовании выпадающих меню имеют место быть ситуации, когда визуально сложно различить, где еще меню, а где уже элемент на самой странице. Например, настройка кнопок и светодиодов на странице "Параметры системы", где в одном блоке несколько таких меню. В светлой теме, в целом, ситуацию спасает небольшое затенение вокруг: В темной теме это затенение менее заметно, особенно при невысокой яркости экрана: Предлагаю немного изменить цвет фона в выпадающих меню, чтобы они не сливалось с фоном страницы. Или же, как вариант, сделать более заметным их выделение. По большей части это относится к мобильному вебу, где ширина выпадающего меню всегда фиксирована, в отличие от десктопного.

@eralde в 4.1 Beta 0 подправлено. Спасибо! После этой подписи лишний интервал пропал, но я его нашел в парочке других мест: