corniger

Спасибо. Поправлено, войдёт в очередной выпуск.

Перехват трафика должен включаться если задействован один из (любой) режимов фильтрации. Транзит запросов нужен только в случае включенного перехвата трафика, для того чтобы разрешать имена в адреса через явно указанные на устройствах сервисы. Система "никуда ничего не посылает", только запрос и только туда куда указано по указанным настройкам. Складируется только в локальный кеш (это нормальное поведение любого резолвера, вести кеш). Пожалуйста, если вы идите другое поведение, опишите как воспроизвести. Здесь или в обращении в Техническую поддержку.

Буква "и" не была использована чтобы избежать ..ее и И.. Вся настройка так и осталась называться Ограничение скорости, данное поле ввода принимает значение для обоих направлений одинаковое, если включить ниже Асимметрично то поле разделяется на два, по направлениям

Настройка "Без IP адреса" для сегментов устройства в режиме extender запланирована в 3.8.

Спасибо. Вам, если рассматривать использование Wi-Fi-системы, не поможет решение вопроса "просто разрешите сохранение настроек сегмента без IP-адреса", так как в случае ваших требований, если даже и будет такая возможность, это будет, как, знаете, маска с огурцами. Действует пока нанесено. Как только контроллер проведет следующее построение, например при перезапуске, настройка interface ip no address с ретрансляторов будет убрана - заменена на ip address dhcp. Другая настройка не поддерживается для неосновного сегмента в Wi-Fi-системе, и планов на реализацию этого пока совсем нет. Я не понял причем тут настройки arp у вас на шлюзе). Если не рассматривать управляемые с контроллера точки доступа, тогда да, во имя чего-то настройка без IP-адреса имеет место быть на сегменте. Есть мнение что стоит предусмотреть такой сценарий в веб-интерфейсе, хотя бы для избежания отказа при работе. А скажите, сценария когда вы устройство переводите в неуправляемый Wi-Fi-коммутатор без возможности зайти на него по сети, такого нету ведь у вас? Хотя бы один сегмент остается с настройкой IP?

Кажется, понял о чем вы. Имеется в виду, что в дополнительных сегментах (кроме основного, который вы оставляете как VLAN управления) требуется на всех узлах Wi-Fi системы, включая контроллер, отсутствие IP-адресов? FT-роуминг при этом не будет работать, но вам это и не нужно, так? А требование такое, потому что а) доступ пользователей к веб-интерфейсам точек доступа и контроллера неприемлем б) использование DHCP-клиентов неприемлемо в) статические адреса (они и не поддерживаются на точках досутпа в дополнительных сегментах) также неприемлемы

Доступ к управлению можно закрыть при помощи сетевого экрана, устранять адрес интерфейса для этого не обязательно. Я видимо неверно понимаю вашу схему, мне так начинает казаться по прочтении этого несмотря на то, что вы не отреагировали на мой вопрос о примере настройки интерфейса сегмента. Или, если это не относится к сегменту, то тогда кто - он? Пожалуйста, уточните, как у вас планируется, как должен быть настроен сегмент? Вы включаете в сегменте несколько VLAN-интерфейсов, с разными внешними DHCP-серверами?

Пожалуйста уточните, чем мешает адрес интерфейса сегмента, кроме очевидного - занятый IP? Верно понимаю, что вы говорите о сегменте к примеру с такой конфигурацией? interface Bridge2 description "Segment 3" include GigabitEthernet0/Vlan15 include WifiMaster0/AccessPoint2 include WifiMaster1/AccessPoint2 mac access-list type none security-level protected ip dhcp client dns-routes ip dhcp client name-servers iapp key ns3 6i1ln01HEPOQDCOyDeDwY/FL up Без адреса на сегменте, если не ошибаюсь, не будет работать 802.11r - FT-роуминг. Если можно расскажите подробнее также о других недоработках. В реализации на данный момент, действительно, контроллер Wi-Fi-системы это обязательно устройство в основном режиме работы, но все сегменты кроме Home вы можете настроить на использование внешнего DHCP и шлюза.

Пожалуйста уточните по возможности, для какой цели требуется решить такую задачу. На данный момент реализация не позволяет настроить сетевой мост как вы описали. Мосты в системе могут содержать только Ethernet-интерфейсы, каковым интерфейс QMI-модема не является. Если говорить о франкенштейне, то тоже нет, DHCP Relay тут не поможет, так как этот протокол вовсе не используется на стороне провайдера.

1 и 2, работы в этом направлении запланированы, обращение в техподдержку если нет специальной необходимости можно не оформлять в названии топика есть слово "ребут", и также вы пишете в сообщениях о ребуте всех клиентов - пожалуйста, уточните, это перезагрузка имеется в виду? или ребут в данном случае надо понимать как переподключение к сети

насколько я могу понять, это не проблема связанная с изменениями в этом выпуске данное предложение можно внести в соотв. раздел (о предложениях) настройка о которой идет речь, продвинутого уровня. не всегда в настройках продвинутого уровня удается элегантно заложить защиту от дурака. в данном случае можно рассмотреть как вариант отслеживать действие пользователя по удалению установленных пользовательских DNS-серверов вместе с наличием интерфейсов у которых запрещено использование провайдерских DNS. с такими условиями вы бы увидели сообщение на моменте удаления. речь об этом? либо можно в Системном мониторе сообщать о проблемах более развернуто, то есть добавить валидацию наличия ключевых параметров подключения. второй вариант представляется более логичным, а первый - более костыльным

не так будили видимо. грамотно заданный вопрос..

как пользоваться Allowed IPs разъяснено для примера, в целом повторяющего вашу схему, в статье на русском языке https://help.keenetic.com/hc/ru/articles/360012075879 посмотрите ее пожалуйста может быть, у вас есть предложения, как ее улучшить? Wireguard концептуально может казаться несколько громоздким, думаю, с этим связано отчасти двусмысленное название вашего топика - "Подключение одного пира к другому через Keenetic WireGuard" - выглядит так, будто вы внутри туннеля еще один устанавливаете)

с точки зрения функционала, управление от уровня сигнала клиента еще пока не реализовано. тем не менее, мало что конкретного можно определить из вышеизложенных данных. что если клиент хватается за первый попавшийся маяк в эфире? что если он запоминает себе по-тихому BSSID, и других и не ищет? если у вас есть возможность поделиться захватом радиоэфира MESH-системы, например, моментов когда запускается клиент и подключается не к близкорасположенной ТД, а удаленной, с низким уровнем сигнала ТД - анализ подобной информации может помочь. вы можете прислать такие данные в ТП, чтобы здесь не прятать в сообщения.

рекомендовал бы обратиться в поддержку если проблема продолжается, пришлите вместе с обращением файл диагностики (self-test.txt) сохранив его непосредственно в период когда проявляется описанное поведение

это не совсем так, не в любой момент, а есть определенные обстоятельства. примерно это выглядит следующим образом, драйвер ntfs ставит такую метку на том при монтировании, а при отмонтировании снимает. если метка уже присутствует при попытке смонтировать, драйвер пишет про dirty filesystem. эту метку можно убрать и не отключая диск https://help.keenetic.com/hc/ru/search?utf8=✓&query=dirty&commit=Поиск

Замечу, вы упомянули интерфейс L2TP, похоже что сервер находится удаленно и именно Keenetic устанавливает к нему подключение, а не наоборот? Когда включено автоматическое правило трансляции для определенного сегмента (стоит галка NAT в Домашней сети), трафик из этой сети поступает во внешние сети с адресом интерфейса устройства в этой внешней сети. На входящий трафик непосредственное влияние этой настройки отсутствует. Однако, если говорить о трафике ответном, то разница разумеется будет, поскольку адрес отправителя разный. При включенном NAT это адрес интерфейса, который установлен у вас по L2TP, при выключенном - это адрес хоста, отправляющего запрос, так как подмены не будет происходить. Пожалуйста, посмотрите статью.

Прочтите пожалуйста статью. Насколько я могу понять, локальная сеть вашего huawei это по статье "сеть предприятия". Данный сценарий не назвать распространенным, и, к тому же, по сути это брешь в безопасности - выход в интернет через сегмент с локальными устройствами. Да, конечно есть и существующий шлюз, но все же. Поэтому мы как о рекомендованной, о такой схеме стараемся не говорить.

Управление по данному протоколу по умолчанию включено в локальном сегменте, в котором не запрещен доступ к сервисам на устройстве (таком как например предустановленный сегмент Домашняя сеть). Из внешних сетей доступ к управлению при помощи любых протоколов по умолчанию закрыт. Можно выполнить команды no service telnet и system configuration save , что приведет сначала к отключению службы и затем к сохранению конфигурации. Как перейти ко вводу команд через веб-конфигуратор посмотреть можно здесь, последний раздел. Установите компонент SSH чтобы подключаться к командной строке в безопасном режиме, если это необходимо в вашей локальной сети. После установки, в локальной сети с уровнем безопасности private сервер SSH отвечает по умолчанию.

(По всей вероятности такой вопрос можно задавать в поддержку, сразу.) Какие параметры используются в конфигурации OpenVPN-соединения? Это подключение к серверу, организованному на рабочем месте, в его настройки у вас нету доступа? Вы не пишете, но возможно - проверяли, если этот модем непосредственно на компьютере установить, том, с которого выполняется подключение к OpenVPN-серверу, и запустить туннель, ошибок в журнале подключения не будет образовываться? Сравните пожалуйста показания статистики в веб-интерфейсе модема при подключении его в роутер и в компьютер.

Эта функция есть в приложении для мобильных устройств, которое "всегда онлайн". Реализация ее же в системе устройства предполагает решение вопросов по работе в режиме оффлайн, что связано с определенными моментами. База зарегистрированных вендорами MAC-адресов имеет некий, заметный, размер, и время от времени обновляется. "Просто добавить" такую функцию не представляется элементарным действием. Если для вас наличие данного функционала в приложении не является достаточным, напишите пожалуйста в каком сценарии он требуется в веб-конфигураторе.

First and basic reason is the hardware platform is different. It is common in modern hardware to automate low-level routines via intelligent driver algorithms. That is why, also, it would be desirable to have a look at the operator recommendations of such manual tweking. Or any other kind of info that would indicate that the connection made in automatic mode is not optimal.

I guessed so. Thank you. Would also like to know, if the operator would respond when you inquire the values for the settings mentioned, or do you have to tune them in an experimental manner? Do you (or maybe the person whose modem is on the screeen-shot) have exact values that should be entered, for the specific line? I mean, vectoring and impulse protection assistance are somewhat automated tech, there must be a reson to disable those on a cpe side. Is there an ISP reccomendation to do that, and what kind of problems are you experiencing.

Hi, and welcome to forum! Please let me query, what is the make and FW version of the device you got on that screen shot?