Настройка разделения VLAN на SwitchOS оказалась не такой простой как в обычных коммутаторах, а официальные гайды не предоставляют рабочего примера. Также в сети я не нашёл (особенно не искал) рабочий пример для моего сетапа.
Стандартный сетап в нашем случае - подсеть без тэга как основная и одна (или несколько) входящих тэговых подсетей для разделения по портам.
Коммутатор Mikrotik RB260GSP сделан на основе CSS106-1G-4P-1S поэтому скачивать обновление прошивки нужно для SwitchOS.
По умолчанию коммутатор либо получает адрес по DHCP в сегменте сети, которому подключен, либо, в случае отсутствия DHCP (fallback) назначает себе адрес 192.168.88.1.
Мне нужно подключить коммутатор в кабинете с основной сетью VLAN2, но пробросить туда сеть другого отдела - VLAN16. На этажном коммутаторе меняю тип порта комнаты на trunk и разрешаю два VLAN 2 и 16 (заранее нужно убедиться что VLAN 16 заходит в этажный коммутатор в принципе) при этом назначаю VLAN2 - основным, то есть он будет нетэговым (untagged) на выходе из порта.
После подключения к сети комнаты коммутатор получил адрес в сети по умолчанию VLAN2 - 192.168.2.15. Подключаюсь через браузер, обновляю прошивку, настраиваю имя, пароль и включаю работу с VLAN.
Затем на вкладке VLANs завожу рабочие VLANы.
16 - тэговая VLAN поэтому включаю IVL на ней.
Соответственно распределяю VLAN по портам, если входит - убирать тэг ("always strip"), не входит - соответственно "not a member". Первый порт транк (входящий в кабинет), поэтому всё оставлять как есть "leave as is".
Затем настраиваем на вкладке VLAN аналогично VLANs (по моему мнению, это избыточные, дублирующие настройки, но как есть)
Собственно всё. 1 порт входящий, 2 порт - VLAN16, порты 3,4,5 - VLAN2.
Да, также рекомендую выключить PoE на портах, если технология не используется. Вкладка Link
Если что-то упустил, не судите строго, некогда было вникать глубже, кроме получения рабочей конфигурации.
Akina
С моей точки зрения использование нетегованного VLAN (у вас - VLANID=2) и , как следствие, гибридный режим порта - это неправильно. На транке должны быть только и исключительно тегованные VLAN, нетегованный пакет, который пришёл на транковый порт - это признак, что где-то допущена ошибка. А Native VLAN вообще не должен использоваться, нигде и никак - т.е. либо вообще его удалить, либо хотя бы запретить Native VLAN на всех портах, и уж в самом крайнем случае - просто ни на одном порте не прописывать, пусть игнорирует нетегованные пакеты на транковых портах. Native VLAN - это эдакий коммутаторный NULL.. Тем более что у вас же есть (на скриншоте видно) настройка Allow from VLAN - так что адрес по DHCP вы спокойно можете получить из этого VLAN, если он и на этом коммутаторе, и на соседнем, будет тегованным.
Ещё - у вас по тексту VLANID=2, а на всех скринах, кроме самого первого, почему-то VLANID=1.
Опять же не понимаю, почему вы пишете default VLAN, когда он Native VLAN...
".. также рекомендую выключить PoE на портах, если технология не используется .." - пардон, а что, в коммутаторе нет глобальной настройки подсистемы PoE, чтобы в таком случае отключить её всю централизованно, а не запрещать по отдельным портам?
PS. А почему всё это было не проделать из командной строки? Ну да, вводить руками - это подольше, но зато чётко видно, что, где, как и почему.
DaemonGloom
Судя по всему - только по той причине, что на Cisco он окажется как VLAN 2. То, что в данной ситуации в Микротике он ходит без тега, либо считается первым - автора не смутило.
Default VLAN - так он назван в SwitchOS. Native, untagged, PVID - много имён есть у этого понятия в других системах.
А вообще - это просто пересказ документации, на которую автор сам же дал ссылку.
Akina
На первом скриншоте я вижу именно Native VLAN.
DaemonGloom
А первый скрин - не с Микротика. Это веб-интерфейс Cisco.
NAI
о! А может вы мне объясните построение архитектуры с VLANами, а то я вроде понимаю, но не понимаю.
Абстрактная сеть
Когда нам надо изолировать оборудование - все понятно. Пакет от С1.1
приходит на access порт SW1:1
тегируется,
летит по транкам SW1:24-SW2:23
растегируется и вылетает с access-порта SW2:1
А вот дальше непонятно
Ситуация 1: Допустим, VLAN10, VLAN20 сетям надо выдать доступ в интернет (R1). Правильно ли я понимаю что надо:
SW1:20 - R1:LAN сделать транками для VLAN10, 20
на R1 поднять два виртуальных интерфейса, присвоить каждому свой VLAN, присвоить свой IP адрес из сети VLAN'ов, настроить маршрутизацию\NAT
Ситуация 2. Допустим требуется изолировать пучок клиентов, для примера IP-камер, так чтобы они видели только сервер-видеорегистратор и никто больше не имел к ним доступа. При этом С1.1 и С2.1 хотят тоже иметь доступ к видеорегистратору. Правильно ли я понимаю что:
Можно реализовать тот же подход что и в случае R1, транковая линия SW2-SRV1 + набор IP адресов висящих на интерфейсе сервера, каждый в своем VLAN. Но тогда каждая камера должна висеть в своей IP-сети, т.е. для 150 камер нам надо будет настроить 150 сетей с маской /30. + 2 сети для C1.1 и С2.1, т.е. занять 304 IP-адреса.
Аналогично реализовываем на С1.1 и С2.1, акцесс заменяем на транк, поднимаем два интерфейса с двумя IP каждый в своем VLAN.
Теперь вопросы: а что делают если C1.1 не позволяют поднимать дополнительные интерфейсы и тем более пихать в свои VLAN? Пихают SRV1 в сеть VLAN10 (20) и настраивают firewall (allow C1.1, C2.1; deny all)?
Нет навернется ли сервер\интерфейс от такой маршрутизации (152 сети так-то)?
---
или делают проще - "обратный" vlan:
SW2:20 становится access с PVID:99, плюс untagged vlan 10, 20, 31, 32, 33
SW3:1 ставим в PVID:31 плюс untagged vlan99 - аналогично для 32, 33 и C1.1, C2.1
На сервере прописывается 3 IP-адреса - для VLAN10, 20 и 3*. IP-камерам можно присвоить IP-адреса из одной сети.
Броадкастовый пакет от сервера тегируется 99 VLAN'ом, вылетает растегированным везде где мы указали растегировать, т.е. SW1:1(2), SW3:1(2)(3). В ответ камера (допустим С3.2) отправляет свой пакет который тегируется VLAN32 и вылетает (растегируется) только на SW2:20
Вопросы: так вообще делают? Не охренеет ли коммут SW2 от растегирования 150 VLAN'ов (там же CRC каждого пакета пересчитать надо)?
----
Или есть какие-то другие способы дать общий доступ к ресурсу из разных VLANов?
rainhog Автор
Признаюсь не смог продраться через ваши подробные описания. Для меня VLAN это отдельный провод/кабель сети, просто виртуальный (пакеты помечаются тэгом, вы в курсе), а транк - связка этих кабелей, поэтому если у вас есть необходимость перемещения пакетов из одной сети в другую, вам нужен роутер/маршрутизирующий коммутатор с итерфейсами в каждой из подсетей и, соответственно, таблицей маршрутизации пакетов и, скорее всего, списками доступа. Понимаете?
Akina
Дальнейшие объяснения заставляют думать, что не понимаете.
Нарисуйте модель OSI, которая 7-уровневая. Теперь проведите линию так, чтобы VLAN и всё, что ниже (т.е. L1 и L2), осталось с одной стороны линии, а всё, что выше (т.е. L3..L7) - с другой стороны от линии. И теперь пометьте в своём тексте одним цветом то, что говорит о сущностях и процессах с одной стороны линии, а другим - то, что с другой стороны. Забавная каша, да?
Ну так ресурс-то на верхних этажах. И средства обеспечения доступа к нему тоже должны быть как минимум на L3, а то и повыше. L2 в данном случае только транспорт.
NAI
так с этого и начал что вроде понимаю, а вроде и нет. Т.е. базово L2-домен все понятно. Маршрутизация тоже все понятно, за исключением того когда у нас 150 сетей для вымышленных 150 камер. Т.е. мне скорее нужно подтверждение того что да, это типовой сценарий использования VLAN
Да, только фишка в том что у меня на стенде из 3х комутов "обратный" VLAN работает. IP-камеры и SRV в одной IP сети, но при этом в разных VLAN и траффик между какмера-сервер ходит, а камера-камера нет. И я пытаюсь понять - если это работает то почему никто не пользуется.
Akina
Отлично. Теперь давайте отожмём воду и оставим только факты.
На схеме абстрактной сети присутствует три коммутатора (SWx), один NAT-маршрутизатор (R1), имеющий доступ в Инет и обеспечивающий таковым клиентов из LAN, один сервер (SRV1), выполняющий как функции видеосервера, так и функции глобального маршрутизатора всей сети, четыре рабочих станции (Cx.y) и три видеокамеры (C3.y). Также указаны все физические соединения.
Вот теперь чётко ставьте задачу (узел Mx.y должен иметь доступ к узлу Nx.y)/ Тогда будем расписывать, что и куда.
А пока очевидно следующее. На всех трёх коммутаторах порты 23, 24, а также SW2.20 настроены как trunk. На сервере SRV1 порт настроен в режим multi-VLAN (фактически - trunk). Все остальные, не перечисленные, порты - в режиме access.
Линк между SW1.20 и R1.LAN - в режиме access, т.е. там ходит нетегованный трафик. Порт SW1.20 настроен как access на неуказанный в схеме VLAN (скажем, 100). Тот же VLAN присутствует на портах SW1.24, SW2.20, SW2.23 и SRV1.1.1, везде tagged.
Линк SW2.20 - SRV1.1.1 с обеих сторон в режиме trunk, и там ходят VLANID=10,20,31,32,33,100.
В trunk-линке между SW1 и SW2 ходят VLANID=10,20,100.
В trunk-линке между SW2 и SW3 ходят VLANID=31,32,33.
NAI
Это с чего такие выводы? какой нафиг vlan100 - откуда он взялся? У меня просьба, не копипастить ответы нейронки, я и сам с ней могу пообщаться.
В тексте же написано
вторая задачка:
C3.* <-> SRV1, но при этом каждая С3.* в своем L2 домене и изолирована от других С*.*. Можно ли это реализовать без маршрутизации на SW2 или SRV1?
Akina
Вот НИ РАЗУ не пользовался нейронками для написания ну хоть чего-либо.
Роутер R1 без этого дополнительного VLAN вынужден будет на LAN-порте держать и маршрутизировать в Инет несколько VLAN. Это возможно - но далеко не каждый роутер такое умеет. Да и сервер в такой схеме станет совершенно ненужной деталью.
Вот именно эта задача и решается - сервер маршрутизирует из обеих виланов в дополнительный, а роутер это маршрутизирует в Инет.
Именно так в моей схеме и будет.
NAI
Приношу извинения :], очень уж было похоже, еще раз извиняюсь
Я специально написал что сеть абстрактна чтобы не привязываться к оборудованию, а то обычно начинается "а вот на циске...", "а вот если бы микрот", по факту я обычно вообще работаю с оборудованием про которое мало кто слышал... считаем что роутер general и выбирается исходя из требований
Во-первых сервер это видеорегистратор, ему не нужен доступ в интернет. Во-вторых как-то накладно получается, сначала траффик пойдет по транку SW1-SW2 до SRV1 а потом SW2-SW1. Т.е. у нас один клиент сразу отжирает Tx и Rx от транка и x2 ресурсов SW1, SW2.
VLAN31 - C3.1 - 10.0.0.31/24
VLAN32 - C3.2 - 10.0.0.33/24
VLAN33 - C3.3 - 10.0.0.33/24
Теперь SRV1 к нему пришел транк с VLAN 31,32,32. Далее... мы поднимаем три саб-интерфейса под каждый VLAN? Допустим что-то типа:
Если сейчас сделать ping 10.0.0.33 то получим destination host unreachable т.к. траффик пойдет в vlan31 интерфейс. Так?
Нужна маршрутизация прибитая гвоздями, что-то в духе:
Правильно все понял?
Akina
Именно потому я и не закладываю в схему экзотические способности оборудования.
Вот серьёзно - в разных виланах один и тот же адрес, да? в таком случае вам без промежуточного сервера вообще никуда. Потому как потребуется двойной NAT (сперва SNAT, чтобы развести интерференцию адресов источников, а потом обычный DNAT). А обычные генерик-роутеры такого просто не умеют, не по Сеньке шапка..
Иными словами, задача уже вышла далеко за уровень L2..
NAI
ну очевидно же что при копипасте туда закралась опечатка, ессно адреса(10.0.0.31...33) разные, а вот сеть одна /24
так правильно или не правильно? и в случае 150 клиентов C3.1...C3.150 надо занять 300 адресов (что в общем-то не реализуемо с /24 маской) и зафаршмачить 150 правил маршрутизации?
Ну и схема не реализуется если вдруг окажется, что SRV1 проприетарная железка и не умеет в транки и суб-интерфейсы?
да, но есть нюанс - как писал выше, на стенде, завелась схема в которой вообще нет роутинга - ни на srv1, ни на sw1..sw3 никакого (R1 только NATит C1.* и С2.*).
вот, как-то не очень понятно почему оно работает и почему этим никто не пользуется
rainhog Автор
Не понимаю что конкретно неправильно? Дело в том, что ДО ТОГО как мне потребовалось завести в кабинет дополнительную подсеть для конкретного сотрудника, в кабинете УЖЕ БЫЛА обычная, нетегированная сеть VLAN2 с обычным неуправляемым коммутатором и это было абсолютно нормально, поскольку это уровень доступа. Я заменил устройство на другое, понимающее 802.1Q чтобы завести теговую подсеть к конкретному порту, при этом других портов это не касается. Мало того, в процессе перенастройки никто из сотрудников этого даже на заметил, поскольку все продолжали работать в своей нетеговой сети на обычном коммутаторе даже с переключенным на транк в этажном коммутаторе Cisco, где именно эта концепция принята за норму, все порты по умолчанию в Cisco (в моём случае C9300L-48P-4X-A) именно trunk с native VLAN для уровня доступа. А также, в случае если потребуется вернуть обычный коммутатор в комнату, всё будет работать сразу без проблем.
Даже в ядре сети в транках есть нетегированная подсеть для отказоустойчивости(ни к одном новом устройстве нет преднастроенных VLAN кроме 1 и некоторых специфических для телефонии и прочего, и оно подключится) и это нормально.
Akina
То есть у вас был порт, к которому был подключён коммутатор, на котором было несколько клиентов, а порт тем не менее работал в режиме access.. И вы ещё спрашиваете, что не так?
Да, нормально. Для НЕНАСТРОЕННОГО оборудования. Для того, чтобы коммутатор сразу после включения мог функционировать, эмулируя неуправляемый коммутатор. То есть для полных [censored]. Но на практике коммутатор сначала должен попасть в руки сетевого инженера, который создаст в нём требуемую для конкретной точки сети конфигурацию, и только потом коммутатор сможет встать на своё рабочее место. Но когда он прошёл настройку и включился в работу в сети, гибридный режим работы порта - это НЕнормально. Это либо ошибка настройки, либо режим аварийного восстановления сети.
rainhog Автор
Возможно понял суть вашей претензии. Тегируют весь рабочий трафик и оставляют неиспользованную Native VLAN ради защиты от vlan хоппинга, поэтому это принимают как норму. Но в моём случае, на порту кабинета определены конкретные два VLANа, используемые в кабинете и злоумышленник может попасть только в них. С точки зрения технологии всё валидно, но понимаю вашу озабоченность с точки зрения принятия такой схемы как стандарта.
Akina
Нет. Злоумышленник как раз может со станции, подключенной в порт VLANID=16, попасть в ваш VLANID=2. Для этого ему нужно просто (не, ни фига не просто на практике, но возможно) формировать спецпакеты, которые при снятии с них обёртки VLANID=16 оставят пакет в обёртке VLANID=2.
rainhog Автор
Ещё раз, возможно я недостаточно ясно выразился. В кабинете УЖЕ была сеть VLAN2 и ВСЕ работали там кто подключен к розеткам в кабинете. VLAN16 я добавил как дополнительный и кому нужно, нехай сидят там. Вы, видимо, не слышали про проблему солонки в столовой, любой теоретически может туда насыпать яд, но делать защиту солонки никому в голову не придёт.
Akina
Раз было несколько розеток с одним виланом - значит, был коммутатор, который раздавал этот вилан по розеткам. Но раз у вас в схеме этот вилан идёт в такой коммутатор нетегованным, то вот это и есть бардак.
rainhog Автор
Можете пояснить разницу между Native VLAN и Default VLAN? Если для вас это принципиально, я могу поправить в тексте специально для вас.
Akina
Мне глубоко параллельно, какой термин вы будете использовать. Но главное, чтобы он был везде один и тот же.
Если на первом скриншоте вы уже застолбили один вариант, то и используйте его везде.
Или начните статью с раздела Термины и определения, и там укажите, что default VLAN и native VLAN у вас в статье - синонимы.
rainhog Автор
Внимательно перечитал свою статью и не заметил ни одного слова default Vlan. Термин Native VLAN приведён на скриншоте Cisco и не вижу в этом проблемы. Нашёл для вас определение: https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/lyr2-fwd/vlan/vlan-configuration-guide.pdf
То есть это не NULL а вполне себе нормальная, обычная сеть, для оборудования, неподдерживающего 802.1Q. Да, есть концепция, что рабочий трафик не стоит отправлять по native VLAN, но в моём конкретном случае, я заменяю порт типа Access (где трафик нетегированный) на точно такой же, только с дополнительным VLAN с жёстко настроенным транком только на конкретные VLAN. Не стоит так переживать.
Akina
Признаться, я в недоумении. Ну вот полное впечатление, что в статье было слово default, именно по отношению к default/native VLAN, причём один раз оно было в скобках и на импортном, и один или два раза - русской калькой. Сейчас я ни одного не вижу - то ли поправлено, то ли это был крутой утренний глюк.
PS. К слову, мне как раз термин default более привычен, чем термин native.
Вот определения - ни о чём. Во-первых, сей текст в принципе не допускает варианта, когда один и тот же VLAN относится к более чем одной группе. Во-вторых, в общем случае только на основании конфигурационного файла коммутатора в принципе невозможно определить, к какой группе относится определённый VLAN, более того, один и тот же VLAN может на разных коммутаторах относиться к разным группам.
Вот какой дебил это написал? По этому определению абсолютно все VLANID коммутатора, для которых имеется хотя бы один access порт (как чистый access или как hybrid - неважно), являются native VLAN. Потому что он стопроцентно выполняет процитированное условие. А всё остальное в этом абзаце определяющими условиями не является.
А тут вообще нет определения. В принципе. Налито какой-то малопонятной воды немножко, и только. На основании этого абзаца категорировать какой-либо VLANID как default после почти любой перенастройки коммутатора невозможно, потому что тут нет ни одного критерия, пустой ни к чему не обязывающий трёп.