Jump to content
Калькуляторы

Создание transparent firewall Какие технологии можно использовать.

Народ, помогите, может кто сталкивался. Не совсем понимаю с чего можно начать копать.

Суть в том что есть к примеру центральный роутер на базе MX, центральный коммутатор подключенный к роутеру двумя линками 10g в aggregate.

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

Естественно PC должны быть прозрачными абсолютно и их не должно быть видно. Городить STP не сильно хотелось был, может есть какое-то хитрое решение?

  +Port1---+                +---- PC1 Firewall -----+
MX-+        +--Agregate ---- +  balance,transperent  +  ----- Agregate ---- central switch
  +Port2---+                +---  PC2 Firewall -----+

Edited by Megas

Share this post


Link to post
Share on other sites

Непонятно, зачем STP.

Сбриджевать интерфейсы на серверах, навесить ebtables (если линукс).

Сетевые карты брать с аппаратным байпасом.

 

Но вообще такое лучше делать на порту центрального коммутатора, навесив ACL или полиси.

Share this post


Link to post
Share on other sites

STP это на случай если нельзя повесить одновременно 2PC на один линк, задача сводится к тому что если один из серверов умирает второй заберает его нагрузку, а когда они вместе работают, то нагрузка распределяется.

 

Может я не совсем правильно задачу описывают, а разве агрегационный линк между MX и CentSW поднимается если посредине будет стоять PC у которого интерфейсы сбриджеваны?

 

И еще не совсем понимаю что за карты такие, с аппаратным байпас, можно где-то прочитать?

Edited by Megas

Share this post


Link to post
Share on other sites

К нам на огонек явно забрел разработчик очередного DPI.

Share this post


Link to post
Share on other sites

Спасибо, DPI мне не нужен, нужен firewall для компании, в которой простой не нужен.

Про bypass почитал, интересная технология, не сталкивался и первый раз услышал, буду читать и пробовать достать тестовое железо.

 

Остается только вопрос, пока до практики руки не дошли насчет поднимется ли lacp поверх transparent bridge

Share this post


Link to post
Share on other sites

Не пробовал.

Но думаю, что в бридже должно подняться.

Share this post


Link to post
Share on other sites

Купите карту от Silicom, они умеют аппаратный байпасс. Если Ваш тазик подохнет - трафик аппаратно пойдет сквозь него и клиенты ничего не заметят. Такое использует Арбор в своем железе.

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

К сожалению судьбу не обманешь, lacp похоже работает не много по другим уровнять.

 

Попытались всунуть bridge в один из линков lacp, как и тупой свич, lacp blocked порт получаем, но физика при этом работает.

 

tcpdump на бридже трафика не показывает.

Share this post


Link to post
Share on other sites

Получилось собрать фильтрацию за счет lagg static, в dynamic не поднимается.

 

Получается так что в каждом статическом lagg линке можно держать по машине фильтрующей трафик, ищем теперь где достать сетевые карточки.

Share this post


Link to post
Share on other sites
Суть в том что есть к примеру центральный роутер на базе MX, центральный коммутатор подключенный к роутеру двумя линками 10g в aggregate.

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

стесняюсь спросить, а зачем ? у вас две коробки, которым пофиг на pps, но вы в разрыв собираетесь поставить два нежных писюка, которые будут ласты заворачивать от каждого чиха.

и что такое паразитный трафик ? syn-флуд на тазик клиента ? так пусть он сам от него и отбивается. зачем же надежность всей схемы ПД настолько ухудшать ради таких мелочей ?

Share this post


Link to post
Share on other sites

Такие системы должны стоять на миррор портах, анализировать там и давать команды нормальному надежому железу, что стоит в сети по тому же flow-spec.

Share this post


Link to post
Share on other sites
Суть в том что есть к примеру центральный роутер на базе MX, центральный коммутатор подключенный к роутеру двумя линками 10g в aggregate.

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

стесняюсь спросить, а зачем ? у вас две коробки, которым пофиг на pps, но вы в разрыв собираетесь поставить два нежных писюка, которые будут ласты заворачивать от каждого чиха.

и что такое паразитный трафик ? syn-флуд на тазик клиента ? так пусть он сам от него и отбивается. зачем же надежность всей схемы ПД настолько ухудшать ради таких мелочей ?

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

Не совсем вижу проблемы, если нормальные 10ки, реального трафа всего пару ГБ, сервера резервированы по БП, все на базе xeon с ecc памятью, то есть железо оптимально сопостовимо цена/качество.

 

 

 

Такие системы должны стоять на миррор портах, анализировать там и давать команды нормальному надежому железу, что стоит в сети по тому же flow-spec.

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

 

 

В этой всей задумке для нас имеется много плюсов, но и минусы тоже есть над которыми требуется работать, именно по этой причине расматвариются сетевые адаптера с интересной возможностью, железо которое можно использовать для нагрузок, а не игр. Но пока не проверим говорить о чем-то особо нет смысла, так как не совсем понятно как система поведет себя если прийдет к примеру теже обычные 20GB DDOS с аплинков, справятся ли эти промежуточные молотилки.

Но имеено режим bypass устраивает тем что в любой момент эти системы можно отключить.

Share this post


Link to post
Share on other sites

Такие системы должны стоять на миррор портах, анализировать там и давать команды нормальному надежому железу, что стоит в сети по тому же flow-spec.

Это два разных подхода, каждый имеет право на жизнь.

Мне железка в разрыв (с аппаратным байпасом) оказалась удобнее.

Share this post


Link to post
Share on other sites

0. Для софтроутеров более важен не объём трафика, а кол-во пакетов.

1. Если вставить карточки 10G это вовсе не означает, что через ваши тазики пройдёт 10G.

2. Почему требуется фильтровать именно "прозрачно"? Сделайте ECMP и ещё один хоп, там прибавляйте TTL+1, и для клиента будет точно также "прозрачно".

Share this post


Link to post
Share on other sites

Сделайте ECMP и ещё один хоп, там прибавляйте TTL+1, и для клиента будет точно также "прозрачно".

 

А можете нарисовать схемку? Я не понял логики. :(

Share this post


Link to post
Share on other sites

Хоп не получится, предсвьте себе роутер внутри сети, дальше ядерный коммутатор, от него на стойки. Извращаться в этом месте не сильно получится, по этому самый просто вариант влепить между ядром коммутатором и роутером вариант с прозрачным bridge.

 

Ну это логично что 10Г мелкими пакетами и т.д. тут много нюансов, но все надо тестировать.

Share this post


Link to post
Share on other sites

Сделайте ECMP и ещё один хоп, там прибавляйте TTL+1, и для клиента будет точно также "прозрачно".

 

А можете нарисовать схемку? Я не понял логики. :(

 

Прочитал свой пост, поставил себя на ваше место, и тоже ничего не понял в своём сообщении.

И, вообще, прочитав по-диагонали, не заметил, что у ТС "справа" на схеме коммутатор, а не маршрутизатор.

 

А схему представлял как:

      +Port1---+           +---- PC1 Firewall -----+
ROUTER-+        +--ECMP---- +  balance,transperent  +  ----- ECMP ---- ROUTER
      +Port2---+           +---  PC2 Firewall -----+

Share this post


Link to post
Share on other sites

вам в сторону netmap из freebsd смотреть надо

Хм... А для чего? LACP ведь завелся.

netmap ведь для L3 используется, а у ТС обработка в бридже.

 

0. Для софтроутеров более важен не объём трафика, а кол-во пакетов.

Так это и не роутер.

Там нагрузка будет связана с декодированием и распознаванием трафика, а не с маршрутизацией пакетов.

Share this post


Link to post
Share on other sites

0. Для софтроутеров более важен не объём трафика, а кол-во пакетов.

Так это и не роутер.

Там нагрузка будет связана с декодированием и распознаванием трафика, а не с маршрутизацией пакетов.

 

Не совсем понял, что вы хотели этим сказать. Если там бриджинг, а не роутинг, то всё будет летать?

Или вы имели ввиду, что основной работой серверов будет не непосредственно роутинг/бриджинг пакетов, а прочее ПО, которое будет заниматься анализом?

Всё равно не понятно.

Share this post


Link to post
Share on other sites

Или вы имели ввиду, что основной работой серверов будет не непосредственно роутинг/бриджинг пакетов, а прочее ПО, которое будет заниматься анализом?

Да, думаю что задачи будут именно такие.

Для того, чтобы переложить ethernet-кадр с интерфейса на интерфейс, много ресурсов не нужно.

Share this post


Link to post
Share on other sites

вам в сторону netmap из freebsd смотреть надо

Хм... А для чего? LACP ведь завелся.

netmap ведь для L3 используется, а у ТС обработка в бридже.

вы бы читали сначала, что вам пишут. речь об этом

Share this post


Link to post
Share on other sites

Или вы имели ввиду, что основной работой серверов будет не непосредственно роутинг/бриджинг пакетов, а прочее ПО, которое будет заниматься анализом?

Да, думаю что задачи будут именно такие.

Для того, чтобы переложить ethernet-кадр с интерфейса на интерфейс, много ресурсов не нужно.

Угу, именно поэтому тут более десятка тем, где народ постоянно пытается побороть разные проблемы с распределением нагрузки на цпу на своих софтроутерах.

ТС говорит не о 10 Мбит, а о 10 Гбит на платформу.

 

Основная нагрузка это не "маршрутизация" а программные прерывания, которые создаёт драйвер сетевой карты.

Share this post


Link to post
Share on other sites

Основная нагрузка это не "маршрутизация" а программные прерывания, которые создаёт драйвер сетевой карты.

Он же не на каждый кадр создает прерывание.

У меня есть СКАТ-6 — DPI на базе Linux с 6-портовой картой Silicom.

Он включен в разрыв, через него проходит около 2 Гбит/с трафика.

Причем это полноценный DPI, который проходящий трафик анализирует и блокирует HTTP, адресованный на определенные страницы.

И загрузка CPU в среднем держится на уровне 10-15%. Причем сервер достаточно скромный, CPU Xeon E5-1620.

Так что я думаю, что все в порядке будет.

Share this post


Link to post
Share on other sites

Основная нагрузка это не "маршрутизация" а программные прерывания, которые создаёт драйвер сетевой карты.

 

From 6.5 Mpps to 9.4 Mpps via build_skb() and tunning.

 

отсюда

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this