Доступ в инет с изоляцией клиентов.

[UnLike]

Необходимо организовать доступ в интернет для ethernet клиентов, при этом нужно разграничивать трафик на локальный (игр. и файловые сервера) и интернет трафик. Клиенты по умолчанию "видеть" друг друга не должны. Насколько я понял, использовать pppoe+radius или vpn при таких условиях не получится, т.к. основываясь на данных RADIUS нельзя отделить локальный трафик от внешнего. Если использовать аутентификацию по ip+mac с привязкой mac к порту коммутатора можно разделить трафик, но непонятно как изолировать клиентов друг от друга. Возможно использование для изолирования IEEE 802.1Q и организация vlan на каждого клиента, но с учетом того что коммутаторы могут подключаться каскадом, схема vlan очень громоздкая.

Или возможно сделать pppoe+radius для интернет, а ip+mac для локального трафика, но опять возникает вопрос про изоляцию клиентов друг от друга... Что посоветуете в такой ситуации?

Зараннее спасибо!

[Vicus]

Сами пользуем вот такую схемку:

На домах клиенты втыкаются в свичи типа CNet CNSH-1600, Compex PS-2216, со включеной изоляцией портов. Далее эти свитчи врубаются в конверторы оптики, приходят в офис, там из конвертера втыкаются в Каталист (где на каждый порт свой в-лан), и в итоге все упирается в гигабитный интерфейс Cisco 7301 с no ip address в конфиге.

Работают по PPPoE, авторизируются через радиус, трафик сбрасывает циска по netflow, биллинг делит на классы :)

[Солнечный КОТ]

Используем очень похожее решение

[UnLike]

Изоляция портов реализована на 802.1q или каким-то другим способом? Посмотрю описахи на ваши свитчи...

[UnLike]

Проблема еще в том, что свитчи могут быть включены последовательно (соединение оптикой), по 3-4 штуки... Таким образом для изоляции надо создавать vlan на всех портах все свитчей с разными vlan метками. Пока до меня не дошло, что именно делать с общими оптическими портами.

[lamer]

Изоляция портов реализована на 802.1q или каким-то другим способом

Ну дык, VLAN он и есть VLAN :)

[Солнечный КОТ]

Ну дык, VLAN он и есть VLAN :)

 

vlan .1q <> port based vlan

[lamer]

Да, но суть то не меняется :)

[Guest]

Сами пользуем вот такую схемку:

На домах клиенты втыкаются в свичи типа CNet CNSH-1600, Compex PS-2216, со включеной изоляцией портов. ...

Чем обеспечиваеться изоляция портов ?

Port based VLAN ?

[Vicus]

У меня язык не поворачиваеся это VLAN'ами назвать. Проще сказать, что это 15 независимых порта, которые могут общаться только с первым портом, но никак между собой. А последовательно свитчи очень просто втыкаются: общий порт у втыкаемого свитча суем в любой абонентский, т.е. используя везде такого рода свитчи мы добиваемся полной изоляции на абонентском уровне до самого ядра.

[Susanin]

У меня язык не поворачиваеся это VLAN'ами назвать. Проще сказать, что это 15 независимых порта, которые могут общаться только с первым портом, но никак между собой. А последовательно свитчи очень просто втыкаются: общий порт у втыкаемого свитча суем в любой абонентский, т.е. используя везде такого рода свитчи мы добиваемся полной изоляции на абонентском уровне до самого ядра.

Понятно.

У D-Link это называеться "Сегментация трафика".

НО, интересный момент. Пользователи А и Б включены в разные порты одного свича. Разрезаны с помощью данной технологии.

И тут пользователь А берет и ставит себе ip пользователя Б. При этом пользователь Б находиться OnLine. Естественно, А выйти в инет не сможет - не знает логина, не тот МАС. НО и работать пользователю Б он тоже не даст - так как тот, кто последним сделал команду "обновить" на сетевом интерфейсе (WinXP) - т.е. разослал широковещательный пакет - тот и будет работать со свичем. Т.е. именно на его MAC будут сыпаться пакеты. При этом законопослушный пользователь Б даже не увидит системного сообщения о конфликте ip адресов..

[krab]

И тут пользователь А берет и ставит себе ip пользователя Б. При этом пользователь Б находиться OnLine. Естественно, А выйти в инет не сможет - не знает логина, не тот МАС. НО и работать пользователю Б он тоже не даст - так как тот, кто последним сделал команду "обновить" на сетевом интерфейсе (WinXP) - т.е. разослал широковещательный пакет - тот и будет работать со свичем. Т.е. именно на его MAC будут сыпаться пакеты. При этом законопослушный пользователь Б даже не увидит системного сообщения о конфликте ip адресов..

Почему вы так решили? L2 свич понятия не имеет о том какой у клиента в порту IP-адрес, он работает по mac-адресам. Да и PPPoE выдает адреса на основании авторизации по mac+login+password...

А вообще рулит 802.1x :)

[Nailer]

У меня язык не поворачиваеся это VLAN'ами назвать. Проще сказать, что это 15 независимых порта, которые могут общаться только с первым портом, но никак между собой. А последовательно свитчи очень просто втыкаются: общий порт у втыкаемого свитча суем в любой абонентский, т.е. используя везде такого рода свитчи мы добиваемся полной изоляции на абонентском уровне до самого ядра.

Понятно.

У D-Link это называеться "Сегментация трафика".

НО, интересный момент. Пользователи А и Б включены в разные порты одного свича. Разрезаны с помощью данной технологии.

И тут пользователь А берет и ставит себе ip пользователя Б. При этом пользователь Б находиться OnLine. Естественно, А выйти в инет не сможет - не знает логина, не тот МАС. НО и работать пользователю Б он тоже не даст - так как тот, кто последним сделал команду "обновить" на сетевом интерфейсе (WinXP) - т.е. разослал широковещательный пакет - тот и будет работать со свичем. Т.е. именно на его MAC будут сыпаться пакеты. При этом законопослушный пользователь Б даже не увидит системного сообщения о конфликте ip адресов..

 

Со свитчем в данном случае все будет в порядке, так как маки различны. Роутер в ответ на arp-запрос получит два ответа, но это уже решаемая проблема :-)

[Технократ]

Со свитчем в данном случае все будет в порядке, так как маки различны. Роутер в ответ на arp-запрос получит два ответа, но это уже решаемая проблема :-)

Если ее решить до того как он получит 2 ответа :)

[krab]

Да вы чего? Если используется PPPoE, не будет никаких arp'ов. На интерфейсе же нету айпишника!

[Nailer]

Со свитчем в данном случае все будет в порядке, так как маки различны. Роутер в ответ на arp-запрос получит два ответа, но это уже решаемая проблема :-)

Если ее решить до того как он получит 2 ответа :)

 

Да и после ее решить можно ;-) А если решить, то и запросов не будет :-)

[Nailer]

Да вы чего? Если используется PPPoE, не будет никаких arp'ов. На интерфейсе же нету айпишника!

 

Какое, нахрен, PPPoE? Для чего городить схему с изоляцией, чтобы потом по ней PPPoE запустить чтоли? :-))

[mav]

Да вы чего? Если используется PPPoE, не будет никаких arp'ов. На интерфейсе же нету айпишника!

 

Какое, нахрен, PPPoE? Для чего городить схему с изоляцией, чтобы потом по ней PPPoE запустить чтоли? :-))

а что еще то? про связанность же говорят)

[Nailer]

Да вы чего? Если используется PPPoE, не будет никаких arp'ов. На интерфейсе же нету айпишника!

 

Какое, нахрен, PPPoE? Для чего городить схему с изоляцией, чтобы потом по ней PPPoE запустить чтоли? :-))

а что еще то? про связанность же говорят)

 

Я вам схему описывал..

[mav]

Nailer, вы про подсеть /30? не думаю, что это лучшее решение.

[krab]

Да вы чего? Если используется PPPoE, не будет никаких arp'ов. На интерфейсе же нету айпишника!

 

Какое, нахрен, PPPoE? Для чего городить схему с изоляцией, чтобы потом по ней PPPoE запустить чтоли? :-))

А в чем проблема то? И двойная изоляция (у клиентов не возникает соблазна поставить на сетевухах айпишники и подрять туннель через сеть провайдера внутри сегмента) +авторизация, и клиенты друг друга видят (через роутер, соответственно траффик поддается контролю). По моему идеальный вариант, гораздо более простой чем 802.1q.

[Nailer]

Nailer, вы про подсеть /30? не думаю, что это лучшее решение.

 

Почему?

[Nailer]

Да вы чего? Если используется PPPoE, не будет никаких arp'ов. На интерфейсе же нету айпишника!

 

Какое, нахрен, PPPoE? Для чего городить схему с изоляцией, чтобы потом по ней PPPoE запустить чтоли? :-))

А в чем проблема то? И двойная изоляция (у клиентов не возникает соблазна поставить на сетевухах айпишники и подрять туннель через сеть провайдера внутри сегмента) +авторизация, и клиенты друг друга видят (через роутер, соответственно траффик поддается контролю). По моему идеальный вариант, гораздо более простой чем 802.1q.

 

 

PPPoE нужен тогда, когда вы не контролиоруете L2-сегмент.

Хотя я не прав, PPPoE нужен, так как сегмент на самом деле вы не контролируете..

[krab]

PPPoE нужен тогда, когда вы не контролиоруете L2-сегмент.

Хотя я не прав, PPPoE нужен, так как сегмент на самом деле вы не контролируете..

И да и нет.

Если L2 не контролируется, то ничто не мешает поднять в сегменте альтернативный PPPoE сервер (практически тоже самое что и в случае DHCP, только в несколько другой проекции). В данном случае такая опасность сводится к нулю, т.к. клиенты изолированы друг от друга, но есть связность клиентов друг с другом (по схеме client1 -> PPPoE -> router -> PPPoE -> client2, даже если client1 и client2 находятся физически в одном свиче).

Если же вместо PPPoE использовать, например, подсети /30 (с кучей алиасов на интерфейсе) - возникает бардак с маршрутизацией, не использовать - будет отсутствовать связность клиентов в пределах сегмента (будут жалобы, типа - не могу поиграть с соседом по сети в Counter-Strike).

Поэтому, имхо, технологии отлично дополняют друг друга, и имеют очевидные преимущества перед связкой Port Security+VPN, Port Security+NAT, итд...

[Nailer]

PPPoE нужен тогда, когда вы не контролиоруете L2-сегмент.

Хотя я не прав, PPPoE нужен, так как сегмент на самом деле вы не контролируете..

И да и нет.

Если L2 не контролируется, то ничто не мешает поднять в сегменте альтернативный PPPoE сервер (практически тоже самое что и в случае DHCP, только в несколько другой проекции). В данном случае такая опасность сводится к нулю, т.к. клиенты изолированы друг от друга, но есть связность клиентов друг с другом (по схеме client1 -> PPPoE -> router -> PPPoE -> client2, даже если client1 и client2 находятся физически в одном свиче).

Если же вместо PPPoE использовать, например, подсети /30 (с кучей алиасов на интерфейсе) - возникает бардак с маршрутизацией, не использовать - будет отсутствовать связность клиентов в пределах сегмента (будут жалобы, типа - не могу поиграть с соседом по сети в Counter-Strike).

Поэтому, имхо, технологии отлично дополняют друг друга, и имеют очевидные преимущества перед связкой Port Security+VPN, Port Security+NAT, итд...

 

Ну по поводу бардака - это субьективно, смотря как делать и как к получившемуся относится :-)

 

Лучшая схема - dot1x+port security + dhcp snooping + dynamic arp inspection + ip source guard :-) Хорошо работает на 3750-EMI :-P