LINUX.ORG.RU
Форум — Admin  

Что за бред с -t mangle PREROUTING ?


0

0

Хочу сделать приоритеты трафика при помощи маркировки:

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -m ipp2p --ipp2p -j MARK --set-mark 11
iptables -t mangle -A PREROUTING -p tcp --sport 80 -j MARK --set-mark 12
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark

iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 11 -j ACCEPT
iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 12 -j ACCEPT



И получаю непонятку с количеством проходящего веб трафика
командой
iptables -t mangle -L -n -v

Счетчик растет медленно, или никак не растет.
Не смотря на то что стянуто 100 мб счетчик увеличился на пару кб.

Машина представляет собой простой шлюз - с интерфейса ETH0 на интерфейс ETH1 форвардит трафик.

Если добавить правила в POSTROUTING ( внимание !!! )

То по 80 порту получаются значения более реальные к жизни и так же и пиринговый трафик большего объема !
Правила вносятся одновременно.

Вот результат :
Chain POSTROUTING (policy ACCEPT 301M packets, 172G bytes)
pkts bytes target prot opt in out source destination

56776 22M ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
MARK match 0xb
58418 74M ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
MARK match 0xc

Chain PREROUTING (policy ACCEPT 65M packets, 24G bytes)
pkts bytes target prot opt in out source destination

481K 255M CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0
CONNMARK restore
184K 128M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match !0x0
22440 2864K MARK all -- * * 0.0.0.0/0 0.0.0.0/0
ipp2p v0.8.2 --ipp2p MARK set 0xb
1360 84711 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:80 MARK set 0xc
23793 2947K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0
MARK match !0x0 CONNMARK save


Почему такое различе ?! Машина только форвардом занимается и самостоятельно не генерирует никак трафик, так откуда различие в количестве пришедшего трафика и исх трафика ?

anonymous
← plesk
Можно ли временно не очищать дисковый кэш →

Эх, ну вот результат так может нагляднее :

Chain POSTROUTING (policy ACCEPT 301M packets, 172G bytes) pkts bytes target prot opt in out source 56776 22M ACCEPT all -- * eth1 0.0.0.0/0 58418 74M ACCEPT all -- * eth1 0.0.0.0/0

Chain PREROUTING (policy ACCEPT 65M packets, 24G bytes) pkts bytes target prot opt in out source 481K 255M CONNMARK all -- * * 0.0.0.0/0 184K 128M ACCEPT all -- * * 0.0.0.0/0 22440 2864K MARK all -- * * 0.0.0.0/0 1360 84711 MARK tcp -- * * 0.0.0.0/0 23793 2947K CONNMARK all -- * * 0.0.0.0/0

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

йо мае ;)

Chain POSTROUTING (policy ACCEPT 301M packets, 172G bytes) pkts bytes target prot opt in out source 56776 22M ACCEPT all -- * eth1 0.0.0.0/0 58418 74M ACCEPT all -- * eth1 0.0.0.0/0

Chain PREROUTING (policy ACCEPT 65M packets, 24G bytes) pkts bytes target prot opt in out source 481K 255M CONNMARK all -- * * 0.0.0.0/0 184K 128M ACCEPT all -- * * 0.0.0.0/0 22440 2864K MARK all -- * * 0.0.0.0/0 1360 84711 MARK tcp -- * * 0.0.0.0/0 23793 2947K CONNMARK all -- * * 0.0.0.0/0

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

йо мае ;)

Chain POSTROUTING (policy ACCEPT 301M packets, 172G bytes)
pkts bytes target prot opt in out source
56776 22M ACCEPT all -- * eth1 0.0.0.0/0
58418 74M ACCEPT all -- * eth1 0.0.0.0/0

Chain PREROUTING (policy ACCEPT 65M packets, 24G bytes)
pkts bytes target prot opt in out source
481K 255M CONNMARK all -- * * 0.0.0.0/0
184K 128M ACCEPT all -- * * 0.0.0.0/0
22440 2864K MARK all -- * * 0.0.0.0/0
1360 84711 MARK tcp -- * * 0.0.0.0/0
23793 2947K CONNMARK all -- * * 0.0.0.0/0

anonymous
()

Сделайте, все таки, iptables -t mangle -L -n -v и покажите сдесь, будет понятнее, откуда такие различия...

Пока, похоже, что машина генерит достаточно много тарфика. Может ей по локальному интерфейсу приходит много "мусора" и она на него отвечает. Можно во все цепочки -t mangle добавить правила -i eth0 и -i eth1, а в POSTROUTING и OUTPUT еще и -o eth0 и -o eth1 (просто счетчики, без -j ACCEPT) и подождать хотя бы несколько часов. А, потом если выяснить интерфейс, по которому много в OUTPUT, посмотреть его tcpdump.

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

Chain FORWARD (policy ACCEPT 326M packets, 183G bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain INPUT (policy ACCEPT 249K packets, 114M bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 271K packets, 172M bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain POSTROUTING (policy ACCEPT 306M packets, 174G bytes)
 pkts bytes target     prot opt in     out     source               destination

 591K  162M ACCEPT     all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
        MARK match 0xb
 514K  578M ACCEPT     all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
        MARK match 0xc

Chain PREROUTING (policy ACCEPT 69M packets, 26G bytes)
 pkts bytes target     prot opt in     out     source               destination

6360K 3183M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0
        CONNMARK restore
1734K 1069M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
        MARK match !0x0
 289K   36M MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0
        ipp2p v0.8.2 --ipp2p MARK set 0xb
20797 1024K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
        tcp spt:80 MARK set 0xc
 310K   37M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0
        MARK match !0x0 CONNMARK save


Я пробывал с -i eth и -o eth , результат тот же.

Парадокс в том что в PREROUTING трафика _МЕНЬШЕ_ чем в POSTROITING

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

Если смотреть тот вывод, который вы превели, то в PREROUTING попало 3183M, а в POSTROUTING неизвестно сколько (через eth1 ушло как минимум 162M + 578M). Те цифры, которые показываются в строке с названием цепочки относятся к policy, то есть если пакет дошел до конца цепочки (не попал в ACCEPT/DROP) и его дальнейшая судьба определяется политикой, то он увеличивает этот счетчик. Стирая правило в уничтожаете счетчик. Подозреваю, что вы нескольно раз добавляли/удаляли правила -j ACCEPT в разные цепочки, поэтому по policy счетчикам у вас такие не совпадения

PREROUTING << POSTROUTING < FORWARD

Еще раз прошу, сделайте:

for i in FORWARD INPUT OUTPUT POSTROUTING PREROUTING ; do iptables -t mangle -I $i ; done

подождите час и покажите вывод iptables -t mangle -L -n -v -x

P.S. Сообщите версию ядра

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

POLICY различается и сильно, ну не он меня в первую очередь беспокоит !

А именно счетчики правил в прероутинге и построутинг.

Т.е. промаркировав пакеты --sport 80 ( веб трафик ) мы получаем различие в количестве трафика который мы промаркировали в прероутинге и затем который отразили в маркировке а построутинге.

Почему на машине которая занимается только forward'ом такие различия ?

Я оставил ТОЛЬКО маркировку веб трафика - и к концу дня получил расхождение уже почти в 100 мб трафика.

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

ВОТ:

Chain FORWARD (policy ACCEPT 524M packets, 291G bytes) pkts bytes target prot opt in out source destination

13M 6145M all -- * * 0.0.0.0/0 0.0.0.0/0

Chain INPUT (policy ACCEPT 256K packets, 115M bytes) pkts bytes target prot opt in out source destination

86 3519 all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 287K packets, 175M bytes) pkts bytes target prot opt in out source destination

99 24338 all -- * * 0.0.0.0/0 0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 473M packets, 253G bytes) pkts bytes target prot opt in out source destination

13M 6145M all -- * * 0.0.0.0/0 0.0.0.0/0

0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0xb 0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0xc 9250K 11G ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0xd 0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0xe 0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0 MARK match 0x28

Chain PREROUTING (policy ACCEPT 242M packets, 116G bytes) pkts bytes target prot opt in out source destination

13M 6145M all -- * * 0.0.0.0/0 0.0.0.0/0

9323K 11G MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 MARK set 0xd

И какой вывод ?

Можно достаточно уверено утверждать что ваши правила совпадают,(за час) однако по -x есть различие по маркировке трафика с 80 порта примерно на 100 мб :( Которые набрались за сутки.

Так почему же тогда так происходит ? Особенно с промаркированым трафиком командами выше. И что делать ? Как маркировать в прероутинге то... Это для QoS нужно промаркировать ....

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

ВОТ:

Chain FORWARD (policy ACCEPT 524M packets, 291G bytes)
pkts bytes target prot opt in out source destination

13M 6145M all -- * * 0.0.0.0/0 0.0.0.0/0


Chain INPUT (policy ACCEPT 256K packets, 115M bytes)
pkts bytes target prot opt in out source destination

86 3519 all -- * * 0.0.0.0/0 0.0.0.0/0


Chain OUTPUT (policy ACCEPT 287K packets, 175M bytes)
pkts bytes target prot opt in out source destination

99 24338 all -- * * 0.0.0.0/0 0.0.0.0/0


Chain POSTROUTING (policy ACCEPT 473M packets, 253G bytes)
pkts bytes target prot opt in out source destination

13M 6145M all -- * * 0.0.0.0/0 0.0.0.0/0

0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
MARK match 0xb
0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
MARK match 0xc
9250K 11G ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
MARK match 0xd
0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
MARK match 0xe
0 0 ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
MARK match 0x28

Chain PREROUTING (policy ACCEPT 242M packets, 116G bytes)
pkts bytes target prot opt in out source destination

13M 6145M all -- * * 0.0.0.0/0 0.0.0.0/0

9323K 11G MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0
tcp spt:80 MARK set 0xd

И какой вывод ?

Можно достаточно уверено утверждать что ваши правила совпадают,(за час) однако по -x есть различие по маркировке трафика с 80 порта примерно на 100 мб :( Которые набрались за сутки.

Так почему же тогда так происходит ? Особенно с промаркированым трафиком командами выше. И что делать ? Как маркировать в прероутинге то... Это для QoS нужно промаркировать ....

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

За час 6145М, за сутки 147480М, 100 М от этого объема составляет 0,067%, лично я бы забил, хотя можно попробовать покопать дальше.

Во первых, машина занимаеться только маршрутизацией и QoS, никакого SNAT и DNAT на ней нету. MTU на интерфейсах одинаковые 1500 (никаких jumbo-frames нету). Я правильно понял?

Для начала можно в POSTROUTING сделать два правила --- одно MARK match 0xd, а другое tcp spt:80. Там будет видно, может просто часть пакетов ошибочно маркируется... Еще можно попробовать выключить QoS или маркировку пакетов. Я вполне допускаю наличие ошибки в очередях, изредка дающей дублирующие пакеты.

P.S. Еще раз, какая версия ядра?

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← plesk
Admin
Можно ли временно не очищать дисковый кэш →