dimon27254

На случай недоступности GitHub на территории РФ, запущен antiscan.ru - будущий сайт проекта Antiscan. Сейчас он находится в разработке, однако на нем уже работает зеркало для обновления списка подсетей стран, а также репозиторий для обновления Antiscan. Скрипт для установки Antiscan с российского репозитория: opkg update && opkg install curl && curl -fsSL https://bin.antiscan.ru/packages/install.sh | sh Обратите внимание: если у вас ранее был добавлен GitHub-репозиторий, то при использовании данного скрипта он будет заменен на bin.antiscan.ru, и дальнейшие обновления будут загружаться с российского сервера. Вручную перейти на российский репозиторий можно командами: opkg update && opkg install wget-ssl ca-bundle mkdir -p /opt/etc/opkg echo "src/gz antiscan https://bin.antiscan.ru/packages/all" >"/opt/etc/opkg/antiscan.conf" opkg update От GitHub-репозитория я отказываться не планирую, он будет обновляться совместно с российским.

Вышла версия 1.10. Новое: 1. Исключения по странам. Теперь вы можете указать список доверенных стран, доступ с которых не будет ограничиваться Antiscan. За этот функционал отвечает новый параметр GEO_EXCLUDE_COUNTRIES. Страны указываются также, как и в GEOBLOCK_COUNTRIES - в формате ISO 3166 и количеством не более 8. Для использования функционала в ascn.conf должен быть указан каталог для хранения списков адресов (IPSETS_DIRECTORY). Исключения по странам могут работать как самостоятельно, так и вместе с геоблокировкой. Возможно указание одной и той же страны одновременно как в списке геоблокировки, так и исключений. Пример использования такого сценария: Пусть в белом списке находится Россия и Казахстан (разрешены подключения только с IP России и Казахстана). Есть необходимость разрешить пользователям из России неконтролируемый Antiscan доступ к открытым портам, но при этом сохранить работу геоблокировки. В список исключений указывается Россия, и тогда все подключения, принадлежащие российским IP, будут Antiscan игнорироваться. Однако, подключения из Казахстана останутся разрешены, а из остальных стран, не входящих в белый список, запрещены. 2. Управление состоянием блокировки по накопленным IP/подсетям. Для управления этим видом блокировки добавлен параметр ENABLE_IPS_BAN. Значение по умолчанию - ENABLE_IPS_BAN=1 (блокировка включена). Если установить ENABLE_IPS_BAN=0 (выключить), то будет приостановлено: 1) Отслеживание множественных соединений с одного IP; 2) Накопление IP-адресов кандидатов на блокировку (отслеживание соединений с множества IP, принадлежащих одной подсети). 3) Свертывание накопленных IP адресов в подсети для блокировки; 4) Сама блокировка по накопленным спискам IP и подсетей. 3. Управление состоянием работы "ловушки". Теперь нет необходимости очищать список портов, чтобы отключить ловушку - достаточно изменить значение в новом параметре ENABLE_HONEYPOT. ENABLE_HONEYPOT=1 - ловушка включена, ENABLE_HONEYPOT=0 - выключена. Если в ascn.conf у вас ранее были указаны порты в HONEYPOT_PORTS, то при обновлении на 1.10 значение параметра ENABLE_HONEYPOT установится 1. В ином случае 0. Улучшения: 1. Повышена надежность загрузки списка подсетей стран. Если Antiscan не удастся скачать списки с оригинальной базы RIPEstat (stat.ripe.net), то будет выполнена попытка загрузки с зеркала. 2. Разделение исходного кода Antiscan на модули (предложил @eralde). Основной исполняемый файл S99ascn уже насчитывает более 1500 строк. С целью повышения читаемости исходного кода, функции из S99ascn вынесены в отдельные скрипты-модули, каждый из которых отвечает за определенную функциональность. Эти скрипты находятся в каталоге /opt/etc/antiscan/scripts. Удалять их строго запрещено, иначе работа Antiscan будет нарушена! Например, в config.sh приведены все функции, связанные с чтением и обработкой конфига ascn.conf. Исправления: 1. Если в GEOBLOCK_COUNTRIES указать страну, для которой в RIPEstat нет IP-адресов, то Antiscan при загрузке возвращал ложно-положительный статус. 2. Работа команды antiscan edit config блокировалась при наличии ошибок в ascn.conf. 3. После редактирования пользовательского списка исключений с помощью команды antiscan edit custom_exclude, в консоли могло появляться сообщение sh: bad number.

@eralde @Anna_ @Test Pilot Если какое-то из устройств в сети Кинетика откроет большое количество соединений (больше 1000), то на вкладке становится заметным появление некоторой задержки в работе. Можно попробовать открыть список соединений такого устройства, и веб-интерфейс на некоторое время зависнет, а браузер выдаст сообщение "страница не отвечает". Возможно ли это как-то подправить? Проверял на NC-1812 с 5.0.0.

@Anna_, у меня эта проблема тоже воспроизводится: Видны "подергивания" графика в момент, когда изменятся ширина правого блока с круговой диаграммой и легендой. ОС Windows 11 25H2, браузер Google Chrome 142.0.7444.135. Экран 1920x1080 с масштабом 125%.

@eralde @Anna_ @Test Pilot В мобильной версии журнал переходов становится нечитаемым, если раскрыть блок с фильтрами: Проверял на NC-1812 с 5.0.0.

Интересное наблюдение: Телефон подключается к 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 ...

Прикрепил. В модем вставлена сим-карта с отрицательным балансом (доступ в интернет отсутствует), на Кинетике настроен автоматический режим ping-check.

Это, вероятно, сработает при "белых" списках, но при отрицательном балансе ICMP у меня вообще не проходит. Мысль моя из первого сообщения заключается в том, чтобы понять, есть ли возможность у NDMS "остановиться" после нескольких перезагрузок модема, и просто ожидать появление доступа в интернет.

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

@slomblobov Пусть имеется USB-модем, подключенный к Кинетику/Неткрейзику, и для него настроен ping-check. Далее у USB-модема пропадает выход в интернет. Например, из-за не пополненного вовремя баланса, отключения мобильного интернета или полного пропадания сотовой сети. Как и ожидается, ping-check срабатывает и перезагружает модем. Однако потом, если доступ в интернет не появился, то выполняется повторная перезагрузка. И так далее, NDMS продолжает без остановки перезагружать модем, ожидая, что интернет когда-то все таки появится. Нет ли каких-то "крутилок" в прошивке, которыми можно было бы ограничить количество перезагрузок определенным значением, или же увеличить интервал между ребутами?

Проверьте, установлен ли у вас компонент "Модули ядра подсистемы Netfilter". Без него работа Antiscan невозможна.