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-адреса?

В данный момент (после нескольких перезагрузок Кинетика) ситуация слегка изменилась, а именно: 1. В списке устройств дубли исчезли, у каждого MACа свой неповторяемый IP-адрес (на картинке IP-адреса замазаны, но "расшифрую" - для MACа Ethernet-адаптера (00:12:41:...) IP-адрес 192.168.0.80, а для MACа WiFi-адаптера (30:ff:f6:...) IP-адрес 192.168.0.40) 2. Но в логе по-прежнему появляются записи: Авг 16 11:58:23 ndm Hotspot::Discovery::Explorer: "Bridge0": network conflict: hosts 00:12:41:XX:XX:XX and 30:ff:f6:XX:XX:XX have the same IPv4 address 192.168.0.40. То есть, говорится о том, что оба эти MAC-адреса используют один и тот же IP-адрес 192.168.0.40, закрепленный за WiFi-адаптером камеры. Но на самом деле это не так, потому что второй адрес (192.168.0.80, закрепленный за Ethernet-адаптером камеры) пингуется, и через него можно попасть в Web-интерфейс администрирования камеры, и именно по этому адресу камера "прицеплена" к видеорегистратору. Так что получается, что "дуркует" только сам Кинетик. P.S. По факту, конечно же, на работоспособность это не влияет, однако сообщения в логе о якобы существующих ошибках несколько напрягают.

В том-то и дело, что MAC-адреса разные - внимательнее прочитайте первое сообщение. P.S. Для WiFi-адаптера тоже указано "По проводу", потому что он подцепляется к сети не через точку доступа Кинетика, а через другую точку доступа, которая, в свою очередь, соединена с Кинетиком по проводу.

Keenetic Omni, режим роутера, сеть разветвленная (коммутаторы, точки доступа WiFi, порядка полусотни проводных и беспроводных клиентов). В логе повторяется много раз следующая запись: Hotspot::Discovery::Explorer: "Bridge0": network conflict: hosts aa:bb:cc:dd:ee:ff and ff:ee:dd:cc:bb:aa have the same IPv4 address 192.168.0.100 (здесь MAC- и IP-адреса изменены для приватности) Смотрю, что же это за устройства и обнаруживаю, что оба MAC-адреса принадлежат одной и той же камере видеонаблюдения, которая подключена к сети и через Ethernet, и по WiFi (причём, по WiFi не к точке доступа роутера, а к другой точке доступа, тоже входящей в мою сеть - поэтому Кинетик показывает подключение "по проводу") . То есть, один MAC-адрес принадлежит Ethernet-адаптеру камеры, а второй - её же WiFi-адаптеру. И при этом оба этих MACа зарегистрированы как разные устройства, и обоим присваиваются разные выделенные IP-адреса (DHCP static lease). А Кинетик в своем логе упоминает только тот IP-адрес, который принадлежит именно WiFi-адаптеру камеры. Смотрю список устройств и вижу вот такое чудо: зарегистрированное устройство с MAC-адресом WiFi-адаптера повторяется в списке два раза - при этом обе записи полностью совпадают - и присвоенное имя, и MAC-адрес, и IP-адрес, и вид подключения. Ну ладно, думаю. Удалю-ка я их обоих (ну, то есть, две этих одинаковых позиции) из зарегистрированных устройств - пусть "живут своей жизнью." Но при этом Ethernet-подключение камеры не трогаю, оставляю в списке. Удалил. Смотрю - теперь в списке незарегистрированных устройств два устройства "Без имени" с одинаковыми MAC- и IP-адресами. Перезагрузил Кинетик. Ничего не изменилось: всё так же в незарегистрированных устройствах два "близнеца", а в логе снова бегут эти строчки. Что делать-то? P.S. Советы типа "отключи на видеокамере одно из подключений" не принимаются, ибо нужно там иметь и Ethernet, и WiFi. P.P.S. Сохранил конфигурацию в файл - в файле никаких дублей нет. Странно.

KeenDNS - это решение для серых адресов. Мне оно не нужно, т.к. есть белый адрес. Похоже, что таким способом можно получить сертификат только для доменов, базирующихся на KeenDNS, но не для произвольных. P.S. А хотя нет - сработало, хоть и пришлось ждать долго. Спасибо за помощь!

Ну, вот мои настройки. Вроде бы всё, как у вас. Однако, если я обращаюсь... https://myname.keenetic.pro - получаю главную страницу веб-сервера (т.к. он согласно правилам переадресации в статусе DMZ, и на него переадресуется порт 443) https://myname.keenetic.pro:8443 - получаю веб-админку роутера. Меня это удовлетворяет лишь отчасти (т.к. порт не пересекается с https-портом веб-сервера) https://my_domain:8443 - получаю бесконечное ожидание открытия страницы в браузере https://my_ip_address:8443 - получаю бесконечное ожидание открытия страницы в браузере. А мне-то как раз и нужно обращаться извне именно по моему доменному имени (благо есть и белый IP, и зарегистрированный домен), а не через "костыль", предоставляемый KeenDNS

Устройство: Keenctic Omni Версия ПО: Keenetic OS 3.6.10 Нужен доступ из внешний сети к веб-интерфейсу администрирования по протоколу HTTPS на нестандартный порт. Конфигурация такая: "белый" IP-адрес, за роутером работает веб-сервер. Т.к. этот сервер использует (вполне естественно) https и 443-й порт, то на него проброшены порты 80-й и 443-й. В связи с этим обращение извне на https://<domain_name>.keenetic.pro (не говоря уже про https://<IP-адрес>) приводит к попаданию на главную страницу этого самого веб-сервера (и это понятно, потому что 443-й порт переброшен на веб-сервер). Выходом из ситуации было бы назначение для "админки" какого-нибудь нестандартного порта - например, 8443 или 9943 или еще какого-нибудь. Но в GUI-настройках я ничего подобного не нашел. Еще я пробовал назначить переадресацию порта 8443 на 443-й порт самого роутера. И это тоже не помогает. Может быть, можно назначить нестандартный порт не через GUI, а через CLI? Но я не знаю, как.