ИТ База знаний
Курс по Asterisk
Полезно
— Узнать IP — адрес компьютера в интернете
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Калькулятор инсталляции IP — АТС Asterisk
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Настройка VLAN в Mikrotik
Умение настраивать VLAN (Virtual Local Area Network) или виртуальные локальные сети — одно из самых базовых умений, которым должен обладать системный администратор. Сегментирование сети с помощью VLAN-ов строго необходимо для PCI, HIPAA и прочих стандартов безопасности, и, кроме того, это помогает сохранять “чистоту” и порядок в больших сетях. Настройка VLAN-ов на маршрутизаторах MikroTik не является сложной задачей, подробнее о шагах настройки вы можете прочесть ниже.
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Дизайн VLAN в организации
Первым шагом в сегментировании сети должен быть не настройка маршрутизатора, а понимание будущей схемы в целом — предпочтительно нарисовать схему на листе бумаги, использовать ПО наподобие Microsoft Visio и т.д. К тому же, если ваша сеть должна соответствовать стандартам безопасности, которые были перечислены выше, то практически не нужно ничего придумывать — в описании стандартов есть подробные инструкции что и как должно быть сегментировано. Однако, чаще всего, сегментирование происходит для общей оптимизации сети — и тут необходимо будет что-то придумать самому. На наш взгляд, проще всего отразить структуру организации в схеме VLAN-ов. Каждый департамент должен находится в собственном VLAN-е, т.к каждый департамент обладает своими собственными уникальными функциями, и, скорее всего, различными правами доступа. Также в отдельные VLAN-ы необходимо поместить сервера и дисковые хранилища.
Для серверов и хранилищ рекомендуется использовать отдельные коммутаторы, но, для маленьких компаний это часто невозможно из-за лимитированного бюджета.
К тому же, с помощью таких инструментов как Torch или NetFlow можно будет контролировать и мониторить трафик каждого департамента. Гостевая сеть также должна быть помещена в отдельный VLAN, который будет полностью изолирован от внутренней сети. Беспроводные сети также должны находится в своем VLAN, таким образом весь трафик мессенджеров, обновлений мобильных приложений и т.д будет полностью отделен от основной сети.
Транковые протоколы VLAN
В нашем сценарии у нас есть только один роутер, и создадим VLAN-ы для HR (192.168.105.0/24), бухгалтерии (192.168.155.0/24) и гостевую сеть (192.168.1.175.0/24). Если у вас получится создать три VLAN-а, то, очевидно, получится создать и сто — в нашем примере мы описываем создание только трех VLAN-ов для простоты и прозрачности примера. IP-адреса для каждого VLAN-а также были выбраны случайным образом — для вашей организации, скорее всего, адресация будет иной. В нашем случае, маршрутизатор подключен к коммутатору по интерфейсу ether2, с 802.1q транком между ними — эта схема также известна под именем “роутер на палке” (router on a stick). Мы не будем углубляться в детали касаемо свитча — это может быть Cisco, HP и т.д — потому что 802.1q транки одинаковы практически на всех платформах — если у вас какой-нибудь необычный свитч, то вам стоит просто обратиться к документации и прочесть, как выполняется конфигурация транкового порта. Наш маршрутизатор также обладает подключением к WAN на порту ether1 — все пользователи в VLAN-ах будут использовать его для доступа к интернету.
Создание VLAN-ов на MikroTik
Сперва необходимо создать VLAN-ы на маршрутизаторе и назначить их на интерфейс ether2. После этого, интерфейс ether2 будет автоматически настроен как 802.1q транк и не будет доступен для трафика без тэгов, что означает, что до конца настройки этот линк будет “лежать” — поэтому строго рекомендуется выполнять эти действия во в нерабочее время.
Крайне рекомендуется всегда давать понятные имена интерфейсам и писать комментарии — в дальнейшем это может сильно облегчить администрирование сети и обучение новых системных администраторов. Как мы упомянули выше, создание VLAN-ов и назначение их на физический порт ether2 автоматически изменит тип инкапсуляции на 802.1q, но вы нигде этого не увидите — даже если выведете всю информацию об интерфейсе.
Назначаем IP-адреса
Далее, необходимо назначить сетевые адреса, чтобы VLAN интерфейсы могли работать как шлюзы:
На всякий случай, еще раз обращу ваше внимание на то, как важно комментировать интерфейсы для удобства в дальнейшем. На данном моменте у нас уже настроены VLAN-ы и у них назначены сетевые адреса. Если у вас не используется DHCP, а используется статическая адресация — на этом настройка VLAN в общем-то закончена. Следующим шагом (этот шаг, соответственно, опционален) является настройка DHCP на VLAN интерфейсах, для того чтобы клиенты внутри каждого VLAN могли автоматически получить динамический IP-адрес.
DHCP для VLAN
Для начала, необходимо установить адресные пулы для каждого из VLAN-ов:
Далее, настраиваем DHCP с опциями для DNS и шлюзов:
В данном случае мы используем DNS сервис от Google. Далее, добавляем ранее настроенные пулы на VLAN интерфейсы:
Адресные пулы соответствуют настроенным сетям, и именно такие DHCP опции как шлюз и DNS присваиваются конкретной DHCP инстанции. Смысл присвоения DHCP для каждого VLAN в том, чтобы у вас была возможность контролировать сроки выдачи адреса (lease times), опции и т.д для каждого сегмента сети, что дает большой простор для оптимизации и контроля DHCP в вашей организации.
Настройка VLAN на коммутаторе
На данном этапе настройки вам необходимо будет назначить порты доступа на ваших свитчах на конкретные VLAN-ы, и клиенты, которые будут подключены к этим портам будут находится в их VLAN и получать соответствующие IP-адреса по DHCP. Теперь уже вам решать, какие VLAN будут полностью изолированы друг от друга, а какие смогут “общаться” — осталось только настроить соответствующие правила на фаерволле. Как правило, мы разрешаем доступ только абсолютно необходимого трафика в VLAN — если разрешить весь трафик, тогда теряется смысл сегментирования.
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Источник
Mikrotik и VLAN
Сразу оговорюсь, что данная статья про Router OS, а не Switch OS.
На мой взгляд, работа с VLAN в Mikrotik освещена хуже всего. Да, конечно есть набор статей на эту тему, например вот:
https://wiki.mikrotik.com/wiki/Manual:Interface/VLAN#InterVLAN_routing (за неуказание при публикации прямой ссылки на официальную доку прям словил хейта в личку)
И тому подобное. Но лично я когда их все читал. У меня не складывалось глубокого понимания, как именно это всё работает, только возможность повторить типовую конфигурацию.
То есть, эти статьи хороши, но на мой взгляд написаны для специалистов по микротикам, которым понадобилось еще и в 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».
Пятое — автоконфигурации работают несколько мимо этих механизмов. И поэтому если у вас в бридже есть порты, настроенные вручную и они наглухо не работают как надо, но при этом другие порты работают хорошо, но те настроены автоматически (туннель, капсман, прочее), то скорее всего конфигурация ошибочна и если ошибку исправить, то вручную настроенные интерфейсы заработают, а автоматически настроенные при этом не сломаются.
Шестое, в комментариях словил хейта за то, что не указал второй способ работы с этим счастьем, поэтому поправлюсь, еще можно использовать VLAN и без моста, для чего создаётся интерфейс VLAN, подключаемый напрямую к физическому порту. Тогда на физический порт пакет приходит с тэгом, потом на уровне виртуального интерфейса происходит его снятие и дальше он идёт нетегированным. Создаётся такой виртуальный порт ровно тем же путём: «Interfaces — Interface — ‘+’ — VLAN», там надо указать «VLAN id» и физический порт, на который его посадить.
И надеюсь уж последнее, раз уж мы вспомнили эту конфигурацию, то седьмое, казалось бы, никто не мешает из таких портов как в п.6, с которых уже сняты теги на уровне виртуального интерфейса, опять же собрать мост. Таким способом например можно менять тэг между портами. Но есть два «но», во-первых, комбинировать способ из первых пяти пунктов со способом из последних двух не рекомендую категорически, потому что там сам черт ногу сломит. В том смысле, что поиск возможных проблем станет совсем гиблым делом. А во-вторых, как мне подсказали в комментариях, по официальной же документации с этим есть определенные сложности.
Пример работы со всем вышеперечисленным
Итак, есть сеть, в которой микротиковая точка доступа используется просто как точка доступа. А точнее, их две и между ними реализовано бесшовное переключение средствами 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-ах во всех строчках и это правильно):
Теперь всё пингуется и можно настроить остальные вещи типа фильтрации, НАТ и прочее, но это типовые вещи, о которых можно прочитать в других местах и потому выходят за рамки этой статьи.
Источник