VLAN на одного абонента

[Bushi]

Почитав форум, я увидел бытующее мнение, что при построении сети по технологии Ethernet идеальный вариант для безопасности и управления - каждого абонента запихать в отдельный VLAN (внутри такой виртуальной сети находятся всего два интерфейса - интерфейс клиента и интерфейс маршрутизатора провайлера.

 

Не буду вспоминать ограничения 802.1q в 4096 vlan, спрошу, как в данном случае решать вопрос с организацией сети point-to-point? Ведь для организации такой сети на одного абонента приходится расходовать 4 ip-адреса (адрес сети, адрес маршрутизатора, адрес абонента, широковещательный адрес), когда при организации VPN-соединения достаточно и одного. Кто и как решает эту проблему?

[Shiva]

Bushi,

Кто и как решает эту проблему?

В разных VLAN'ах могут быть одинаковые IP адреса.

 

когда при организации VPN-соединения достаточно и одного

Пересчитай ещё раз, ты ошибся

[Bushi]

Bushi,

Кто и как решает эту проблему?

В разных VLAN'ах могут быть одинаковые IP адреса.

 

когда при организации VPN-соединения достаточно и одного

Пересчитай ещё раз, ты ошибся

 

До одного считать точно умею :) На NAS-сервере один local-IP адрес может испольоваться в протоколе PPP для организации всех подключений + 1 remote-IP на клиента (или пул адресов на всех).

 

Не понял про схему с одинаковыми IP-адресами, прошу пояснить.

[Shiva]

Bushi,

До одного считать точно умею :)

VPN: 1 клиенту, 1 серверу, 1 клиенту = 3

VLAN: 1 клиенту, 1 сеть, 1 броадкаст, 1 клиент = 4

И того на 1 больше

 

Не понял про схему с одинаковыми IP-адресами, прошу пояснить

Если .q VLAN всё сегментируется на 2 уровне, а IP это 3. В итоге всё идёт отдельно.

[UglyAdmin]

ИМХО, гемморроя с виланом на юзера существенно больше:

1. На каждого надо заводить VLAN. Может на цисках с её VTP это и не проблема, но на банальном D-Link'ке это утрахаться.

2. На каждого надо заводить интерфейс на маршрутизаторе.

3. Реальные адреса дать невозможно, слишком большой расход (3/4 улетит в трубу).

4. Стоимость оборудования, потребного для такого количества виланов...

 

Отсюда для себя сделал сделал вывод: при 30-50 юзераж сделать можно, но не нужно, т.к. слишком дорого для пионерии. При 200 и более юзерах сделать нужно, но невозможно по очень многим причинам, в том числе вышеприведённым.

 

Одинаковые IP можно использовать, только если виланы терминируются на разных маршрутизаторах, ну или на очень хороших маршрутизаторах с VFR.

[Guest]

Bushi' date='

Не понял про схему с одинаковыми IP-адресами, прошу пояснить

Если .q VLAN всё сегментируется на 2 уровне, а IP это 3. В итоге всё идёт отдельно.

 

А подробнее можно про эту сегментацию? Схема не понятна.

[Shiva]

Гость,

Чушь какая то. VPN - это обычно протокол PPP на канальном уровне (PPTP, PPPoE, etc).  

Чушь у тебя. Это не только канальный уровень, возможен любой уровень модели OSI.

 

А для организации PPP-линка необходимо всего два IP-адреса - один на интерфейсе клиента, один на интерфейсе сервера, причем один IP-адрес на стороне сервера может быть сразу на всех PPP-интерфейсах. Итого - 1 IP-адрес на клиента.  

А я тебе написал затраты IP адресов для соединения 2 клиентов между собой. И никто не мешает тебе светить один адрес шлюза во всех VLAN.

 

А подробнее можно про эту сегментацию? Схема не понятна.

Поиск в разделе Hardware

[olebedev]

Зачем? Достаточно завести один VLAN для всех клиентов и включить изоляцию портов средствами коммутатора, затем настроить proxy-arp и раздавать всем адреса из одной сетки.

[Reis]

Зачем? Достаточно завести один VLAN для всех клиентов и включить изоляцию портов средствами коммутатора, затем настроить proxy-arp и раздавать всем адреса из одной сетки.

 

Что за изоляция портов такая? На каких железках присутствует?

[olebedev]

Что за изоляция портов такая? На каких железках присутствует?

 

Да практически на любых на Cisco она называется protected port и отличается разной степенью интелектуальности в зависимости от размера железки. А например на D-Link носит название traffic segementation.

 

Суть исполнения в следующем, трафик между портами в одном vlan'е ограничивается в рамках коммутатора (только одного), при этом на Cisco это делается таким образом, что порты могут общаться с одним общим (uplink) и например иметь или не иметь возможность общаться между собой (зависит от железки). А на D-Link'е можно просто задать список поротов на которые может ходить трафик с конкретного порта.

 

Теперь, возвращаемся к описаному способу применения, на коммутаторе ставим настройки таким образом, чтобы порты даже в рамках одного клиентского VLAN'а не могли общаться между собой, только с uplink. Но следует помнить, что эти ограничения распространяются только на тот коммутатор на котором они настроены.

 

Ну и как говориться на закуску, легко видеть, что "мыльница" которая умеет port based VLAN тоже может быть вписана в эту схему!

[Shiva]

olebedev,

Теперь, возвращаемся к описаному способу применения, на коммутаторе ставим настройки таким образом, чтобы порты даже в рамках одного клиентского VLAN'а  

В том то и дело, если будет ещё один такой коммутатор, когда к нему по аплинку с второго коммутатора придёт пакет и уйдёт обратно (не доходя до считалки, роутера, ...), т.к. мас пользователя висит на этом же порту.

[olebedev]

В том то и дело, если будет ещё один такой коммутатор, когда к нему по аплинку с второго коммутатора придёт пакет и уйдёт обратно (не доходя до считалки, роутера, ...), т.к. мас пользователя висит на этом же порту.

 

А вот и нет, допустим даже у нас уровней больше одного, например 3, тогда мы имеем:

router-switch1.1-switch2.1-switch3.1

              |-switch2.2-switch3.2

На всех коммутаторах switchX.Y включен режим изоляции портов и поэтому пакеты идут исключительно "вверх" к роутеру, за счет proxy-arp. А попасть с switch2.1 на switch2.2 они не могут, так как порты в которые включены эти коммутаторы могут общаться только с портом роутера, но не между собой.

[Shiva]

olebedev,

Ситуация такая

router - switch#1 - switch#2

                   |      |

              client#1   client#2

В этом случае пакету между двумя пользователями могут по теории ходить через switch#1, надо проверять на каждой железке...

[olebedev]

olebedev,

Ситуация такая

router - switch#1 - switch#2

                   |      |

              client#1   client#2

В этом случае пакету между двумя пользователями могут по теории ходить через switch#1, надо проверять на каждой железке...

 

Если на switch#2 и на switch#1 включена изоляция портов, то не будут, особенно учитывая тот факт, что MAC'и client#1 и client#2 будут находиться на одном порту switch#1 том самом которым он включен в switch#2.

[Nag]

Ситуация такая

router - switch#1 - switch#2

             |               |

              client#1   client#2

будут, особенно учитывая тот факт, что MAC'и client#1 и client#2 будут находиться на одном порту switch#1 том самом которым он включен в switch#2.

 

Надо схему подправить.

Изоляция портов не спасет если клиенты на разных коммутаторах.

 

Тут или засовывать коммутаторы в разные тегированные виланы (рабочий вариант), либо иметь "выше" коммутатор делящий все на виланы.

[Shiva]

olebedev,

Если на switch#2 и на switch#1 включена изоляция портов, то не будут, особенно учитывая тот факт, что MAC'и client#1 и client#2 будут находиться на одном порту switch#1 том самом которым он включен в switch#2.

Не верю я китайцам... Пока не увижу :) Главное что это возможно и нет гарантии что в следующей ривизии это не появится. На этом основывать свою сеть я бы категорически не стал...

[olebedev]

Не верю я китайцам... Пока не увижу :) Главное что это возможно и нет гарантии что в следующей ривизии это не появится. На этом основывать свою сеть я бы категорически не стал...

А при чем здесь вера китайцам? Это поведение описаное в документации на коммутатор и активно продвигаемое и эксплуатируемое. Ну, а если хотите уверености, то кто Вас заставляет на "мыльницах" делать, берите Cisco и делайте на них ;-))

[olebedev]

Надо схему подправить.

Изоляция портов не спасет если клиенты на разных коммутаторах.

 

Тут или засовывать коммутаторы в разные тегированные виланы (рабочий вариант), либо иметь "выше" коммутатор делящий все на виланы.

 

Даже если клиенты в разных коммутаторах, но коммутатор в котором они сходятся тоже с изоляцией портов то схема будет все равно работать. Конечно, если они сходятся в коммутаторе без изоляции портов, то они смогут общаться в обход роутера.

[Nag]

Даже если клиенты в разных коммутаторах, но коммутатор в котором они сходятся тоже с изоляцией портов то схема будет все равно работать. Конечно, если они сходятся в коммутаторе без изоляции портов, то они смогут общаться в обход роутера.

 

В теории да - есть правда куча китайских реализаций где это не так. ;-)

Или вообще изоляция только арпы режет... Но это не так и важно...

 

Скажем, такие проблемы.

1. Требования к топологии ужесточается, скорее всего никаких колец (если это просто портовые виланы) а не внутри виланов как на сисках и нортелях.

2. Не понятны вопросы безопасности (я плохо представляю устойчивость системы к тому же арп-спуфингу), или к простому получению трафика соседа с подделкой МАКа.

3. Невозможность без плясок с бубном передача данных (и даже сообщений) между соседями. Иногда возникают забавные казусы.

 

В общем - на мой взгляд технология ОЧЕНЬ ограниченного применения. ;-) Совсем забывать нельзя, но и надеяться не стоит...

[olebedev]

В теории да - есть правда куча китайских реализаций где это не так. ;-)

Или вообще изоляция только арпы режет... Но это не так и важно...

Рассматриваются варианты, только которые режут все. Например тот же D-Link именно так и делает

Скажем, такие проблемы.

1. Требования к топологии ужесточается, скорее всего никаких колец (если это просто портовые виланы) а не внутри виланов как на сисках и нортелях.

Я не предлагаю строить всю сеть на "мыльницах", только самый нижний уровень агрегирования и то выборочно, а дальше эта мыльница включается уже в нормальный (Cisco/Nortel) или приличный (D-Link/Planet) свич с поддержкой нормальных VLAN'ов

2. Не понятны вопросы безопасности (я плохо представляю устойчивость системы к тому же арп-спуфингу), или к простому получению трафика соседа с подделкой МАКа.

Да с подделкой MAK'а тут не поборешься, но вот узнать этот самый МАК почти невозможно (только ногами и посмотреть), весь обмен идет через MAK роутера в proxy-arp

3. Невозможность без плясок с бубном передача данных (и даже сообщений) между соседями. Иногда возникают забавные казусы.

Proxy-arp решает, но скорость будет не очень высокая, за то все на 100% контролируемо

[Bushi]

Хм... Вот и выходит, что со схемой изоляции портов идеальнее всего использовать PPPoE. За что боролись, на то и напоролись. Получаем высокую безопасность и кучу других проблем. Да и все равно зная MAC соседа можно теоретически сессию перехватить или просто ее поломать. Как тогда быть с QoS, фильтрами? Или выносить NAS ближе к клиентам, чтобы на магистралях уже ходил трафик без инкапсуляции, где можно его отполисить и отроутить?

[olebedev]

Хм... Вот и выходит, что со схемой изоляции портов идеальнее всего использовать PPPoE. За что боролись, на то и напоролись. Получаем высокую безопасность и кучу других проблем. Как тогда быть с QoS, фильтрами? Или выносить NAS ближе к клиентам, чтобы на магистралях уже ходил трафик без инкапсуляции, где можно его отполисить и отроутить?

 

Зачем в этом случае нужен PPPoE? С QoS и фильтрами все хорошо, кроме того вы получаете многоуровневую фильтрацию, на уровне агрегирования и на уровне пересылки пакетов (на роутере), да безусловно Вам потребуется более производительный роутер, но в этом случае если Вы просто запретите на нем доступ для клиента по IP то этот клиент будет полностью выключен, его пакеты больше никуда ходить не будут! Чем не коммунизм?

[Nag]

Хм... Вот и выходит, что со схемой изоляции портов идеальнее всего использовать PPPoE.

 

Почему???

Не вижу из чего это следует. ;-)

Если схема с изоляций накладывается на то же портсекьюрити - никаких проблем не возникает. И если эта схема сочетается с тегированными виланами - то же нет проблем...

[Bushi]

Хм... Вот и выходит, что со схемой изоляции портов идеальнее всего использовать PPPoE.

 

Почему???

Не вижу из чего это следует. ;-)

Если схема с изоляций накладывается на то же портсекьюрити - никаких проблем не возникает. И если эта схема сочетается с тегированными виланами - то же нет проблем...

 

Ну хорошо, допустим мы используем схему с изоляцией и портсекьюрити. Так как в этом случае трафик между портами исключен, как использовать адресное пространство ip? Какие тогда адреса, маски и шлюзы мы должны будем выдавать клиенту, чтобы разрешить межклиентский p-t-p трафик через роутер?

[olebedev]

Ну хорошо, допустим мы используем схему с изоляцией и портсекьюрити. Так как в этом случае трафик между портами исключен, как использовать адресное пространство ip? Какие тогда адреса, маски и шлюзы мы должны будем выдавать клиенту, чтобы разрешить межклиентский p-t-p трафик через роутер?

 

Да в общем случае любые, на все широковещательные запросы в поисках MAC'а отвечать будет одна единственная железка и всегда одним и тем же MAC'ом - роутер в режиме proxy-arp.