Как защитить коммутатор от L2 петли без отключения избыточного линка?

Question

[Benedictus]

Есть такая схема включения



Внешняя платформа - подменяет MAC адреса назначения на MAC адрес сервера аналитики

Сервер аналитики трафика прозрачно пропускает трафик через себя и отправляет его на Port 1, но в этом случае между портом 1 и портом 2 возникает петля, а необходимо что бы L2 Switch отправлял пакеты обратно на внешнюю платформу.

Подскажите, можно ли как то отключить пересылку пакетов между двумя портами в рамках L2 домена одного свича, есть ли какие то механизмы защиты

Comments

[Сослан Хлоев]

Если я не ошибаюсь, коммутатор среагирует на петлю если увидит оди и тот же MAC адрес на 2 портах. Если это условие не наступает, то по идее коммутатор не должен ругаться на петлю. Могу ошибаться.

[athacker]

Сослан Хлоев, коммутатор среагирует на петлю (и отрубит один линк), если увидит STP BPDU со своим идентификатором. А их будет транслировать только другой коммутатор. А т. к. тут один коммутатор и остальные сервера -- то ничего не будет. А конкретное поведение будет определяться тем, с какого MAC-адреса анализатор будет отправлять обработанный трафик. Если с того же, на который он принимает не обработанный, то коммутатор просто в следующий раз отправит пакет от платформы в порт 1 коммутатора. А на порту 2 трафика не будет вообще.

[Сослан Хлоев]

athacker, stp в расчет не брал, имел в виду стандартный loopdetect.

Answer 1

[athacker]

Придётся всю систему менять. Либо переделывать отдачу трафика на "анализатор" (вы, я так понимаю, строите IPS?) через маршрутизацию, т. е. выносить на уровень L3. Либо подавать на анализатор копию трафика через SPAN, а анализатор должен отстреливать spoofed-пакетами TCP RST в сторону клиента, прикидываясь сервером если соединение признано подозрительным. Тогда клиент будет сразу закрывать соединение.

Но отвечая на прямым образом поставленный вопрос -- защитить коммутатор от отключения избыточного линка можно настроив, например, port-channel на этих линках (между коммутаторами). Однако очевидно, что это не ваша история, и вам этот вариант не поможет. Так что остаётся только менять систему.

Comments

[Benedictus]

SPAN в данном случае не подойдет. Анализатор еще и изменяет трафик - нужно заблокировать часть пакетов и оставшийся часть вернуть клиенту. А механизм Private VLAN Edge (switchport protected) в этом случае не поможет?

И если работать через L2/L3 Switch, я правильно понимаю что можно будет просто создать статический маршрут в сети /30 отдав при этом 2-а IP адреса на Port 2 и Port 1? Или потребуется делать какие то тунели?

[athacker]

А у вас на интерфейсах 1 и 2 анализатора одинаковые маки, что ли? Если да, то ваша схема вообще работать не будет, независимо от изоляции портов. Т. к. в момент отправки анализатором первого же пакета проанализированного трафика коммутатор будет править TCAM, и записывать, что такой-то MAC у него висит за портом 1. А значит, следующий пакет, который платформа попытается на этот мак завернуть, уйдёт через порт 1 коммутатора и попадёт на порт 1 вашего анализатора.

А если маки разные (т. е. "внешняя платформа" подменяет DST MAC на один MAC, а анализатор, когда отправляет пакет после анализа, отправляет пакет с другого SRC MAC, не совпадающего с тем, который подставляет платформа), то проблемы как бы вообще нет -- коммутатор видит два порта, к которым подключены устройства с отличающимися маками.

Кстати, а какой смысл блокировать ЧАСТЬ пакетов в TCP сессии? :-) Это равнозначно обрыву соединения. Клиент не увидит части пакетов, и отправит серверу сообщение о том, что пакеты такие-то не дошли. Сервер повторит отправку. Ваша система опять их заблокирует. Клиент опять пожалуется. И так будет повторяться, пока соединение по глобальному таймеру не сбросится. Тогда уж можно сразу подделывать TCP RST от сервера, чтобы клиент сразу соединение сбросил.

[athacker]

Насчёт L3 -- зависит от общей схемы. Откуда вы берёте трафик, что это за сети, как они попадают на вашу платформу и т. п. В общем случае, для платформы нужно указать, что такие-то DST сети у нас за IP, висящем на анализаторе. Анализатор трафик получил и отправил через другой интерфейс, на другой IP платформы. На платформе должны быть две таблицы маршрутизации -- для входящего трафика от клиентов и последующей отправки на анализатор, и для входящего (уже проанализированного трафика) от анализатора, который будет отправляться дальше по маршруту (в интернет, например).

Answer 2

[Михаил Хорев]

Обычно такие шарманки когда делают, входящий и исходящий трафик разводят по разным VLAN-ам.
Насколько критично, что б он был в одном влане?

На Cisco Catalyst можно, то есть нужно написать на обоих портах switchport protected, а на аплинке такую строку не писать.
На порту 1 (для обработанного трафика) надо еще написать mac access-list, что б необработанный трафик не пер на него с аплинка. (unknown unicast будет так или иначе занимать полосу)
И вообще, если protected чем-то не подойдет - можно покурить тему private vlans.

Answer 3

[Валентин]

1) два логических или физических интерфейса на внешней платформе, на коммутаторе они в разных вланах. На коммутаторе можно отключить mac-address-learning для обоих вланов
2) первый и второй порт на свиче в режим port-isolate
3) если трафик только в одну сторону, тупо отзеркалировать типа SPAN (без всяких вланов) из порта 1 в порт в сторону внешней платформы
4) на сервере для аналитики трафика помечать исходящий трафик какой-нибудь меткой (например qos), а на коммутаторе запретить исходящие пакеты с этим qos на порту 2. Для всего слана отключить mac-learning.