2.1. Краткое введение в технологию VLAN

Что есть VLAN? Virtual LAN, некоторое средство логического деления сети на части. Основная идея заключается в том, чтобы выделить некую часть сети в независимую группу. В современной практике очень часто применяются для разделения доступа к той или иной части сети. Среди людей занимающихся администрированием ЛВС встречаются люди, считающие, что выделенные в VLAN сегменты сети полностью отделены друг от друга, чуть ли не на физическом уровне. Так ли это? Давайте посмотрим. Во первых, какие бывают VLAN'ы: VLAN'ы бывают MAC-based, port based и "тегированные" (определяются стандартом [4]).

MAC based VLAN -- это группа рабочих станций, объединенных на основе физических адресов их сетевых адаптеров, в случае Ethernet - на основе MAC-адреса Ethernet адаптера компьютера (адреса его NIC).

Port based VLAN'ы -- это VLAN'ы, создаваемые из портов коммутатора путем объединения их в группы.

Наконец, 802.1q VLAN'ы (dot 1 q), или tag-based VLAN'ы появляются в средах передачи данных с модифицированными фреймами. Модификатор фрейма представляет собой некоторую добавку к стандартному типу фрейма. Согласно содержимому этой "добавки" устройство, обслуживающее сеть, может разделять трафик, в том числе по параметру "VLAN ID". В типичном случае, такие VLAN "ходят" внутри транковых (тегированных) каналов, или, перефразируя, между тегируемыми интерфейсами. В терминологии Cisco Systems такой порт называется "транковым" (trunk).

Особенности .1q VLANов:

• Существует некий default VLAN, тег которого определяет его VLAN id=0.
• Могут одновременно существовать нетегируемые и тегируемые порты, и те и другие могут иметь при этом членство в неких VLAN.
• При входе в не тегируемый порт, являющийся членом VLAN отличного от default, трафик "оборачивается" в некий внутренний формат, позволяющий определить какому VLAN принадлежит этот пакет.
• VLAN'ы могут соединяться между собой через нетегируемые порты. Например, порт 1 и порт 2 состоят в vlan1 и vlan2 соответственно, при этом они нетегируемые (не-транковые). Так вот, если соединить эти порты самым обычным кроссом получится объединение vlan1 и vlan2, при этом на линке в момент прохода пакта между этими портами происходит конвертация номеров VLAN, то есть трафик из порта 1 в порт 2 с VLAN ID =1 выходит из порта 1 уже с vlan id 0 (default, идентично "не обернутому" трафику), а в порту 2 оборачивается и получает VLAN ID=2. При этом, по формату фреймов, вошедших в порт 2 из порта 1 уже никак не понять, что они были когда-то в vlan1.

С точки зрения функционирования некоторого моста, сеть, в которой появляются VLAN, должна обслуживаться с иной таблицей коммутации, чем та, которая применяется для сети без VLAN. В сетях с использованием VLAN появляется еще один параметр в таблице коммутации - VLAN id и правила коммутации привязываются к этому параметру так, чтобы коммутация фреймов могла происходить только между портами, являющимися членами одной и той же VLAN. В случае, если часть портов коммутатора в одном VLAN'е, а другая часть - в другом VLAN, то тогда, с точки зрения нормального функционирования сети, можно рассматривать эту ситуацию как два независимых коммутатора. Это утверждение действительно справедливо для пользовательского трафика, однако оно не совсем верно для ситуации с STP и BPDU, обеспечивающих функциональность, требуемую алгоритмом Spanning Tree.

2.2. Миф о раздельном дереве STP в каждом VLAN

Прежде всего, следует заострить внимание на функционировании STP в системах с поддержкой VLAN. При этом надо отметить, что наиболее "продвинутые" устройства, поддерживающие VLAN (но не все), поддерживают отдельное STP дерево на каждый VLAN. Таким образом все STP атаки на такие устройства, на первый взгляд, будут эффективны только в пределах данного VLAN (по поводу VLAN см. [4]). C точки зрения STP внутри vlan мы имеем стандартную схему функционирования портов - каждый порт, согласно протоколу, получает и отправляет BPDU и, в зависимости от их содержимого, изменяет свое состояние.

Тем не менее, часть устройств, поддерживающих VLAN, имеет единственное Spanning Tree дерево на весь коммутатор (например,модели Intel 460T), что делает всю сеть, построенную на таких устройствах, уязвимой ко всем STP атакам.

С точки зрения обсуждаемых проблем, устройства второго типа с единственным на все устройство STP-деревом по части функционирования STP атак ничем не отличаются от рассматриваемого ниже случая без поддержки VLAN, так что мы не будем рассматривать отдельно этот вариант. Со вторым типом устройств, поддерживающих собственное STP-дерево на каждый VLAN, дела обстоят немного по-другому. Чтобы подойти поближе к заголовку этой главы, давайте обсудим пару практических примеров, которые могут встретиться в нормальной (рабочей) ситуации, а также к тому, как коммутатор может обеспечить работу именно по такому варианту.

2.3. Миф о физической раздельности VLAN'ов

Итак, как уже указывалось ранее, port based VLAN'ы можно объединить, просто воткнув патч-корд в соседние порты, подключенные в разные VLAN. После того, как это произойдет, порты, объединенные в VLAN'ы, с точки зрения коммутатора по-прежнему будут состоять в разных VLAN - до тех пор, пока не используется GVRP (см. раздел 10), принадлежность порта тому или иному vlan определяется исключительно администратором (и правилом по умолчанию, если администратор не соизволил определить данный порт в тот или иной VLAN). Однако для корректного функционирования STP описанная ситуация должна отслеживаться особенным образом, то есть, с точки зрения STP, если два изначально "независимых" дерева вдруг соединились, то появился повод для STP-выборов. Действительно, аналогичная ситуация возникала на практике и алгоритм STP срабатывал. С учетом возможности конвертации VLAN ID становится понятно, что на самом деле независимость STP дерева в пределах VLAN -- это миф. Возникает идея: что если сгенерировать STP BPDU с параметрами, аналогичными тем BPDU, которые распространяются в соседнем VLAN, можно заставить STP устройство устроить перевыборы с участием интерфейса, находящегося в соседнем VLAN. Правда есть еще один вариант передачи BPDU, который позволил бы отслеживать ситуацию с VLAN соединенными, через нетегируемый порт, а именно - передавать BPDU всегда в тегируемом фрейме и игнорировать нетегируемые порты.

На момент написания этой главы авторы еще не завершили исследование стандарта [4], так что описание используемой в большинстве устройств реализации "отдельного" STP дерева на каждый VLAN пока за рамками данного исследования и будет включено лишь через некоторое, надеемся, небольшое время

Этот и предыдущий подразделы требуют существенной доработки.

Впрочем, с точки зрения возможных атак на STP дерево соседнего VLAN, нет принципиальной разницы в каком фрейме передаются STP пакеты, поскольку генерация тегированных фреймов не составляет проблемы и давно реализована во многих UNIX-подобных ОС. Например в OpenBSD поддержка VLAN идет "из коробки". Разумеется поддержка VLAN есть и для Linux, однако в некоторых дистрибутивах она потребует установки "заплатки" (patch) на ядро.