Немного о private vlan

    Довольно часто на форумах, и других it ресурсах, проскакивает фраза что vlan (стандарт 802.1q) не относится к безопасности, как таковой. Я в принципе с этим суждением согласен, это как динамический nat, который косвенно, но обеспечивает защиту хостов который находятся в серой сети. Да эти 2 темы как vlan так и nat рождают холивар. Но вот есть одна технология которая в большей степени относит vlan к безопасности, о ней мы и поговорим далее.

    Кому интересно приглашаю под кат.


    Private vlan, что же это такое ?


    Попробую рассказать своими словами. По сути с помощью данной технологии выполняется контроль внутри vlan-а. Контролируя broadcast домен превращая его в под домены, согласно настройкам, которые дал администратор сети. Проще говоря, есть свич, есть сеть, есть broadcast домен. Не хотим мы что бы пользователи, которые подключены в этот домен могли обращаться друг к другу. Здесь и применяется наша технология. А если смотреть со стороны самой технологии, то в домене организуются поддомены.



    Существует 2 типа вланов в данной технологии, primary, основной влан который берется за основу и представляется не private vlans, как обычный не показывающий id внутридоменных вланов, которые и относятся у второму типу вланов secondary.
    Тем самым сами secondary vlans могут быть 2-х типов: Isolated и community, ниже описаны различия этих понятий.
    Итого подытожив получим следующее.



    Promiscuous (или Uplink к примеру в allied telesyn) — режим пропускания трафика, применяется в случаях когда не нужно ограничивать доступность(тот же файловый сервер, маршрутизатор или коммутатор). Этот тип относится к primary vlans. И обменивается трафиком как с изолированными, так и как сказано выше с вланами не использующие технологию pvlan.

    Isolated — как раз порт который находится в изолированном состоянии т.е. находится в своем под домене, и не имеет доступ к другим изолированным под доменам, так же как и к нему. Видит он только порты которые находится в promiscuous состоянии, применяется когда хост в сети требует к себе особой безопасности.

    Community – деление на под домены не один порт, а несколько портов в отдельном домене. Другими словами, хосты в этом домене видят как своих соседей по под домену, так и хосты в promiscuous состоянии, применимо, когда изоляцию делаем, к примеру, по отделу.

    Я больше опирался на понятия корпорации cisco, чем других. Так что в понятиях есть различия, но они схожи с понятиями cisco, и вы при знакомством с технологией от другого вендора думаю поймете, что и как.

    О Применении.

    Скажу что бы внедрить данную технологию в сеть нужно учитывать, такие параметры, что pvlan не поддерживает многие другие технологии, к примеру vtp rsapn, voice vlan и т.д…

    Технология довольно интересная, на мой взгляд, и если вы не найдете применения ей в своей сети, думаю кто не сталкивался с этим понятием будет интересно познакомиться с легким описанием данной технологии.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 36

      +1
      И через trunk порт можно пропустить только primary vlan т.е. по сути технология живет на отдельно взятом коммутаторе.
      эм… trunk порт и pvlan не связные вещи как бы… А касательно вашей фразы, то всё наоборот: trunk порт не может быть объявлен promiscuous портом.
        0
        спасибо! оговорился, исправил.
          +1
          Всё не то.

          Главное, что хочет индустрия: возможности устройствам, находящимся в одной сети (L3 network) иметь возможность работать посредством только L3, то есть чтобы они не видели L2 трафик друг друга, но могли обращаться по IP.

          Я не видел промышленных систем, которые могли бы делать такое.
            0
            ну такое не возможно. по крайней мере по существующей модели osi. И если и будет возможно, то только в не близком будущем.
              +1
              У меня есть пара идей как это сделать — маршрутизатор должен отвечать на who has своим MAC'ом на все активные IP в его сетевом сегменте и дальше работать с пакетом как при обычной маршрутизации. В этом случае private vlan позволит изолировать клиентов на L2, а L3 будет обрабатываться машрутизатором, даже в одном сетевом сегменте.

              PS У меня начинается когнитивный диссонанс из-за ников.
                0
                Щас amario еще и аватарку такую же поставит ;)
                  0
                  Я вот случайно увидел этот комментарий и вспомнил, что именно такое делает accel-ppp в схеме с ipoe на QinQ. Там каждый пользователь в отдельном VLAN-е, навешивается ip unnumbered и proxyarp.
                    0
                    И опять же случайно нашёл: похоже, такая же схема реализовывается в Extreme Summit с помощью PVLAN + configure iparp add proxy. Есть в Concepts Guide.
                0
                а чем Вам не хватает возможностей PVLAN? isolated — и вперед…
                  0
                  Не хватает.
                    0
                    очень емкий и информативный ответ
                      0
                      Как узлам между друг другом по L3 ходить?
                        0
                        написать маршрут через gateway
                          0
                          С какой стати узел будет отправлять трафик соседу по сети на шлюз?

                          Сколько я с людьми, которые про PVLAN'ы не говорил, практически никто из них не понимает, чем «сосед по сети» отличается от «другой сети в том же канальном сегменте». Проблема не сетями, проблема в изоляции клиентов одной сети. По спекам они должны на L2 взаимодействовать, а нам этого не хочется. В этом и есть главная драма.
                            0
                            если напишете маршрут к своей подсети с большей маской через шлюз (например, для подсети с /24 два маршрута с /25) — трафик будет ходить через шлюз.
                              0
                              Чушь говорите. Direct connected networks отправляются локально.

                              Вот про эту проблему я и говорил — как начнёшь с человеком говорить, выясняется, что он основ IP-машрутизации не знает.
                                +1
                                локальная таблица маршрутизации ничем не хуже любой другой. если маршрут будет с большей маской — он выиграет у directly-connected.

                                И, amarao, полегче, Вы не в колхозе лекции по квантовой физике читаете.
                                  0
                                  Упс. Спасибо. Я был не прав, узкий машрут выигрывает даже если он directly connected.

                                  Ок, теперь говорю более развёрнуто.

                                  Мы не можем принудить клиентские машины ходить на шлюз вместо arp-запроса к соседу без прописывания ему пачки таблиц маршрутизации. А власти над клиентскими машинами мы не имеем.

                                  Далее: я не знаю (это интересно, так что я проверю это завтра), будет ли маршрутизатор маршрутизировать трафик в ту же сеть, из которой принял пакет (не физический интерфейс, а именно сеть).

                                  Хотя идея внезапно стала интересной…
                                    0
                                    начну с конца: кошка — да, будет. на антициске тут недавно даже жалоба на это в форуме. За остальные не поручусь. Только icmp redirect отключить для спокойствия.

                                    про клиентские машины — понял, тут пока в голову ничего не приходит.

                                    Рад, что пришли к конценсусу.
                                      0
                                      Спасибо большое, я пишу пока идею в трекер, я буду над ней сильно думать.

                                      Потому что это вполне себе решение для EVG (IEEE 802.1Qbg), позволяющее избавить машины от чуждого им трафика полностью и окончательно.
                                      0
                                      А власти над клиентскими машинами мы не имеем.
                                      А по dhcp, роуты кинуть на тачки есть возможность?
                                        0
                                        Нет, статика.

                                        Да и «власть» я имел в виду другого плана — клиенты вольны делать в своих машинах что угодно, пока это не направлено на помехи окружающим.
                              0
                              Можно даже элегантнее — local proxy arp:
                              «The local proxy ARP feature allows the Multilayer Switching Feature Card (MSFC) to respond to ARP requests for IP addresses within a subnet where normally no routing is required. With the local proxy ARP feature enabled, the MSFC responds to all ARP requests for IP addresses within the subnet and forwards all traffic between hosts in the subnet.»
                              0
                              Влан на юзера? Одна L3 сеть нужной ширины на лупбеке + ip-unnumbered + proxy arp, если хостам надо общаться между собой?
                              Навроде вот этого www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html
                        0
                        Не знаю что у вас за индустрия, и на какие промышленные системы вы смотрели, но подобный функционал у нас реализован с помощью ip unnumbered на Cisco.

                        www.opennet.ru/base/cisco/catalyst_ip_unnumber.txt.html
                          0
                          Я правильно понял, что это решение требует отдельный VLAN на каждого пользователя?
                            0
                            Да. Ибо, 3-ий уровень. Ну… или каждому клиенту по порту на маршрутизаторе (не l3 коммутатор).
                              0
                              Так неинтересно :) А уж поддерживать это дело вообще напряг, если не использовать какие-нибудь средства автоматизации.
                              Local Proxy ARP выглядит интереснее.
                                0
                                Это решение используется у операторов, а у них практикуется автоматизация на unix-like системах, в частности фряху любят.
                        0
                        ну вот этот самый момент как заставить роутер одним маком для всего сетевого сегмента.
                        а так pvlan практически та самая схема.

                        ps сам путаюсь с никами, но так уж получилось, я сам забил свой ник на хабре но потом оказалось что инфайт перестал жить :). при следущей регистрации уже нельзя было выбрать ник. в любом случае он не сильно отличался от amario т.е. mario но уже было бы намного просче в различии.
                          0
                          Блин, статья интересная, но из-за бесконечных «ться» читать невозможно. Я не граммар-нацци, но это реально бесит.
                            0
                            Исправил. Извините, но с русским у меня действительно не сильно хорошо.
                              0
                              Спасибо, теперь с удовольствием прочту)
                            0
                            И через trunk порт нельзя нельзя пропустить pvlan. т.е. по сути технология живет на отдельно взятом коммутаторе.
                            Для ознакомления — www.cisco.com/en/US/tech/tk389/tk814/technologies_configuration_example09186a008017acad.shtml#multiple_switch
                              0
                              В JunOS можно размазать на несколько коммутаторов начиная с 10.4
                                0
                                Убрал… Это утверждение родилось у меня в связи с тем, что оборудование Allied telesis, не умеет через транк работать. А я с этой технологией как раз, больше, на их оборудовании работал.

                              Only users with full accounts can post comments. Log in, please.