Перейти к содержимому
Калькуляторы

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

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

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

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

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

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

Изменено пользователем Megas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Изменено пользователем Megas

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не пробовал.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем pavel.odintsov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

 

 

 

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

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

 

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

отсюда

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.