Russian Users MikroTik | Форум пользователей MikroTik

Досталась сеть крутящаяся на Mikrotik RB 1100AH. В ней есть примерно 150 устройств и нет ни одного управляемого коммутатора. Еще есть совершенно ужасное каскадирование, видимо родившееся в процессе роста сети. Все подключенные устройства сидят в 192.168.2.0/24, то есть рабочие станции сотрудников, сетевые принтеры, точки доступа и подключающиеся к ним мобильные устройства, видеонаблюдение, биометрия и все все все находиться в одной сети. При этом на одном физическом порте Микротика может висеть, несколько разных отделов, которые ни как не связанны ни какой логикой бизнес процессов или иной, там же несколько IP камер и сканер отпечатков. Возможности перетянуть сеть нет, одномоментно заменить все свичи на управляемые нет. Значит привести сеть к структуре в которой можно использовать vlan нет, я правильно понимаю? Но очень хочется поделить сеть и сделать это в соответствии хоть с какой-то логикой.
Разобраться хочу на примере видео наблюдения.Сейчас это:
сетевой регистратор: 192.168.2.66 сидящий за свичем на eth7
камеры: 192.168.2.75, 77, 79, 83, 85, 87, 89, 91, 93, 95, 96, 97, 98-102 на eth5
Естественно на этих интерфейсах кроме них есть и другие клиенты.
Так вот возможно ли вывести в отдельную сеть, пусть 192.168.2.0/24 видео наблюдение, при этом предоставив туда доступ нескольким станциям и мобильным устройствам из .2.0/24 или я слишком много хочу и начинать нужно с физической структуры сети.

С Микротиком мы сейчас в начала нашего знакомства, цветочно-конфетный период у нас.

UncleD писал(а): ↑23 июл 2020, 14:33 одномоментно заменить все свичи на управляемые нет. Значит привести сеть к структуре в которой можно использовать vlan нет, я правильно понимаю?

Да, правильно понял.
Если нет возможности физически разнести сеть камер, регистратора в отдельний порт микротика, без управляемых свитчей не обойтись. Или перетягивать сеть отделную к камерам, регистратору.

UncleD писал(а): ↑23 июл 2020, 14:33 Так вот возможно ли вывести в отдельную сеть, пусть 192.168.2.0/24 видео наблюдение, при этом предоставив туда доступ нескольким станциям и мобильным устройствам из .2.0/24 или я слишком много хочу и начинать нужно с физической структуры сети.

Ну делать какие то движение в занятой грязной сети как-то странно и страшно.
Я бы пошёл (и в какой-то степени давно так тоже делал), я начинал выводить часть
служб/сервисов отдельно.
Хотя бы пока у Вас нет управляемых свитчей, надо хотя бы логику почистить.
То есть сделать сетку скажем 192.168.5.0/24, она будет чисто для видеонаблюдения.
Потихоньку сидеть и камеры "перебивать" на эту сеть, а потом сделать маршрутизацию
между грязной текущей сетью 2.0/24 и 5.0/24. А когда свитчи умные появятся и виланы
будут, сделаете к примеру вилан5 и там будет только сеть 5.0/24.
В любом случаи это логическая чиста, зато и часть оборудования разделите по сетям,
и порядок какой-то будет.

UncleD писал(а): ↑23 июл 2020, 14:33 С Микротиком мы сейчас в начала нашего знакомства, цветочно-конфетный период у нас.

Надо изучить, а Вы сразу виланы, разделения. Быстры Вы.

Чисто теоретически, если камеры и регистратор позволяют, то возможно они умеют во вланы самостоятельно, т.е. они будут тегиоровать свой трафик, а ваши "тупые" л2 свичи поидее будут спокойно пропускать такой трафик, который вы уже разгребете на микроте при помощи вланов. Так же есть еще костыльный вариант - вы просто создаете еще один адрес на бридже микротика, без dhcp и начинаете переводить камеры и т.д. на эту другую сеть, т.е. это будет дикий костыль, но хоть чуть чуть разграничить сеть позволит, т.к. маршрутизироваться камеры будут уже микротиком и соответственно вы сможете контролировать доступ. Безопасности при этом будет еще меньше чем в первом варианте, любой знающий и желающий сможет задать себе адрес из нужной сети и получить доступ в обход микротика, но именно второй случай даст вам возможность подготовить сеть к умным свичам. Оба варианта больше костыль, но все же имеют право на жизнь.
Ну а в идеале, да, вам нужны управляемые свичи, которые позволят полноценно отделить сети.

KARaS'b писал(а): ↑23 июл 2020, 23:28 Чисто теоретически, если камеры и регистратор позволяют, то возможно они умеют во вланы самостоятельно

Не умеют.

KARaS'b писал(а): ↑23 июл 2020, 23:28 Так же есть еще костыльный вариант - вы просто создаете еще один адрес на бридже микротика, без dhcp и начинаете переводить камеры и т.д. на эту другую сеть

То есть присваиваем бриджу еще один адрес и руками прописываем его шлюзом на камерах, правильно? А dhcp не используем потому что на один интерфейс больше одного dhcp повесить нельзя, верно?

KARaS'b писал(а): ↑23 июл 2020, 23:28 это будет дикий костыль, но хоть чуть чуть разграничить сеть позволит, т.к. маршрутизироваться камеры будут уже микротиком и соответственно вы сможете контролировать доступ.

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

KARaS'b писал(а): ↑23 июл 2020, 23:28 Безопасности при этом будет еще меньше чем в первом варианте, любой знающий и желающий сможет задать себе адрес из нужной сети и получить доступ в обход микротика, но именно второй случай даст вам возможность подготовить сеть к умным свичам.

А можете пояснить в чем именно проявится снижение безопасности? Так как прописать каждый желающий может и сейчас, не смотря на наличие dhcp. Отсюда еще вопрос, возможно ли запретить получение адресов неизвестными клиентами, а еще лучше отбрасывать их совсем?

А если кинуться в совсем не традиционную ортопедию и выдать третий костыль в виде увеличения пула dhcp до 192.168.2.0-192.168.5.254, или даже изменить его на 192.168.2.0/21 или /22? При таком варианте мы ни как не можем выдавать конкретным клиентам конкретный шлюз?

1) "То есть присваиваем..." - Да, просто еще один адрес микротику, с нужной маской, а камерам даете адреса из этого пула и в качестве шлюза адрес который задали на микротике. Два dhcp нельзя даже по соображениям логики, протокол устроен так что в пределе одного сегмента используя два dhcp сервера вы получаете проблемы и не более того. Поищите информацию о принципах работы и вам все станет ясно.
2) "В этом случае маршрутизация..." - Тут долго объяснять, это основы сетей, в кратце все что доступно в пределах маски будет опрашиваться бродкастом, все что не покрывается маской и не имеет иных маршрутов, будет запрошено у шлюза. В вашем случае и камеры и клиентские устройства скорее всего будут иметь 24 маску что не даст общаться клиентам и камерам напрямую, из-за этого общаться они смогут только через шлюз.
3) "А можете пояснить в чем именно проявится снижение безопасности?..." - Опять основы, но вкратце, когда у вас вланы, то устройства физически соединены свичем, но логически могут быть разделы этим же свичем при помощи вланов, т.е. рядом стоят два компьютера, воткнуты в соседние дырки свича, но находятся в разных вланах, т.е. как будто подключены к двум разным свичам, при этом даже задав одному из компьютеров адрес сети соседнего, логически вы рядом с ним не окажитесь и добраться до него не сможете, потому что хоть адрес и поменяли но влан остался прежним и он по прежнему идет к устройству которое терминирует его и маршрутизирует его клиентов, в том числе возможно и ограничивая доступность тех или иных узлов сетей и т.д.. В вашем же случае, используя просто разную адресацию, но в пределах одного и того же л2 сегмента, такого добиться нельзя, любой желающий может взять и изменить себе адрес на нужны и получить доступ к чему желает.

KARaS'b писал(а): ↑24 июл 2020, 23:24 Да, просто еще один адрес микротику, с нужной маской, а камерам даете адреса из этого пула и в качестве шлюза адрес который задали на микротике.

Значит, все таки увеличиваем пул dhcp? Иначе как быть с устройствами, которые не умеют в ручное назначение IP адресов (есть тут такие камеры)?

Давно вывел несколько камер в 5.0/24 и они там успешно существуют, позволяют подключиться и к собственным вебмордам из 2.0/24 и успешно подключаются к регистратору, находящемуся там же. А тут решил, почему бы не попробовать такой же фокус с сетевыми принтерами? И увел парочку в 4.0/24. В целом работает, но ощутимо увеличилось время отправки задания на печать. Нужно ли было сопроводить это еще какими-то изменениями?