LINUX.ORG.RU
ФорумAdmin

Фильтрация по маски мак адреса


0

1

Подскажите пожалуйста как на основе фильтра по содержимому пакета сделать фильтр по мак адресу. Какое смещение и как задать. Какую таблицу использовать. Или может есть другой способ сделать фильтр по маске мак адреса ? Очень много устройств и поэтому перебирать их всех без маски это слишком большая будет нагрузка на ядро.

Не совсем понял о чём вы говорите.

iptables -m mac -h
anton_jugatsu ★★★★ ()
Ответ на: комментарий от Pinkbyte

Что зачем ?
Защита по маку зачем ?
Раз ёё ввели в айпитейблс то значит она нужна. Вот такой мой ответ.
Защита по маски мака нужна в моём случае потомучто есть около сотни устройств где первые цыфры макадреса одинаковые. А посколько устройств около сотни нагружать айпитейблс таким количеством правил врядли получится без возникновения тормозов.

Baltika80 ()
Ответ на: Зачем???! от adriano32

Нет. Сервер вполне себе мощный(не помню что но кажеться дуал коре дуо), но и трафик он должен обрабатывать без тормозов. Вводить сотню правил думую нерационально. Лучше вместо сотни сделать 8-10.

Baltika80 ()
Ответ на: комментарий от Baltika80

первые цыфры макадреса
>>цыфры макадреса
>>цыфры(!!!)

На лицо профессиональный уровень знаний Ethernet.

>>трафик он должен обрабатывать без тормозов

А ты настроил как говоришь «с сотней правил» и «трафик тормозит?»

adriano32 ★★★ ()
Ответ на: комментарий от adriano32

Привык делать хорошо или никак.
Мне такое решение(вбивание сотни правил) кажеться непрофессиональным, когда можно найти(я в это верю) более оптимальное.

Baltika80 ()
Ответ на: комментарий от Baltika80

Видимо до этого ты делал никак.
С чего ты взял, что конфиг отзывчивого продакшн сервера должен быть из десяти строчек?

Вдумайся напоследок как будет происходить так желаемая тобой «сверка по маске мака на основе фильтра по содержимому пакета»
Реально ли будет быстрее fragment-matching, парсящий весь пакет, отлаженной годами командой netfilter процедуры извлечения стандартных полей из заголовка пакета и проверки по правилам в конфиге?

Всё, больше никого не буду переубеждать - если ты сам себе царь и отлично представляешь принцип работы iptables, основы pattern matching, понимаешь какие алгоритмы более накладны для процессора, а какие более щадящие... дерзай сам.

adriano32 ★★★ ()
Ответ на: комментарий от Tanger

Я думаю парень представляет MAC-адрес 01:23:45:ab:cd:ef как строку у не как 10010001101000101101010111100110111101111.
Если я ошибаюсь - мои извинения, но пусть тогда впредь выражается правильно.

adriano32 ★★★ ()

Возможно, что вам нужен ebtables, правда Еthernet интерфейс нужно будет превратить в Bridge и не знаю, как это скажется на производительности.

mky ★★★★★ ()
Ответ на: комментарий от adriano32

У меня нет информации о том что сам iptables эту сотню правил соптимизирует так что лучше это поручить ему чем пытатся делать правило вида «pattern matching».


Baltika80 ()
Ответ на: комментарий от adriano32

А правильно как?

Несколько первых символов...
Несколько первых щестнадцатиричных цИфр...

ИМХО, в том, что он сказал «несколько цИфр» нет ничего ужасного.

Tanger ★★★★★ ()

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

JFreeM ★★★☆ ()
Ответ на: комментарий от mky

Возможно, что вам нужен ebtables, правда Еthernet интерфейс нужно будет >превратить в Bridge и не знаю, как это скажется на производительности.


Если мост это всё что нужно и этот самый ebtables это может то я думую это стоящие решение. Во всяком случае стоит попробовать.

Baltika80 ()
Ответ на: комментарий от Baltika80

У меня нет информации о том что сам iptables эту сотню правил соптимизирует

Сходи на оффсайт netfilter или возьми книгу по iptables где описан принцип его работы или разбери сорцы, раз ты так любишь делать либо хорошо, либо никак.

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

А у тебя есть информация, что ты сможешь написать десяток своих правил и соптимизировать их так, чтоб «трафик обрабатывать без тормозов.»?

adriano32 ★★★ ()
Ответ на: комментарий от Baltika80

Прочти сперва как он работает хотя бы тут

Если у тебя большой траффик, то ИМХО ты как раз повесишь свой сервер.

brctl - Чем этот код хуже чем аппаратный коммутатор?

Для того чтобы работать в качестве моста, устройство должно быть переведено в неразборчивый (promiscuous) режим, в котором оно получает весь трафик, приходящий на интерфейс. В действительно загруженных сетях это может занять значительную часть процессора, замедляя работу системы. Выход — или использовать выделенную Linux-систему в качестве моста, или использовать аппаратный коммутатор.

adriano32 ★★★ ()
Ответ на: комментарий от JFreeM

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

Не всегда. При некоторой длинне бинарного массива поиск будет проигрывать. Хотя у поиска безусловно преимущество при малом размере массива.

Baltika80 ()
Ответ на: комментарий от Baltika80

А если используется несколько коммутаторов, для того чтобы избежать петель коммутации, нужно включить поддержку протокола Spanning Tree Protocol. Теперь тебе страшно?

adriano32 ★★★ ()
Ответ на: комментарий от adriano32

А если используется несколько коммутаторов, для того чтобы избежать петель коммутации, нужно включить поддержку протокола Spanning Tree Protocol. Теперь тебе страшно?


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

Baltika80 ()
Ответ на: комментарий от Baltika80

Петля ЕМНИП возможна с первым же коммутатором, к которому подключен комп-бридж

Мне надоело, можешь считать, что я сливаю.

Ты такой упёртый - только рассуждать горазд - взял бы да протестил конфиг «с сотней правил» (первый ответ в треде) против «маски по маку» (u32 patch). Сравнил отзывчивость. Выложил результаты. Тогда бы и поговорили.

adriano32 ★★★ ()
Ответ на: комментарий от adriano32

Чтобы сравнить нужно чтобы было с чем сравнивать.
Пока мне дали лишь направление поиска.
Нарыл вот здесь http://ebtables.sourceforge.net/misc/ebtables-man.html вот это:
-s, --source [!] address[/mask]
The source MAC address. Both mask and address are written as 6 hexadecimal numbers separated by colons. Alternatively one can specify Unicast, Multicast, Broadcast or BGA (Bridge Group Address):
Unicast=00:00:00:00:00:00/01:00:00:00:00:00, Multicast=01:00:00:00:00:00/01:00:00:00:00:00, Broadcast=ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff or BGA=01:80:c2:00:00:00/ff:ff:ff:ff:ff:ff. Note that a broadcast address will also match the multicast specification. The flag --src is an alias for this option.
Вроде то что нужно...

Baltika80 ()
Ответ на: комментарий от adriano32

Я вот хотел уточнить, а какой именно «лишний» трафик приходит на интерфейс, если сеть построена на свичах, у которых не переполнена таблица MAC-адресов?

А то в Инете только повторение этой цитаты (оригинал http://www.linuxfoundation.org/en/Net:Bridge ), а объяснения нет.

mky ★★★★★ ()
Ответ на: комментарий от mky

Я почему-то сразу подумал про броадкасты, траффик для поддержки соединений (ну как это называется, когда периодически посылается друг-другу пинг, чтоб не закрылось на нате или по таймауту не закрылось), когда копипастил фразучитал статью, поэтому посчитал вполне себе логичным. Если не прав, исправь, я не могу назвать себя экспертом в этом вопросе.

Загляни, пожалуйста, в этот тред, интересно твоё мнение.

adriano32 ★★★ ()
Ответ на: комментарий от adriano32

Броадкасты всегда приходят и обрабатываются. Другое дело, если бридж, то дальше рассылаются. Но это часть работы бриджа, ИМХО, это нельзя рассматривать как замедление системы.

Если отбросить в строну случай с переполенной таблицей, (когда switch = hub и производительности сети вобще нет), то, вроде и нет лишнего трафика.

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

Вобще я в Инете не нашёл замера, насколько падает производительность при создании бриджа из одного интерфейса.

mky ★★★★★ ()
Ответ на: комментарий от mky

А как грамотно сделать поднятие моста автоматически ?
Вроде всё просто с одной стороны - создай загрузочный скрипт и наслаждайся жизнью, но есть ведь /etc/network/interfaces. Туда надо чтонить писать или не надо.
сам скрипт который будет поднимать мост стоит вызывать до вызова /etc/init.d/networking или после и вместо? Конечно можно самому поэксперементировать, но одна задача для которой это было нужно уже неактуальна (командировка закончена), а вторая задача ещё не наступила.

Baltika80 ()
Ответ на: комментарий от mky

А мост это даже хорошо так как у сервера две сетевухи, а используеться тока одна.
Можно по идеи сделать так чтобы от свитча шло два соединения на две сетевухи.
Вот тока как узнать поодерживает ли он одинаковые айпи на нескольких портах.
Вроде должен так как свитч сюрьёзный гигабитный D-Link DGS на 24 порта (какой не помню). Но в сетях я ламер по сравнению с теми кто админит у интернет провайдеров, поэтому таких специфических заморочек не знаю. подскажите кто знает ?

Baltika80 ()
Ответ на: комментарий от Baltika80

Вот, если делать дистрибутивно-правильно, через правку /etc/network/interfaces: http://acidborg.wordpress.com/2010/01/21/how-to-configure-a-network-bridge-in...

сам скрипт который будет поднимать мост стоит вызывать до вызова /etc/init.d/networking или после и вместо?

«До», ИМХО, смысла не имеет, настройки перепишутся. «Вместо», тогда этот скрипт должен быть полной заменой /etc/init.d/networking, и поднимать все интерфейсы и, вроде, что-то ещё делать. «После» можно, но лучше, всё таки поправить /etc/network/interfaces, чтобы потом не вспоминать, почему в interfaces одно, а по факту другие настройки.

Если сервер нужно связать со свичём несколькими линками, то это бондинг. Тогда сервер не форвардит пакеты между интерфейсами, а старается загрузить оба интерфейса. Причём, лучше, когда свитч понимает агрегацию портов (EtherChannel), но возможны варианты, когда разным клиентам сервер сообщает разные MAC-адреса. DGS'ы, вроде, не управляемые, поэтому там нельзя настроить агрегацию портов, но с DLink я не дружил.

А если сетёвки объединить в мост и воткнуть в одни свитч, то получится закольцовка (петля) и свичу будет плохо.

Можно ли будет засунуть bond-интерфейс (bond0) в bridge (br0) --- не знаю, не пробовал.

mky ★★★★★ ()
Ответ на: комментарий от mky

mky, спасибо очень интересно читать тебя.
Я думал просто объеденить два сетевых интерфейса в один мост и создать виртуальный интерфейс. Таким образом получится этот самый bonding по идеи. Если нет форвординга (отключим если что) то по идеи не должно быть закольцовок.

Baltika80 ()
Ответ на: комментарий от Baltika80

Нет. Бондинг и бриджинг это разные вещи.

Если взять «правильный» бондинг в режиме load balancing (round-robin), при котором свич должен знать какие порты объединены в один, то можно дать следующие различия. В режиме бондинга любой, в том числе и широковещательный пакет пойдёт через один из двух физических интерфейсов (через тот, который свободен в данный момент). В режиме бриджа широковещательные пакет будет отправлен через оба физических интерфейса, а не широковещательные (unicast) пойдут через тот интерфейс, на котором ядро «видело» адресуемый MAC-адрес.

Кроме этого, в режиме бриджа ядро получит от свича широковещательный ARP-зарос на оба физических интерфейса, ответит на оба этих пакета, что, ИМХО, не понравится свичу.

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.