Alguns problemas óbvios que vejo com a configuração do htb.
Primeiro, você não tem um identificador de 1:30, e você deve, dado o default 30 . Talvez você quisesse dizer default 1 ? Isso anexaria todo o tráfego ao classid 1: 1, a menos que a regra anexasse o tráfego a uma classe diferente.
Em terceiro lugar, sua classe com taxa limitada deve ser configurada com um rate definido para a largura de banda garantida que você deseja alocar da classe e o ceil definido para o nível máximo que você permitirá ao usuário. Por exemplo, digamos que você queira dar ao testuser 400kbit de largura de banda garantida, mas se a linha estiver ociosa, deixe-a crescer até a taxa de linha. Defina rate 400kbit e ceil para o que você colocar como taxa para 1: 1. Se você não definir o ceil, o padrão será a taxa.
Em quarto lugar, para atingir seu objetivo de isentar o tráfego FTP, você precisará usar o connmark em vez de apenas marcar. Caso contrário, sua conexão de dados relacionada não será isentada da marca --set 10. O Connmark selecionará corretamente as conexões relacionadas.
Sugiro que as seguintes regras (não testadas!) estão no topo da minha cabeça:
# flush rules out of postrouting so you're not constantly inserting during testing.
iptables -t mangle -F POSTROUTING
iptables -t mangle -X HTB_OUT
# The use of RETURN here is to fall out of our user chain and hit
# -j CONNMARK --save-mark in the POSTROUTING chain.
iptables -t mangle -N HTB_OUT
iptables -t mangle -A HTB_OUT -j MARK --set-mark 30
iptables -t mangle -A HTB_OUT -p tcp --dport 21 -j MARK --set-mark 30
iptables -t mangle -A HTB_OUT -m mark ! --mark 0 -j RETURN
iptables -t mangle -A HTB_OUT -m owner --uid-owner testuser -j MARK --set-mark 10
iptables -t mangle -A HTB_OUT -m mark ! --mark 0 -j RETURN
iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark
iptables -t mangle -A POSTROUTING -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A POSTROUTING -j HTB_OUT
iptables -t mangle -A POSTROUTING -j CONNMARK --save-mark
Então, para tc, algo como o seguinte:
# set a script variable that will represent our line-rate minus some change
CAPRATE=90Mbit
CAP_SUB_400=89Mbit
# clear our qdisc settings for eth0 so we're starting from a clean slate.
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate ${CAPRATE} burst 5k
# this is our capped class:
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 400kbit ceil ${CAPRATE}
# this is our default, catch-all class:
tc class add dev eth0 parent 1:1 classid 1:20 htb rate ${CAP_SUB_400} ceil ${CAPRATE}
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
tc filter add dev eth0 parent 1:0 prio 0 protocol ip handle 10 fw flowid 1:10
Pontos a serem lembrados: A soma de todos os rate s para os filhos imediatos de qualquer pai não deve exceder o pai rate ever. Eu trapaceei um pouco aqui e arredondou a taxa de 1: 20 para 89Mbit ao invés de 89600kbit. Você pode subestimar, mas nunca deve comprometer demais.
As regras do iptables são avaliadas na ordem . Se sua política permitir, as correspondências mais comuns devem aparecer primeiro; A maior parte disso é obviada pelas regras POSTROUTING antes de entrar na cadeia HTB_OUT, mas é uma boa regra prática.
Então, o que é o SFQ para ... é como mexer o pote. O SFQ tenta dar a cada conexão (par de terminais, na verdade) uma parcela justa da largura de banda, então cada segundo perturba as coisas de novo, no caso de muitas conexões terem acabado no mesmo bucket interno (o que é possível devido ao hashing feito em src / dst / portpair). Para mais informações, verifique lartc ou a mancage tc-sfq.