Ad@m pisze:To markowane są tylko połączenia a p2p już nie i leci do kolejki, usera
Natomiast, jeśli przestawię regułki user pod p2p to jest odwrotnie, wszystko leci do p2p
W tym wypadku istotnie tak będzie, gdyż reguły iptables są przetwarzane z góry do dołu.
Najpierw te, które pierwsze pojawią się w skrypcie, a skrypt jest przetwarzany z góry na dół
Ja "wrzucanie" do odpowiednich klas realizuję w podobny, lecz minimalnie inny sposób.
Mianowicie. Tam, gdzie się da, używam filtrów polecenia tc. Wrzucanie ruchu do konkretnego ip'ika można zrealizować za pomocą takiego filtra, i to wychodzi lepiej niż na pomocą markowania pakietów, czy połączeń w iptables. Unika się zależności od kolejności przetwarzania poleceń iptables (jak w Twoim wypadku). Oczywiście jest ruch, np. p2p, media streamowe itd., dla którego nie ustawimy odpowiednich reguł pasujących filtra i wtedy jesteśmy zmuszeni używać narzędzi ipp2p lub layer7 wraz z MARK lub/i CONNMARK.
U ciebie wystąpił przypadek, gdzie użytkownik uruchamia program p2p i de facto pakiety generowane przez jego komputer pasują zarówno do -d JEGO_IP jak również do -m ipp2p --ipp2p. I na tym, jak sądzę, polega problem.
Ja mam zrobione tak:
Kod: Zaznacz cały
# Przekierowanie do imq0 - download
iptables -t mangle -A PREROUTING -i $INTERNET_INTERFACE -j IMQ --todev 0
# Markowanie P2P
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m ipp2p --ipp2p -j MARK --set-mark 0x20
iptables -t mangle -A PREROUTING -m mark --mark 0x20 -j CONNMARK --save-mark
iptables -t mangle -A POSTROUTING -m mark --mark 0x20 -j RETURN
# właściwe klasy "łapiące" ruch pochodzący od usera (1) oraz ruch z p2p (2)
# (1)
tc class add dev imq0 parent 1:1 classid 1:10 htb rate ${USER_RATE}kbit ceil ${USER_CEIL}kbit
tc qdisc add dev imq0 parent 1:10 sfq perturb 5
tc filter add dev imq0 parent 1:0 protocol ip prio 2 u32 match ip dst $USER_IP flowid 1:30
# (2)
tc class add dev imq0 parent 1:1 classid 1:20 htb rate ${DOWN_RATE_P2P}kbit ceil ${DOWN_CEIL_P2P}kbit
tc qdisc add dev imq0 parent 1:20 esfq perturb 10 hash dst
tc filter add dev imq0 parent 1:0 protocol ip prio 1 handle 0x20 fw flowid 1:20
Cały figiel, do której klasy mają trafiać określone pakiety, jeśli pasują i do użytkownika i do ruchu p2p określa parametr
prio w filtrze. Im mniejsza liczba prio tym większy priorytet. Na powyższym przykładzie pakiety p2p, które pochodzą od "pasującego" użytkownika trafią do klasy p2p. I odwrotnie. Jeśli w powyższym przykładzie zamienisz prio 1 na prio 2 w pierwszym filtrze i vice versa w drugim, uzyskasz odwrotny efekt, w którym pakiety ruchu p2p trafią do klasy wydzielonej dla użytkownika.
Pozdrawiam
vitos