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

iptables классификация трафика

Пока еще трафик режится через --set-mark в FORWARD и дальше уже обрабатывает tc

перейти на хэш таблицы не получается из-за vlan интерфейсов на сервере, пробовал различные варианты но трафик из vlan не попадает в filter, только когда указываешь eth1.2020 и т.д.

Решил попробовать через CLASSIFY в iptables отправлять сразу в нужный класс.

Смотрю пример:

http://shearer.org/Linux_Shaping_Template

 

И не пойму, кто-то делает -j CLASSIFY в таблице mangle forward, кто-то в mangle postrouting

но чем заинтересовал этот пример, они вешают tos в forward и дальше класс в postrouting

 

Собственно вопросов несколько, есть ли разница где указывать class в forward или postrouting

ведь согласно

Iptables.gif

все находится в одной цепочке перед выходом пакета.

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

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


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

пробовал различные варианты но трафик из vlan не попадает в filter, только когда указываешь eth1.2020 и т.д.

 

мб использовать дополнительный уровень абстракции в виде ifb ?

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


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

FORWARD - до SNAT, POSTROUTING - после SNAT

Юзайте IFB

Изменено пользователем Alex/AT

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


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

Пока еще трафик режится через --set-mark в FORWARD и дальше уже обрабатывает tc

перейти на хэш таблицы не получается из-за vlan интерфейсов на сервере, пробовал различные варианты но трафик из vlan не попадает в filter, только когда указываешь eth1.2020 и т.д.

Можно классифицировать и на физическом интерфейсе. 802.1Q добавляет к фрейму дополнительный заголовок размером в 4 байта, т.е. значения смещений для destination и source IP (12 и 16, соответственно) нужно увеличить на 4.

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

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


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

photon, в упор не могу понять почему не попадает никакой трафик.

 

root@gateway:/shaper_htb_hash# tc -s -d -p filter show dev eth0
filter parent 1: protocol ip pref 100 u32
filter parent 1: protocol ip pref 100 u32 fh 804: ht divisor 1
filter parent 1: protocol ip pref 49149 u32
filter parent 1: protocol ip pref 49149 u32 fh 131: ht divisor 256
filter parent 1: protocol ip pref 49149 u32 fh 803: ht divisor 1
filter parent 1: protocol ip pref 49150 u32
filter parent 1: protocol ip pref 49150 u32 fh 121: ht divisor 256
filter parent 1: protocol ip pref 49150 u32 fh 802: ht divisor 1
filter parent 1: protocol ip pref 49151 u32
filter parent 1: protocol ip pref 49151 u32 fh 111: ht divisor 256
filter parent 1: protocol ip pref 49151 u32 fh 801: ht divisor 1
filter parent 1: protocol ip pref 49152 u32
filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 link 111:  (rule hit 0 success 0)
 match IP src 0.0.0.0/0 (success 0 )
   hash mask ff000000 at 20
root@gateway:/shaper_htb_hash#

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


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

Поскольку через физический интерфейс идет уже тегированный трафик, то IP-адреса должны быть смещены на 4 байта. Нужно использовать правила вида match u32 0xc0a000001 0xffffffff at 16 вместо match ip dst 10.0.0.1. Для проверки смотрите трафик с помощью tcpdump.

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


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас