Сразу оговорюсь, что данная статья про Router OS, а не Switch OS.
На мой взгляд, работа с VLAN в Mikrotik освещена хуже всего. Да, конечно есть набор статей на эту тему, например вот:
https://lanmarket.ua/stats/bazovye-osnovy-nastroyki-vlan-v-routeros-na-oborudovanii-mikrotik-vlan-dlya-chaynikov-segmentatsiya/
https://настройка-микротик.укр/nastrojka-vlan-v-mikrotik-trunk-i-access-porty/
https://habr.com/en/post/322720/
И тому подобное, включая официальную документацию. Но лично я когда их все читал... У меня не складывалось глубокого понимания, как именно это всё работает, только возможность повторить типовую конфигурацию.
То есть, эти статьи хороши, но на мой взгляд написаны для специалистов по микротикам, которым понадобилось еще и в VLAN. А мне хотелось бы видеть статью, которая для специалистов по сетям, которым надо привычные вещи реализовать на железе Mikrotik. И соответственно, осветить эти вопросы на мой взгляд надо бы с несколько другой стороны. И поскольку я такой статьи не нашел, решил сесть и написать её сам :). Так что и говорить я буду привычные вещи, но другими словами. Итак, приступим...
Самое первое, что надо помнить -- сетевые операции происходят на пакетах без тэга. А тэги появляются только тогда, когда появился bridge. То есть, если понадобилось например выдать адрес по DHCP, то для этого нужно чтобы DHCP-сервер микротика смотрел на собственный bridge со стороны без тэга. Аналогично со всеми остальными "высокоуровневыми" операциями. Никаких тэгов внутри "умной" чисти Микротика нет! Поэтому если нужны тегированные VLAN'ы, надо "довешивать" тэги позже.
Второе, что надо понимать на мой взгляд -- тег снимается (для исходящего и добавляется для входящего трафика) в тот момент, когда пакет доходит до порта (не важно, физического в мосту, виртуального или автоматически созданного чем-то вроде CapsMan'а), в свойствах которого этот самый тег указан. То есть, вот примеры точек, с одной стороны ("внутри" bridge) от которых тэг есть, а с другой -- уже нет (Рисунки 1, 2 и 3)
Третье, что надо понимать... Мост умеет фильтровать теги. Если фильтрация тегов выключена вообще, то не на всех устройствах механизм работы с VLAN вообще будет работать, а если фильтрация запрещает лишние тэги, то искать проблемы можно долго. Лучший вариант на время диагностики поставить галку "VLAN filtering" и "Admit all".
И внутри моста какой-то один VLAN считается по-умолчанию и идёт без тега, а остальные -- с тегом. Добиться того, чтобы все VLAN были с тегом и не было ни одного дефолтного, но при этом всё работало, лично у меня не получилось. Поэтому лично я не тегирую сервисный VLAN 1, куда доступ открыт только авторизованным лицам и устройствам, во всей статье умолчания такие.
То есть, вписываем тэг "1" в свойства моста, после чего Vlan 1 считается в этом мосту нетегированным и порты, которые в этот мост включены и в свойствах которых прописан тэг 1, не будут пытаться его снимать.
Четвертое... Чтобы мост пропускал тегированный трафик мало поставить галку "Admit all", надо еще и добавить сам мост в конфигурацию VLAN в поле "tagged".
И пятое -- автоконфигурации работают несколько мимо этих механизмов. И поэтому если у вас в бридже есть порты, настроенные вручную и они наглухо не работают как надо, но при этом другие порты работают хорошо, но те настроены автоматически (туннель, капсман, прочее), то скорее всего конфигурация ошибочна и если ошибку исправить, то вручную настроенные интерфейсы заработают, а автоматически настроенные при этом не сломаются.
Пример работы со всем вышеперечисленным
Итак, есть сеть, в которой микротиковая точка доступа используется просто как точка доступа. А точнее, их две и между ними реализовано бесшовное переключение средствами CapsMan'а. Точки раздают по 2 сети, одна из которых -- техническая, вторая -- гостевая, внутри сети разделение происходит на уровне VLAN. Тэг 1 для технической, 2 -- для гостевой. Пока всё достаточно типовое и подробного описано много где.
Но у нас шлюз сделан не на микротике, является отдельно стоящей машиной и потому с точки зрения логики сети, микротики к второму влану не подключены, хотя его и раздают. Реализовано это очень просто: на микротике создан единственный бридж с тэгом 1 в свойствах фильтрации. При его создании на вкладке VLAN автоматически появилась первая запись, она описывает конфигурацию по-умолчанию и потому в левом столбике обозначена буквой "D". Далее, мы вручную создали второй VLAN с тэгом 2 и вручную добавили туда порты (Рис. 3).
А в CAPsMAN на вкладке Datapaths создали путь для тэгированного трафика (Рис. 1)
Порт ether1 воткнут в тот же свитч, что и управляющее устройство и схема работает на отлично: трафик от клиента приходит на вайфай, где на него навешивается тэг из-за настройки Datapath, благодаря которой капсман создаёт порт Wlan сразу с тэгом в свойствах, дальше это счастье идёт через мост и в конце тэг не снимается когда трафик проходит через порт eth1, потому что в свойствах порта стоит тэг 1, а потому тэг 2 он просто игнорирует, пропуская пакеты насквозь, дальше тэгированные пакеты уходят в сеть и проходя через любое количество оборудования прямо в таком виде, доходят до сервера, который в курсе, что с ними делать, а потому и ответы шлёт также, с тэгом, с которым они и проходят обратный путь, теряя его только перед уходом "в среду" WiFi.
Но через какое-то время появляется задача изменить настройку и сделать, чтобы гостевой трафик шел через саму точку доступа, а точнее, через порт eth2 и далее к провайдеру, а основной остался на том же маршруте, что и был. Идём и создаём "Interfaces - Interface - '+' - Vlan", указываем там бридж и нужный тэг (опять же как на рисунке 1), прописываем ему интерфейс, для проверки пингуем любой другой адрес в гостевой сети и... получаем облом.
А всё потому, что несмотря на то, что тегированный трафик, заданный капсманом через бридж идёт... Но "вы не понимаете, это другое", а вообще бридж тегированный трафик режет. И чтобы это исправить, надо применить четвертый постулат из списка выше и исправить конфигурацию вот так (да-да, бридж указан в собственных VLAN-ах во всех строчках и это правильно):
Теперь всё пингуется и можно настроить остальные вещи типа фильтрации, НАТ и прочее, но это типовые вещи, о которых можно прочитать в других местах и потому выходят за рамки этой статьи.
