Traffic Segmentation + связь между хостами

[syslog-ng]

Для борьбы с подслушиванием трафика и вирусами, вызывающими arp-spoofing, приняли решение использовать Traffic Segmentation. Собрали все сервера в корне дерева, клиенты-листочки Cделали всё по букварю ДЛинка. Свитчи доступа 400шт* DES-3526, в корне 3шт*DGS-3326. Однако, для некоторых абонентов (или для всех), хотелось бы настроить связь между собой. Т.е., обеспечив их изоляцию на уровне 2, разрешить соединения на уровне 3 (или что-то типа этого). Все клиенты сидят в одной подсети 10.0.0.0/16 и классическая маршрутизация тут не поможет, т.к. ни один хост не додумается ходить в свою сеть через гейт. Да, в сети запущен мультикаст (ТВ-вещание). Хостов на L2 более 5000. Все хосты перевести в отдельные подсети нереально.

 

Такое возможно:

 

Есть некая сеть в городе, у которой тоже все абоненты сидят "каждый в своем влане", тоже есть мультикаст, и до их нововведения с вланами, абоненты сидели на свитчах DES-3526 с привязкой по МАК-ИП. Теперь, на 99% (точность информации) свитчи на уровне доступа остались теми же - DES-3526, а трасса до соседнего хоста в той же подсети проходит вот так:

 

IP: 77.41.27.186

Mask: 255.255.240.0

Def gateway: 77.41.16.1

 

Tracing route to host 77.41.27.185

1 2 ms 1 ms 1 ms 10.182.192.1 ??? та самая загадка.

2 2 ms 1 ms 1 ms 77.41.27.185

 

Trace complete.

 

ВОПРОС.

Можно ли организовать аналогичную схему на оборудовании ДЛинк? Что надо дополнительно прописать на свитчах доступа и/или что установить в качестве корневого устройства?

 

Заранее спасибо всем ответившим.

[vIv]

Смысл не очень ясен. Чисто теоретически могло бы помочь rfc3069 но я не в курсе, умеет ли это желозо эту функцию. Да и даже если умеет, всё-равно костыль редкий.

[syslog-ng]

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

[vIv]

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

Из-за какого вопроса? 8-)

 

Короче, тут есть одно "но": если это IP, то в IPv4 в нормальном случае _надо_ давать самостоятельной единице (в вашем случае - юзер) _подсеть_. Так работает IPv4.

Вариант: они будут несамостоятельны, тогда они будут в одном L2 сегменте, а это вы сразу заявили недопустимым.

Вывод: придётся давать по одной подсети на абонента. А вам это тоже не нравится.

[nnm]

Такая конструкция собирается, если заставить коробку, на которой терминируются VLAN с абонентами, делать proxy ARP. Т.е. отвечать своим MAC на ВСЕ ARP запросы.

[vIv]

rfc 3069 да