booroondook

Да, получается, что так. Но тем не менее, получилось хоть какое-то, пусть и очень условное, разделение адресов.

Мне кажется, я нашел более простое решение. А именно: 1. Удалил этот дополнительный сегмент. Вообще. 2. Расширил маску в основной сети до 255.255.248.0 (таким образом, диапазон адресов подсети стал от 192.168.0.1 до 192.168.7.254). При этом диапазон раздачи адресов от DHCP остался прежним (т.е.. не выходит за пределы 192.168.0.X). 3. Поменял IP-адреса объектов CCTV с 192.168.10.X на 192.168.7.X Ну, то есть, вместо маршрутизации между двумя сетями просто расширил одну сеть. Чисто формальное решение - больше для красоты, ибо технического смысла тут никакого.

Да ну. Никаких денег не хватит, чтобы установить вместо свичей управляемые коммутаторы. Я так приблизительно прикинул - понадобится штук 6, не меньше. Ведь смотрите - по сути-то вторая подсеть (ну, пусть она будет 192.168.10.0/24) может существовать и без "вмешательства" Кинетика - там все адреса фиксированные (т.е., услуга DHCP не нужна), вайфай не используется, устройства знают друг друга по IP-адресам. Им нужен только шлюз для выхода в другие сети. Ну и теперь я просто вынужден рассказать, как я решал эту задачу, иначе будет непонятно. Я создал на Кинетике дополнительный сегмент (назвал его "CCTV") с адресом шлюза 192.168.10.1 и маской 255.255.255.0 и прописал этот шлюз в настройках сети всех камер и видеорегистратора. Присвоил видеорегистратору и камерам адреса из диапазона 192.168.10.0/24. Система видеонаблюдения работает штатно, регистратор камеры видит, запись ведет картинку показывает. Но.... Я не могу доступиться из основной сети (192.168.0.0/24) ни к одному устройству в подсети "CCTV". При этом адрес шлюза этой подсети (т.е., 192.168.10.1) пингуется. Пытался настроить маршрутизацию, но не сработало. И более того - в сети "CCTV" устройства между собой пингуются, но шлюз 192.168.10.1 почему-то не пингуется (для этого "эксперимента" я временно менял настройки IP своего компа на подобные тем, что выставлены на камерах). Внешние адреса (например, 8.8.8.8) тоже из этой подсети не пингуются. Для справки: флажок "Изоляция клиентов" в настройках сегмента на роутере выключен.

Боюсь, что нет. А если бы понимали, то что можно было бы сделать?

Я специально не буду здесь рассказывать, что я делал и как я пытался настроить - иначе вместо ответа на свои вопросы получу кучу упреков с указаниями на то, что я делал не так. Итак, есть довольно объемная сеть с адресацией 192.168.0.0/24. Возглавляет сеть Keenetic Skipper DSL, по разным помещениям расставлены еще три "Start" и два "Lite", объединенные в WiFi-систему. Несколько клиентских компов, три сервера, полтора десятка камер видеонаблюдения с видеорегистратором, куча всевозможных "умных" датчиков, выключателей, розеток и лампочек, "умные" колонки, пара Смарт-ТВ и т.д. В-общем, большая помойка. Все это расположено в трехэтажном доме и двух подсобных помещениях - везде протянуты кабели, установлены неуправляемые свичи. Самое главное - разделить сеть на логические сегменты (и использовать для них разные порты роутера) физически невозможно. Встала задача - вынести (логически, не физически) часть оборудования в отдельный сегмент сети, но при этом сохранив связь между сегментами. В качестве "выносимого" оборудования были выбраны камеры видеонаблюдения (16 шт.) в комплекте со своим видеорегистратором. Еще раз хочу уточнить - камеры не подключены к регистратору напрямую - они физически подключены к общей сети патч-кордами к тех местах, где сеть оказалась поблизости. Через свичи, естественно. Видеорегистратор тоже подключен к общей сети наравне с прочими клиентами. Так как система видеонаблюдения использует только кабельное подключение, то наличие точек доступа в этом сегменте не нужно. DHCP-служба в этом сегменте тоже не нужна, т.к. и видеорегистратору, и всем камерам назначаются фиксированные IP-адреса. Соответственно, возникает вопрос - как правильно организовать дополнительный сегмент сети под видеонаблюдение, чтобы при этом из основной сети можно было доступиться до всех камер и регистратора - например, чтобы вывести изображение с камеры на экран ПК, или чтобы настроить регистратор через его веб-админку. Какой адрес выбрать для шлюза, какую маску применить в подсети, как настроить маршрутизацию между сегментами?

Имеется Skipper DSL (KN-2112). Так как в сети расплодилось слишком много "умных устройств", то было принято решение организовать для них отдельный сегмент сети, что и было сделано. Точка доступа WiFi получила имя, отличное от основной ТД, был выделен диапазон адресов (основная сеть - 192.168.0.х, дополнительная - 192.168.100.х), настроен DHCP-сервер. Но оказалось, что ни одно умное устройство - ни "фирменные" датчики, ни "доморощенные" (например, модуль ESP32 с прошивкой Tasmota или ESPHome) по какой-то неведомой причине не хотят подключаться к новой точке доступа. В логах пишут "не удалось подключиться по таймауту" и тому подобное. Стоит перенастроить их на основную ТД - все нормально - подключаются, получают IP-адреса, работают. Что я только ни делал - и по-всякому переименовывал ТД, и менял её протокол безопасности (WPA, WPA2, их комбинации), и отключал 5 ГГц, и вообще снимал защиту, и менял диапазон подсети - ничего не помогает. В конце концов даже вообще удалил этот сегмент и попытался подключить девайсы к "умолчательно" настроенной гостевой сети - опять нет коннекта. Промучился пару дней, уже почти отказался от идеи организовать вторую сеть для IOT, но тут мне на глаза в кладовке попался старый Keenetic Omni (KN-1410), списанный год назад по причине прекращения обновлений. На нем я быстренько смоделировал конфигурацию с двумя сегментами, и... о, чудо... девайсы к точке доступа Omni прекрасно подключились и заработали, причём, именно в дополнительной сети, а не в основной. Получается, что причина в Skipper'е? Он как-то нестандартно транслирует WiFi в дополнительных сегментах, что ли? Кто может помочь разобраться с проблемой?

Как я уже писал выше, в моем случае этот баг вылезает не только для "малинки", но и для нескольких камер видеонаблюдения, которые (так же, как и "малинка") обладают двумя сетевыми интерфейсами - Ethernet и WiFi. При этом не имеет значения, какой именно сетевой интерфейс является в данный момент рабочим - Ethernet, WiFi, или даже оба сразу. Как мне показалось (но я до конца не уверен) для наличия обсуждаемой проблемы нужно, чтобы в Кинетике были зарегистрированы оба MAC-адреса устройства - и Ethernet'овский, и WiFi'ный. При этом DHCP-лизинг для них не является обязательным.

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

Версия 3.9.4 на всех Кинетиках. Лог в момент бага - это как вообще? Вот сижу я за рабочей станцией с Windows 10. Вызываю командную строку. Посылаю команду "ping 192.168.0.xxx". В ответ получаю "Destination host not reachable". Вы этот лог имели в виду, или какой? Роутер такие события не логирует вообще. P.S. Проблема решилась. Симптомы были очень похожи на включенную изоляцию WiFi-клиентов. Оставалось только найти тот модуль, который её включил. И это , судя по всему, оказался OPKG-шный модуль Netfilter. После его удаления проблема перестала проявляться.

У вас по сути вопроса есть, что сказать? Или для вас главное - отметиться сообщением?

Основной роутер: Omni (KN-1410) Ретрансляторы: 3 шт. Start (KN-1111) и 2 шт. Lite (KN-1311) - некоторые связаны с основным роутером по кабелю, некоторые по WiFi Организована WiFi-система. Клиентов сети: порядка 100 (серверы, рабочие станции, камеры видеонаблюдения, устройства умного дома, медиаприставки. телевизоры, смартфоны). Часть клиентов подключена к сети по кабелю, часть - по WiFi через разные ретрансляторы. Проблема состоит в том, что WiFi-устройства (не кабельные, а только WFi), подключенные к ретрансляторам (но не к основному роутеру), недоступны по сети со стороны других клиентов (например, рабочих станций под Windows, серверов под Linux и др.) - а именно: не проходит ping, нет доступа по telnet на известные открытые порты, не открываются веб-интерфейсы (у кого они есть). Точно так же не проходит ping на эти устройства из Web-интерфейсов ретрансляторов (при условии, что устройство подключено не к данному ретранслятору, а к другому). При этом из Web-интерфейса основного роутера ping на эти устройства проходит всегда. Тип недоступного устройства роли не играет - это может быть и IoT-устройство (розетка, выключатель, умная лампа), и камера видеонаблюдения, и смартфон. Стоит также заметить, что IoT-устройства из числа "недоступных" продолжают передавать требуемые от них данные на сервер умного дома и управляться с его стороны. Замечено также, что если перезагрузить (например, по питанию) такое "недоступное" устройство, то оно начинает отвечать на ping, и это продолжается некоторое время, а затем снова становится недоступным. Тот же эффект можно наблюдать, если перезагрузить ретранслятор, обслуживающий такое "недоступное" устройство. Хотелось бы узнать суть описанного явления, а также способы устранения этой проблемы.

Проблема касается не только камер. Например, имеется RaspberryPi, подключенный к сети и по кабелю, и по WiFi. С ним точно такая же ситуация - в списке устройств показываются два устройства с одинаковыми MAC-адресами (причем, и там, и там показан MAC-адрес именно WiFi-карты, а не Ethermet), но с разными IP. А в журнале ошибок указан конфликт между теперь уже разными MFC'ами (Ethernet'овским и WiFi'ным), которые якобы работают на одном и том же IP-адресе (и указан IP-адрес, закрепленный в настройках для WiFi-адаптера). Другими словами, проблема возникает тогда, когда некое устройство-клиент имеет одновременно два подключения к сети через две своих сетевых карты. P.S. Проверил инструкцию по вашей ссылке на Raspberry Pi - не помогло.

Судя по практически нулевой реакции представителей ТП Keenetic, о проблеме знают, но решить её не могут. Я угадал?

Да - так и сделал в итоге. Спасибо! Здесь надо учитывать "skill level" конкретного пользователя. Абсолютное большинство пользователей Андроида и слыхом не слыхивало об этой функции, поэтому они пользуются теми настройками, которые были "из коробки". А "из коробки" как раз настроено на случайный MAC.

Можно ли заблокировать устройство, по неполному MAC-адресу? Немного поясню вопрос. Необходимо заблокировать смартфон на Андроиде (ну, когда-то сдуру сообщили соседке пароль от WiFi, а теперь она "тычется" в мою сеть, а менять пароль WiFi не хочется по ряду причин). Современные версии Андроида устроены так, что при каждом подключении генерируют новый случайный MAC-адрес, поэтому блокировать устройство по полному MAC-адресу - бессмысленная затея. Однако, у этих случайных Мак-адресов есть некая закономерность - первый байт адреса всегда один и тот же, а второй байт может принимать значения в довольно узком диапазоне. В связи с этим возникает вопрос - а можно ли как-то блокировать устройства не по конкретным полным MAC-адресам, а по маске MAC-адреса?