URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 78852
[ Назад ]

Исходное сообщение
"В каком месте IPTABLES работает TC?"

Отправлено Rom1 , 21-Фев-08 13:33 
Необходимо поднять шейпер на TC.
Задался таким вопросом, в каком месте работает TC?
Тут, в "<Routing decision>", сразу после nat-PREROUTING?

----------------------------
                    <Network>
              1) mangle - PREROUTING
              2)    nat - PREROUTING
                <Routing decision>
           +------------+--------------+
3) mangle - INPUT                     |
4) filter - INPUT                     |
     <Local process>         8) mangle - FORWARD
   <Routing decision>        9) filter - FORWARD
5) mangle - OUTPUT                    |
6)    nat - OUTPUT                    |
7) filter - OUTPUT                    |
           +------------+--------------+
             10) mangle - POSTROUTING
             11)    nat - POSTROUTING
                    <Network>
----------------------------


Содержание

Сообщения в этом обсуждении
"В каком месте IPTABLES работает TC?"
Отправлено tungus , 21-Фев-08 14:19 
http://l7-filter.sourceforge.net/PacketFlow.png

"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 21-Фев-08 15:08 
>http://l7-filter.sourceforge.net/PacketFlow.png

Спасибо tungus.
Получается что ingress qdisc работает вообще до iptables.

Почему тогда работает такой финт:
iptables -t mangle -A PREROUTING -i eth0 -s 192.168.0.1 -j MARK --set-mark 1
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 handle 1 fw police rate 32Kbit burst 4K drop flowid :1

т.е. маркеры я расставляю в iptbales, и согласно их ingress qdisc режет трафик.
Как так получается?


"В каком месте IPTABLES работает TC?"
Отправлено sergey.shkolin , 21-Фев-08 18:22 
>[оверквотинг удален]
>Почему тогда работает такой финт:
>iptables -t mangle -A PREROUTING -i eth0 -s 192.168.0.1 -j MARK --set-mark
>1
>tc qdisc add dev eth0 handle ffff: ingress
>tc filter add dev eth0 parent ffff: protocol ip prio 50 handle
>1 fw police rate 32Kbit burst 4K drop flowid :1
>
>т.е. маркеры я расставляю в iptbales, и согласно их ingress qdisc режет
>трафик.
>Как так получается?

iptables -L -t mangle


"В каком месте IPTABLES работает TC?"
Отправлено tungus , 22-Фев-08 16:57 
>>http://l7-filter.sourceforge.net/PacketFlow.png
>
>Спасибо tungus.
>Получается что ingress qdisc работает вообще до iptables.
>

Да.

>Почему тогда работает такой финт:
>iptables -t mangle -A PREROUTING -i eth0 -s 192.168.0.1 -j MARK --set-mark
>1
>tc qdisc add dev eth0 handle ffff: ingress
>tc filter add dev eth0 parent ffff: protocol ip prio 50 handle
>1 fw police rate 32Kbit burst 4K drop flowid :1
>
>т.е. маркеры я расставляю в iptbales, и согласно их ingress qdisc режет
>трафик.
>Как так получается?

А с чего вы взяли что у вас работает такой финт?
Единственный способ ограничивать скорость входящего трафика используя iptables для классификации - это IMQ : http://www.docum.org/docum.org/kptd/

Даже с ifb http://www.linux-foundation.org/en/Net:IFB неполучится использовать iptables для классификации



"В каком месте IPTABLES работает TC?"
Отправлено tungus , 22-Фев-08 17:05 
>А с чего вы взяли что у вас работает такой финт?
>Единственный способ ограничивать скорость входящего трафика используя iptables для классификации - это
>IMQ : http://www.docum.org/docum.org/kptd/
>
>Даже с ifb http://www.linux-foundation.org/en/Net:IFB неполучится использовать iptables для классификации

Гм. Хотя согласно http://www.docum.org/docum.org/kptd/  "QOS INGRESS" идёт после PREROUTING. Нато будет спросить на lartc mailing list


"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 22-Фев-08 17:57 
>Гм. Хотя согласно http://www.docum.org/docum.org/kptd/  "QOS INGRESS" идёт после PREROUTING. Нато будет спросить на lartc mailing list

Точно, думаю, вот эта блок-схема правильнее будет.


"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 22-Фев-08 18:02 
Но засада в том что, если включен NAT, то пакет в цепочке PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен. А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то и шейпер его пропустит...

А с IMQ намучался уже, никак не могу ядро с ним скомпилировать, то одни ошибки, то другие.


"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 22-Фев-08 19:11 
>Но засада в том что, если включен NAT, то пакет в цепочке
>PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен.
>А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то
>и шейпер его пропустит...
>
>А с IMQ намучался уже, никак не могу ядро с ним скомпилировать,
>то одни ошибки, то другие.

Ядро скомпилировал, но реч не об этом.

Подскажите, а пакет в IMQ уходит, судя по диаграмме, из цепочки PREROUTING?
Значит при включенном NAT'е, пакет будет содержать IP_DEST не истинного владельца.
А раз так, то его не отмаркируешь, и мне толку от IMQ не будет никакого...


"В каком месте IPTABLES работает TC?"
Отправлено tungus , 23-Фев-08 01:12 
>Ядро скомпилировал, но реч не об этом.

Вообще в последнее время информация на http://www.linuximq.net/ давно не обновлялась (хотя 2008-02-18 как раз обновилась) - более актуальные патчи можно найти на mailing list http://tech.groups.yahoo.com/group/linuximq/ (или например на http://www.actusa.net/~linuximq/ )

>
>Подскажите, а пакет в IMQ уходит, судя по диаграмме, из цепочки PREROUTING?
>
>Значит при включенном NAT'е, пакет будет содержать IP_DEST не истинного владельца.
>А раз так, то его не отмаркируешь, и мне толку от IMQ
>не будет никакого...

Смотря как собрано - нужно включить "after NAT in PREROUTING" при сборке ядра

    prompt "IMQ behavior (PRE/POSTROUTING)"
    depends on IMQ
    default IMQ_BEHAVIOR_BB
    help

    This settings defines how IMQ behaves in respect to its
        hooking in PREROUTING and POSTROUTING.

        IMQ can work in any of the following ways:

            PREROUTING   |      POSTROUTING
        -----------------|-------------------
        #1  After NAT    |      After NAT
        #2  After NAT    |      Before NAT
        #3  Before NAT   |      After NAT
        #4  Before NAT   |      Before NAT

        The default behavior is to hook before NAT on PREROUTING
        and after NAT on POSTROUTING (#3).

        This settings are specially usefull when trying to use IMQ
        to shape NATed clients.

        More information can be found at: www.linuximq.net

        If not sure leave the default settings alone.

Попадались так же мне сторонние патчи (не с linuximq.net), где можно указать поведение как параметр модуля imq.ko

У вас кстати какое ядро используется? Не 2.4?



"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 23-Фев-08 08:36 
tungus, спасибо за развернутый ответ!

>У вас кстати какое ядро используется? Не 2.4?

2.6.18-5-686

При компиляци, когда увидел количество опций, ужаснулся.


"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 23-Фев-08 09:21 
На всякий, если кому надо, вот ссылка на IMQFAQ, там как раз сказано как менять точки выхода в IMQ http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/ImqFaq#Can_I_chang...

"В каком месте IPTABLES работает TC?"
Отправлено sire , 25-Дек-08 15:23 
>У вас кстати какое ядро используется? Не 2.4?

А какие с 2.4 могут быть проблемы?


"В каком месте IPTABLES работает TC?"
Отправлено neonman , 28-Май-08 12:51 
>Но засада в том что, если включен NAT, то пакет в цепочке
>PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен.
>А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то
>и шейпер его пропустит...
>
>А с IMQ намучался уже, никак не могу ядро с ним скомпилировать,
>то одни ошибки, то другие.

отработанный НАТ'ом он будет в цепочке mangle FORWARD, вот там то его и отмаркировать ;)


"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 28-Май-08 15:43 
>>Но засада в том что, если включен NAT, то пакет в цепочке
>>PREROUTING идет еще неотработанный NAT'ом, и адрес назначения еще не известен.
>>А раз так, то отмаркировать его нельзя, а нельзя отмаркировать, то
>>и шейпер его пропустит...
>>
>>А с IMQ намучался уже, никак не могу ядро с ним скомпилировать,
>>то одни ошибки, то другие.
>
>отработанный НАТ'ом он будет в цепочке mangle FORWARD, вот там то его
>и отмаркировать ;)

Ага, карман шире ;) А маршрутизировать вы его как собираетесь после этого?


"В каком месте IPTABLES работает TC?"
Отправлено Rom1 , 29-Фев-08 08:06 
Вот трассировка прохождения пакета, от меня (192.168.0.2) в интернет и обратно, через маршрутизатор (192.168.0.1)

eth0 (192.168.0.1) =>
PREROUTING / mangle        192.168.0.2 => 213.180.204.8
PREROUTING / nat        192.168.0.2 => 213.180.204.8
FORWARD / mangle        192.168.0.2 => 213.180.204.8
POSTROUTING / nat        SNAT 192.168.0.2 на 127.62.11.73
=> tun0 (127.62.11.73)

dvb0_1 =>
PREROUTING / mangle        213.180.204.8 => 127.62.11.73
PREROUTING / nat        -нет-
FORWARD / mangle        213.180.204.8 => 192.168.0.2
=> eth0

1. Когда пакет возвращяется, цепочку "PREROUTING / nat" он даже и не проходит, видимо с ним на этом шаге происходит обратная трансляция NAT. Достаточно странно что пакет в этой цепочке не появляется, пусть после трансляции хоть бы всплывал тут...

2. Ядро скомпилировано так, чтобы пакет улетал в IMQ только после POSTROUTING / nat.
Какой глубинный смысл строчки "iptables -t mangle -A PREROUTING -i * -j IMQ --todev 0". Причем именно в _mangle_, если пакет туда попадет уже после PREROUTING / nat ?

3. Получается так, что входящий пакет, который проходит NAT, даже при использовании IMQ, невозможно отмаркировать для нужд шейпера.
Вот если NAT убрать, все получается красиво, если NAT работает, блин не получается...


"В каком месте IPTABLES работает TC?"
Отправлено feducha , 24-Июн-09 13:15 
Приветствую Всех!

Каким образм трасировку прохождения пакета снимали, очень надо), много
вопросов отпадет.