В данной статье рассмотрим такую интересную, на мой взгляд, технологию, как Private VLANs в теории и практике.
Для начала вспомним, что такое VLANы. VLAN – отдельная подсеть, отдельный домен бродкаста, используется для логической сегментации сети, ограничения домена широковещательной рассылки, безопасности и т.д.
Обычно сеть делится на VLANы, далее c помощью router-on-the-stick либо многоуровнего свича (любого устройства 3 уровня) включается маршрутизация (разрешается весь трафик), а потом, с помощью списков контроля доступа, прописывается кому, с кем и по какому протоколу разрешено “общаться” (или применяется контроль трафика исходя из требований политики безопасности вашей организации, как было бы написано в учебнике Cisco).
Но что же делать когда, например, сеть уже разделена, сегментирована, но возникла необходимость изолировать серверы либо группы хостов друг от друга?
У Cisco, как и других вендоров, есть дополнительные инструменты, помогающие ограничивать пересылку трафика между хостами, находящимися в пределах одной подсети или контроля трафика внутри VLAN. Для этого чаще всего используются Private VLANs (частные VLANы), VLAN access list и protected ports.
Следует отметить, что Private VLANы на Cisco поддерживаются на моделях Nexus, а так же Catalyst начиная с 3560 и старше.
На свичах младших моделей есть такое понятие как private vlan edge. Настраивается очень просто – из режима конфигурации интерфейса прописываем команду (config-if)#switchport protected, в результате чего, хосты подключенные к этим портам буду изолированы друг от друга на 2 уровне (т.е. физически они будут подключены к одному свичу, находиться в одной подсети, но не будут “видеть” друг друга, при этом будут “видеть” все остальные хосты). Один из недостатков этого механизма, это то, что он имеет локальное значение для свича, и не масштабируется.( т.е. если мы соединим свич А и свич В транком, например, то protected порт свича А сможет “увидеть” protected порт свича B).
Остановимся более подробнее на частных VLANах. Основная цель статьи – научить настраивать частные VLANы, разобраться с терминологией, а так же получить общее представление, где их использовать.
В первом примере, сеть уже разбита на VLANы, но вдруг потребовалась изоляция хостов, что делать? Вы скажете, что всё очень просто: выносим хосты, которые требуется изолировать в отдельные VLANы, включаем маршрутизацию, с помощью списков контроля доступа изолируем их друг от друга. Для этого просто создаем еще несколько подсетей и всё. Но, вдруг вы работаете в организации, где очень строгая иерархия IP-адресации и просто получить еще одну частную подсеть не так легко либо у вас нет свободных VLANов?
Рис. – Изоляция серверов в DMZ.
Вы работаете в провайдере и предоставляете услуги web-хостинга для большого количества клиентов, вы поместили веб-серверы в одну сеть, при этом получается, что нет никакой изоляции, все они могут “слышать” броадкасты друг друга, т.е. передавать трафик без фильтрации через межсетевой экран. Если хакер сможет попасть на один из серверов, то он сможет развернуть атаку на все серверы, ”положить” всю серверную ферму. И, конечно же, клиенты хотят изоляции своих серверов друг от друга. Особенно PVLANы актуальны для провайдеров, предоставляющих layer 2 подключения как вид услуги, для разделения клиентов, клиент А конечно же не захочет, что бы его широковещательная рассылка попадала к клиенту Б, сами понимаете, какая дыра в безопасности здесь открывается. Традиционный выход из положения методом добавления нового VLANа здесь не подойдет (метод один VLAN на клиента), “упираемся” в масштабируемость максимальное количество VLANов 4094 минус зарезервированные. Вторая проблема, т.к. VLAN – отдельная подсеть, нужно заниматься subnetting и откидывать еще по 2 адреса на каждую подсеть (subnet и broadcast) жалко, так как это “белые” адреса :).
В данных ситуациях на помощь приходят частные VLANы.
Немного терминологии. Частные VLANы делятся на:
Порты делятся на:
Только один isolated vlan может быть привязан к одному promiscuous порту. Если хотите несколько isolated vlan, тогда к каждому vlan должен быть привязан отдельный promiscuous порт.
Обычно создается только один isolated vlan, не важно, сколько там хостов, все равно они не будут видеть друг друга.
В отличие от isolated VLAN, несколько community VLAN может быть привязано к одному promiscuous порту.
Рассмотрим следующую топологию:
— Все устройства находятся в одной подсети 10.0.0.0/24 VLAN 10.
— R4 и R5 должны быть изолированы друг от друга и R2, R3 – т.е. должны иметь доступ только к интерфейсу маршрутизатора.
— R2 и R3 должны быть изолированы от R4, R5, но видеть друг друга и маршрутизатор.
Сперва создадим 2 второстепенных VLANа, 101 community VLAN и 102 isolated VLAN. VLAN 10 сделаем основной и привяжем к ней второстепенные( порядок ввода команд не имеет значения).
Проверим:
Далее, мы должны ассоциировать порты c VLANами.
Из режима конфигурации интерфейса делаем его сначала private vlan host (говорим ему, что он необычный порт), второй командой привязываем его к isolated и primary VLANам
По аналогии настраиваем интерфейс fa1/0/4
То же самое прописываем на fa1/0/9 – сначала говорим ему, что он private vlan host и для того, что бы он понял, что он принадлежит community vlan 102, привязываем его к ней, а так же не забываем привязать его к основному VLANу.
Аналогично настраиваем fa1/0/9
Интерфейсу fa2/0/2, так как мы хотим, что бы все хосты его “видели” и он всех “видел”, задаем режим promiscuous и по правилу привязываем его к основному и всем второстепенным VLANам.
Проверяем ассоциацию портов:
Следующее действие не обязательное, создаем L3 SVI, для проверки, что isolated и community хосты могут его “видеть” так же, как и promiscuous port.
И теперь самое интересное – как это все работает.
Взглянем на таблицу MAC-адресов на свиче, выглядит она необычно. Оказывается, MAC-адреса хостов на портах, с которых они были получены, одновременно ассоциируются с основным и второстепенным VLANами!
Почему хосты R4 и R5 в isolated vlan 102 не могут ничего “видеть” кроме интерфейса маршрутизатора? Обратите внимание, что MAC-адреса этих хостов в пределах 102 isolated vlan свич пометил, как BLOCKED, в то же время MAC-адрес promiscuous интерфейса маршрутизатора в пределах vlan 102, как обычный DYNAMIC.
Теперь давайте посмотрим, почему интерфейс маршрутизатора, помеченный, как promiscuous может “общаться” со всеми интерфейсами, дело в том, что он их может видеть через primary VLAN 10 (первые 5 строчек в таблице MAC-адресов).
В следующей статье рассмотрим тонкости масштабируемости частных VLANов, как между свичами поддерживающими эту технологию, так и на / через обычные свичи, которые даже и не знают такого понятия, как частный VLAN (нет, нет никакого двойного тегирования фрэйма) и типы “специальных” транков.
Для начала вспомним, что такое VLANы. VLAN – отдельная подсеть, отдельный домен бродкаста, используется для логической сегментации сети, ограничения домена широковещательной рассылки, безопасности и т.д.
Обычно сеть делится на VLANы, далее c помощью router-on-the-stick либо многоуровнего свича (любого устройства 3 уровня) включается маршрутизация (разрешается весь трафик), а потом, с помощью списков контроля доступа, прописывается кому, с кем и по какому протоколу разрешено “общаться” (или применяется контроль трафика исходя из требований политики безопасности вашей организации, как было бы написано в учебнике Cisco).
Но что же делать когда, например, сеть уже разделена, сегментирована, но возникла необходимость изолировать серверы либо группы хостов друг от друга?
У Cisco, как и других вендоров, есть дополнительные инструменты, помогающие ограничивать пересылку трафика между хостами, находящимися в пределах одной подсети или контроля трафика внутри VLAN. Для этого чаще всего используются Private VLANs (частные VLANы), VLAN access list и protected ports.
Следует отметить, что Private VLANы на Cisco поддерживаются на моделях Nexus, а так же Catalyst начиная с 3560 и старше.
Первый пример.
На свичах младших моделей есть такое понятие как private vlan edge. Настраивается очень просто – из режима конфигурации интерфейса прописываем команду (config-if)#switchport protected, в результате чего, хосты подключенные к этим портам буду изолированы друг от друга на 2 уровне (т.е. физически они будут подключены к одному свичу, находиться в одной подсети, но не будут “видеть” друг друга, при этом будут “видеть” все остальные хосты). Один из недостатков этого механизма, это то, что он имеет локальное значение для свича, и не масштабируется.( т.е. если мы соединим свич А и свич В транком, например, то protected порт свича А сможет “увидеть” protected порт свича B).
Остановимся более подробнее на частных VLANах. Основная цель статьи – научить настраивать частные VLANы, разобраться с терминологией, а так же получить общее представление, где их использовать.
Второй пример.
В первом примере, сеть уже разбита на VLANы, но вдруг потребовалась изоляция хостов, что делать? Вы скажете, что всё очень просто: выносим хосты, которые требуется изолировать в отдельные VLANы, включаем маршрутизацию, с помощью списков контроля доступа изолируем их друг от друга. Для этого просто создаем еще несколько подсетей и всё. Но, вдруг вы работаете в организации, где очень строгая иерархия IP-адресации и просто получить еще одну частную подсеть не так легко либо у вас нет свободных VLANов?
| VLAN Support Matrix for Catalyst Swithes | ||
| Type of Switch | Maximum No. of VLANs | VLAN IDs Range |
| Catalyst 2940 | 4 | 1-1005 |
| Catalyst 2960 / 2955 | 250 | 1-4094. |
| Catalyst 2960 | 255 | 1-4094. |
| Catalyst 2970/2550/3560/3750 | 1005 | 1-4094. |
| Catalyst 2848G/2980G/4000/4500 | 4094 | 1-4094. |
| Catalyst 6500 | 4094 | 1-4094. |
Рис. – Изоляция серверов в DMZ.
Третий пример.
Вы работаете в провайдере и предоставляете услуги web-хостинга для большого количества клиентов, вы поместили веб-серверы в одну сеть, при этом получается, что нет никакой изоляции, все они могут “слышать” броадкасты друг друга, т.е. передавать трафик без фильтрации через межсетевой экран. Если хакер сможет попасть на один из серверов, то он сможет развернуть атаку на все серверы, ”положить” всю серверную ферму. И, конечно же, клиенты хотят изоляции своих серверов друг от друга. Особенно PVLANы актуальны для провайдеров, предоставляющих layer 2 подключения как вид услуги, для разделения клиентов, клиент А конечно же не захочет, что бы его широковещательная рассылка попадала к клиенту Б, сами понимаете, какая дыра в безопасности здесь открывается. Традиционный выход из положения методом добавления нового VLANа здесь не подойдет (метод один VLAN на клиента), “упираемся” в масштабируемость максимальное количество VLANов 4094 минус зарезервированные. Вторая проблема, т.к. VLAN – отдельная подсеть, нужно заниматься subnetting и откидывать еще по 2 адреса на каждую подсеть (subnet и broadcast) жалко, так как это “белые” адреса :).
В данных ситуациях на помощь приходят частные VLANы.
Немного терминологии. Частные VLANы делятся на:
- Primary – основная, главная VLAN
- Secondary – второстепенные VLANы (бывают 2 видов isolated и community), все они должны принадлежать primary VLAN
Порты делятся на:
- Promiscuous – этот порт “видят” все и он “видит” всех, должен быть привязан к основному и всем второстепенным VLANам.
- Private vlan host может принадлежать:
- Isolated VLAN- “видит” только promiscuous порт, не “видит” другие порты даже в своей isolated vlan. Должен быть привязан к своему isolated VLANу и primary VLANу
- Community VLAN- “видит” только порты в данной community vlan, которой он принадлежит и promiscuous порт. Должен быть привязан к своему community VLANу и primary VLANу.
Общие правила
Только один isolated vlan может быть привязан к одному promiscuous порту. Если хотите несколько isolated vlan, тогда к каждому vlan должен быть привязан отдельный promiscuous порт.
Обычно создается только один isolated vlan, не важно, сколько там хостов, все равно они не будут видеть друг друга.
В отличие от isolated VLAN, несколько community VLAN может быть привязано к одному promiscuous порту.
Рассмотрим следующую топологию:
— Все устройства находятся в одной подсети 10.0.0.0/24 VLAN 10.
— R4 и R5 должны быть изолированы друг от друга и R2, R3 – т.е. должны иметь доступ только к интерфейсу маршрутизатора.
— R2 и R3 должны быть изолированы от R4, R5, но видеть друг друга и маршрутизатор.
Сперва создадим 2 второстепенных VLANа, 101 community VLAN и 102 isolated VLAN. VLAN 10 сделаем основной и привяжем к ней второстепенные( порядок ввода команд не имеет значения).
SW1 (config)#
vlan 101
private-vlan community
!
vlan 102
private-vlan isolated
!
vlan 10
private-vlan primary
private-vlan association 101-102
Проверим:
SW1#sh vlan private-vlan
Primary Secondary Type Ports
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
10 101 community
10 102 isolated
Далее, мы должны ассоциировать порты c VLANами.
Из режима конфигурации интерфейса делаем его сначала private vlan host (говорим ему, что он необычный порт), второй командой привязываем его к isolated и primary VLANам
interface FastEthernet1/0/11
description SW1 <-> R2
switchport private-vlan host-association 10 101
switchport mode private-vlan host
spanning-tree portfast
end
По аналогии настраиваем интерфейс fa1/0/4
interface FastEthernet1/0/4
description SW1 <-> R3
switchport private-vlan host-association 10 101
switchport mode private-vlan host
spanning-tree portfast
end
То же самое прописываем на fa1/0/9 – сначала говорим ему, что он private vlan host и для того, что бы он понял, что он принадлежит community vlan 102, привязываем его к ней, а так же не забываем привязать его к основному VLANу.
interface FastEthernet2/0/2
description SW1 <-> R6
switchport private-vlan mapping 10 101-102
switchport mode private-vlan promiscuous
Аналогично настраиваем fa1/0/9
interface FastEthernet2/0/11
description SW1 <-> R5
switchport private-vlan host-association 10 102
switchport mode private-vlan host
spanning-tree portfast
Интерфейсу fa2/0/2, так как мы хотим, что бы все хосты его “видели” и он всех “видел”, задаем режим promiscuous и по правилу привязываем его к основному и всем второстепенным VLANам.
interface FastEthernet2/0/2
description SW1 <-> R6
switchport private-vlan mapping 10 101-102
switchport mode private-vlan promiscuous
Проверяем ассоциацию портов:
SW1#sh vlan private-vlan
Primary Secondary Type Ports
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
10 101 community Fa1/0/4, Fa1/0/11, Fa2/0/2
10 102 isolated Fa1/0/9, Fa2/0/2, Fa2/0/11
Следующее действие не обязательное, создаем L3 SVI, для проверки, что isolated и community хосты могут его “видеть” так же, как и promiscuous port.
SW#sh run int vlan 10 | beg int
interface Vlan10
ip address 10.0.0.1 255.255.255.0
private-vlan mapping 101-102
end
SW#sh int vlan 10 private-vlan mapping
Interface Secondary VLANs
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
vlan 10 101,102
SW1#
И теперь самое интересное – как это все работает.
Взглянем на таблицу MAC-адресов на свиче, выглядит она необычно. Оказывается, MAC-адреса хостов на портах, с которых они были получены, одновременно ассоциируются с основным и второстепенным VLANами!
Почему хосты R4 и R5 в isolated vlan 102 не могут ничего “видеть” кроме интерфейса маршрутизатора? Обратите внимание, что MAC-адреса этих хостов в пределах 102 isolated vlan свич пометил, как BLOCKED, в то же время MAC-адрес promiscuous интерфейса маршрутизатора в пределах vlan 102, как обычный DYNAMIC.
Теперь давайте посмотрим, почему интерфейс маршрутизатора, помеченный, как promiscuous может “общаться” со всеми интерфейсами, дело в том, что он их может видеть через primary VLAN 10 (первые 5 строчек в таблице MAC-адресов).
SW#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.0.2 8 0014.a925.72a0 ARPA Vlan10 pv 101
Internet 10.0.0.3 5 0014.a925.4cd8 ARPA Vlan10 pv 101
Internet 10.0.0.1 - 0014.a98c.87c1 ARPA Vlan10
Internet 10.0.0.6 70 0014.a909.78d1 ARPA Vlan10
Internet 10.0.0.4 4 0014.a909.7870 ARPA Vlan10 pv 102
Internet 10.0.0.5 4 0014.a925.6460 ARPA Vlan10 pv 102
SW#sh mac-address-table
Mac Address Table
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Vlan Mac Address Type Ports
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
All 0100.0ccc.cccc STATIC CPU
....
10 0014.a909.7870 DYNAMIC pv Fa1/0/9
10 0014.a909.78d1 DYNAMIC Fa2/0/2
10 0014.a925.4cd8 DYNAMIC pv Fa1/0/4
10 0014.a925.6460 DYNAMIC pv Fa2/0/11
10 0014.a925.72a0 DYNAMIC pv Fa1/0/11
101 0014.a909.78d1 DYNAMIC pv Fa2/0/2
101 0014.a925.4cd8 DYNAMIC Fa1/0/4
101 0014.a925.72a0 DYNAMIC Fa1/0/11
102 0014.a909.7870 BLOCKED Fa1/0/9
102 0014.a909.78d1 DYNAMIC pv Fa2/0/2
102 0014.a925.6460 BLOCKED Fa2/0/11
SW1#
В следующей статье рассмотрим тонкости масштабируемости частных VLANов, как между свичами поддерживающими эту технологию, так и на / через обычные свичи, которые даже и не знают такого понятия, как частный VLAN (нет, нет никакого двойного тегирования фрэйма) и типы “специальных” транков.
