Помогите настроить iproute2
LinAdmin 7 декабря, 2011 - 14:20
Всем привет!
Я настроил шейпер на маршрутизаторе при помощи классификатора u32, вот настройки:
HOSTROUTER_1 ~ # cat rc.traffic EXT_IF=ifb0 INT_IF=eth1 # Flush all rules tc qdisc del dev ${INT_IF} root tc qdisc del dev ${EXT_IF} root rmmod ifb # Create shaper modprobe ifb ip link set dev ifb0 up tc qdisc add dev ${INT_IF} ingress tc filter add dev ${INT_IF} parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ${EXT_IF} tc qdisc add dev ${INT_IF} root handle 1: htb tc qdisc add dev ${EXT_IF} root handle 1: htb tc class add dev ${INT_IF} parent 1: classid 1:1 htb rate 100Mbit ceil 100Mbit tc class add dev ${EXT_IF} parent 1: classid 1:1 htb rate 100Mbit ceil 100Mbit tc class add dev ${INT_IF} parent 1:1 classid 1:10 htb rate 100Mbit ceil 100Mbit tc class add dev ${EXT_IF} parent 1:1 classid 1:10 htb rate 100Mbit ceil 100Mbit tc class add dev ${INT_IF} parent 1:1 classid 1:20 htb rate 50Mbit ceil 100Mbit tc class add dev ${EXT_IF} parent 1:1 classid 1:20 htb rate 50Mbit ceil 100Mbit # tc filter add dev ${INT_IF} parent 1:0 protocol ip prio 2 u32 match ip protocol 6 0xff match ip dport 20 0xffff flowid 1:20 # tc filter add dev ${EXT_IF} parent 1:0 protocol ip prio 2 u32 match ip protocol 6 0xff match ip sport 20 0xffff flowid 1:20 # tc filter add dev ${INT_IF} parent 1:0 protocol ip prio 2 u32 match ip protocol 6 0xff match ip dport 21 0xffff flowid 1:20 # tc filter add dev ${EXT_IF} parent 1:0 protocol ip prio 2 u32 match ip protocol 6 0xff match ip sport 21 0xffff flowid 1:20 classint=1000 classext=1000 IFS='\|' psql -A -t -U billinger -d billingv3 -c "SELECT ip, mac FROM billing;" | while read ip mac do let "classint += 1" let "classext += 1" tc class add dev ${INT_IF} parent 1:10 classid 1:${classint} htb rate 256Kbit ceil 1024Kbit burst 16k tc class add dev ${EXT_IF} parent 1:10 classid 1:${classext} htb rate 256Kbit ceil 1024Kbit burst 16k tc filter add dev ${INT_IF} parent 1:0 protocol ip prio 1 u32 match ip dst ${ip} match ip protocol 6 0xff match ip dport 20 0xffff flowid 1:20 tc filter add dev ${EXT_IF} parent 1:0 protocol ip prio 1 u32 match ip src ${ip} match ip protocol 6 0xff match ip sport 20 0xffff flowid 1:20 tc filter add dev ${INT_IF} parent 1:0 protocol ip prio 1 u32 match ip dst ${ip} match ip protocol 6 0xff match ip dport 21 0xffff flowid 1:20 tc filter add dev ${EXT_IF} parent 1:0 protocol ip prio 1 u32 match ip src ${ip} match ip protocol 6 0xff match ip sport 21 0xffff flowid 1:20 tc filter add dev ${INT_IF} parent 1:0 protocol ip prio 2 u32 match ip dst ${ip} flowid 1:${classint} tc filter add dev ${EXT_IF} parent 1:0 protocol ip prio 2 u32 match ip src ${ip} flowid 1:${classext} done
Все работает замечательно, но появилась необходимость выделить FTP трафик в отдельный канал на полной скорости, для этого я создал класс 1:20, но проблема в том, что пакеты в него не идут, я даже не представляю как сделать так, чтобы пакеты шли куда надо. На LARTC я к сожалению ответа не нашел, а через iptables делать не хочется.
»
- Для комментирования войдите или зарегистрируйтесь
Теперь я приведу несколько
Advanced Routing
В этой статье приводится пример как реализовать весь трафик через одного провайдера, а определенный траффик (в данном случае smtp)заворачивать на другого.
Мне кажется вам это должно подойти.
FTP трафик это протокол с
FTP трафик это протокол с многими портами (управляющий 21 - да вы это все знаете). Тебе нужно загрузить ftp connection helper for state machine и отлавливать трафик который будет state machine помечать как RELATED - помечаешь его и заворачиваешь в твою трубу (шейпер). Как видишь и здесь нет никаких проблемм.
А можешь привезти пример, а
А можешь привезти пример, а то не совсем понятно...
Если ничего не помогает, прочти наконец инструкцию...
А что именно? 1. Как работает
А что именно?
1. Как работает FTP (уж поверь мне многие не знают, с пеной во рту утверждая что у них все работает ...)
2. Правило iptables чтобы отловить состояние RELATED?
3. Активировать и загрузить модуль nf_conntrack_ftp?
В общем пример покажи
В общем пример покажи пожалуйста. И можно ли обойтись только утилитой iproute2? Если нельзя обойтись только утилитой iproute2, то любой другой метод подойдет. Я пытался сделать вот так:
То есть я направил все пакеты которые идут на 20 и 21 порты в класс 1:20. К сожалению эта схема не заработала...
Если ничего не помогает, прочти наконец инструкцию...
ОКtc filter add dev
ОК
tc filter add dev ${INT_IF} parent 1:0 protocol ip prio 1 u32 match ip dst ${ip} match ip dport 20 0xffff flowid 1:20
tc filter add dev ${EXT_IF} parent 1:0 protocol ip prio 1 u32 match ip src ${ip} match ip sport 20 0xffff flowid 1:20
tc filter add dev ${INT_IF} parent 1:0 protocol ip prio 1 u32 match ip dst ${ip} match ip dport 21 0xffff flowid 1:20
tc filter add dev ${EXT_IF} parent 1:0 protocol ip prio 1 u32 match ip src ${ip} match ip sport 21 0xffff flowid 1:20
По этим правилам должен перехватываться трафик:
1) идущий во внутренную сеть на 20 порт
2) исходящий из внутренней сети из 20 порта
3) идущий внутренную сеть на управляющий FTP порт
4) исходящий из внутренней сети, из управляющего FTP порта
То есть правила описывают трафик ftp, как если бы FTP сервак находился во внутренней сети. Вопрос - это так? Второй вопрос - 20 порт. Откуда такая уверенность в ней?
Ну и до кучи tcpdump -n -i ${INT_IF} port 20 что нибудь кажет?
Нет, FTP сервер находится во
Нет, FTP сервер находится во внешней сети и на самом шлюзе, надо сделать так чтобы этот FTP трафик шел через класс 1:20. 20-й порт нужен для пассивного режима работы FTP. tcpdump ничего не говорит на 20 порту, так как все FTP работают в активном режиме, я оставил эту опцию для совместимости, если попадется какой нибудь FTP который будет работать в пассивном режиме.
Если ничего не помогает, прочти наконец инструкцию...
вот еще ляпы: 5) Правила 2 и
вот еще ляпы:
5) Правила 2 и последнее - не правильны в корне! Причиной тому - скорее всего у вас работает SNAT. Можешь догадаться почему у исходящего наружу трафика не будет клиентских ${ip}?
а в виду последнего сообщения первый и третий правила тоже бесполезны.
Можете написать как должно
Можете написать как должно быть, а то я уже все перепробовал и у меня что то не работает... Хорошо бы весь трафик направлять в отдельную трубу до того как он попадает в классы шейпера пользовательского трафика, чтобы не писать для каждого пользователя по 4 лишних правила. Да, вы правы у меня работает NAT, но я использую IFB интерфейс для того чтобы можно было оперировать клиентскими IP адресами при использовании NAT.
Если ничего не помогает, прочти наконец инструкцию...