dimon27254

Интересное наблюдение: Телефон подключается к Wi-Fi с одним MAC-адресом, но DHCP-запросы шлёт с другого ("основного", который виден в самом телефоне). При этом, NDMS "запоминает" только основной MAC, от которого шли DHCP. Первый же нигде в self-test не фигурирует, кроме лога. Если вручную зарегистрировать новое устройство с первым MAC, и привязать к 2.4, то привязка сработает. При включенном MLO уже оказывается 3 MAC. Один также основной, с которого идёт DHCP, и по одному для 2.4 и 5 ГГц.

@Padavan Имеется клиент Galaxy S25 Ultra с поддержкой 802.11be. Включил соответствующий режим на NC-1812 (NDMS 5.0.0) для обоих диапазонов, MLO выключен. Устройство ожидаемо подключилось в диапазоне 5 ГГц с нужным режимом и соответствующей скоростью передачи данных. Далее для теста я решил привязать S25 Ultra к диапазону 2.4 ГГц. Однако телефон продолжил спокойно себе "сидеть" в 5 ГГц и даже не заметил каких-либо ограничений. Это ожидаемое поведение? Если на NC-1812 отключить be (чтобы телефон подключился в n или ax) то привязка к бенду работает корректно, и телефон четко "следует" настройкам роутера.

@corniger @hellonow По моему мнению, в русскоязычной локализации текст выглядит немного некорректно: Такой вариант выглядел бы лучше: Если вы не видите здесь вашего клиента, проверьте Список клиентов (и добавить ссылку на страницу списка клиентов). Есть незарегистрированные клиенты (X), которых вы можете зарегистрировать (и тут снова ссылка на эту же страницу) На английском языке все выглядит поаккуратнее: Проверял на NC-1812 с 5.0.0.

@Anna_ Планируются ли какие-то правки по данной проблеме? Увидел исправление NWI-4472 в 5.0.0, однако каких-либо изменений в лучшую сторону не заметил.

@eralde @Anna_ Подтверждаю исправление в 5.0.0. Спасибо!

@eralde @Anna_ В 5.0.0 исправлено. Спасибо

Я изначально предполагал, что NTCE распознает домены не по DNS-запросам, а из SNI в TLS Client Hello.

@Le ecureuil Нахожусь в локальной сети своего NC-1812 (установлена NDMS 5.0.0), на котором включен NTCE. На одном из устройств обращаюсь по домену CrazeDNS к веб-интерфейсу удаленного Кинетика. Как и ожидается, в Анализаторе трафика приложений вижу CrazeDNS. Затем, не прерывая сессии управления через веб, подключаюсь к этому же удаленному Кинетику по чистому Wireguard (без единого намека на ASC, даже junk packets). Ожидаю увидеть в NTCE протокол Wireguard отдельной строкой, однако там меня встречает приложение CrazeDNS, у которого растет скорость пропорционально потреблению трафика через WG-туннель: Насколько такое поведение в работе NTCE корректно?

Это уже реализовано: interface WireguardX wireguard peer ... no connect

Именно поэтому я и предложил возложить данную функцию на NDMS 🙂

@Anna_ Судя по всему, были учтены не все "заоблачные" значения времени хэндшейка. В 5.0.0 просачивается, если внести любые изменения в конфиг туннеля:

@Anna_ Раз сейчас всем пирам уже может проставляться no connect, то считаю полезным вынести это как отдельный элемент выпадающего списка "подключаться через". Почему-то no connect предусмотрен только в приложении "Wireguard VPN-сервер", хотя пиров можно было бы выключать и из полноценных туннелей.

У меня для появления ошибки достаточно просто открыть dashboard. Настройки пользователя такие:

@eralde @Anna_ @Test Pilot Если работать с веб-интерфейсом от пользователя с правами manager (администратор с ограниченными правами), то в логе периодически появляются сообщения: Core::Configurator: components list: execute denied [http/rci]. Проверял на NC-1812 с 5.0.0.

@Le ecureuil Было бы неплохо иметь возможность устанавливать индивидуальное расписание работы для каждого Wireguard-пира. Пример, для чего это было бы полезно: На роутере настроена DNS-маршрутизация по доменам. Все клиенты в локальной сети успешно ей пользуются. Благодаря приложению "Wireguard VPN-сервер" или же вручную настроенному WG-туннелю, пиры тоже имеют доступ к сети роутера, где работает эта "волшебная" маршрутизация. Однако, нужно определенным пирам ограничить работу туннеля определенными временными рамками, чтобы они ходили "не туда" только в нужное время. Сейчас расписание можно назначить только на весь Wireguard-интерфейс целиком, что не всегда удобно, а в контексте Wireguard-сервера и вовсе перечеркивает полезность его использования при назначении расписания. А так, получилась бы дополнительная команда вида interface WireguardX wireguard peer ... connect schedule ... или же interface WireguardX wireguard peer ... schedule ...