tc filter ЛОГИЧЕСКОЕ отрицание для SRC

А не хочешь вместо u32 заюзать bpf?

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

Через iptables ресурсозатратно по цпу, для этого bpf и придумали.

Попробую bpf, спасибо.

Напиши пожалуйста пример добавления bpf фильтра с использованем утилиты tc.

tc filter add dev eth0 protocol ip bpf run bytecode "тут_идёт_байткод" flowid 1:10

Байткод можешь сгенерировать так:

sudo tcpdump -ni lo -ddd not net 192.168.1.0/24 | tr '\n' ','

или с помощью утилитки pcapc:

pcapc not net 192.168.1.0/24

У тебя будет вывод типа такого:

18,40 0 0 12,21 0 6 2048,32 0 0 26,84 0 0 4294967040,21 11 0 3232235776,32 0 0 30,84 0 0 4294967040,21 8 9 3232235776,21 1 0 2054,21 0 7 32821,32 0 0 28,84 0 0 4294967040,21 3 0 3232235776,32 0 0 38,84 0 0 4294967040,21 0 1 3232235776,6 0 0 0,6 0 0 65535,

Вот его и нужно вставить в команду создания фильтра:

tc filter add dev eth0 protocol ip bpf run bytecode "18,40 0 0 12,21 0 6 2048,32 0 0 26,84 0 0 4294967040,21 11 0 3232235776,32 0 0 30,84 0 0 4294967040,21 8 9 3232235776,21 1 0 2054,21 0 7 32821,32 0 0 28,84 0 0 4294967040,21 3 0 3232235776,32 0 0 38,84 0 0 4294967040,21 0 1 3232235776,6 0 0 0,6 0 0 65535," flowid 1:10

Синтаксис фильтров стандартный для tcpdump'а или pcap'a. Читать man 7 pcap-filter.

Для того, чтобы это работало, нужно ядро 3.14+, свежий iproute2, а чтобы работал быстрый JIT для таких правил (sysctl -w net.core.bpf_jit_enable=1), нужна 64-битная система, хотя BPF мною юзается и на 32-битной без JIT.

Спасибо.

Интересно про использование bpf в фильтрах. Фича совсем свежая.

Но использовать bpf для «not net 192.168.1.0/24» практически бесполезно. По скорости u32 мало отличается от bpf.

Для простых случаев хорошо бы транслятор в u32 как для pcap.

Но использовать bpf для «not net 192.168.1.0/24» практически бесполезно.

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

Конкретно для случая ТС'а, я так понимаю, при использовании u32 нужно плясать от противного, т.е. писать несколько match'ей.

Ну да. Мне нужно разделять на маршрутизаторе локальный траффик( т.е. траффик от маршрутизатора к локальному пк, например ssh-траффик) от forward-траффика(интернет траффик), чтобы по разному шейпить их.
Два фильтра на интерфейсе, который смотрит в локальную сеть:
1 фильтр: адрес источника НЕ адрес сервера;
2 фильтр: адрес источника - это адрес сервера.

Я понимаю, что это деление локального и транзитного траффика можно сделать и с помощью u32, но когда есть возможность использовать логические операции в фильтре, то проще имхо.

А можно обратно преобразовать код, полученный с использованием tcpdump -ddd, в человекочитаемый вид?

Честно говоря, не знаю. Знаю, что набор чисел можно декомпилировать в человекочитаемый ассемблер, а можно ли в pcap-style — хз. Да и зачем?

Ну типо состояние текущего фильтра узнать.

tc -s filter show dev eth0? Да, там байткод :(.

есть замечательный пакет htb.init - он умеет генерировать простые фильтры.