HTB, ipp2p i ograniczanie P2P - problem

Serwery i sieci oparte na Slackware, wszelkiego rodzaju usługi, troubleshooting.

Moderatorzy: Moderatorzy, Administratorzy

Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

HTB, ipp2p i ograniczanie P2P - problem

Post autor: aksnet » 2009-08-26, 14:03

Witam.

Pracuje nad ograniczeniem downloadu P2P (ograniczeniem prędkości a nie zablokowaniem).


Każdemu adresowi IP przydzielam 1000kbit downloadu z internetu i 500 kbit do połączeń z serwerem lokalnym
(lokalna strona www, pliki). Jak widać w konfiguracji najpierw wyłapuję pakiety pochodzące
z sieci lokalnej 10.0.0.0/20 (papametr preference 1) a w drugiej kolejności pakiety nie pochodzące
z sieci lokalnej (preference 2) są kolejkowane jako downlad z internetu.
Wszystko wielokrotnie testowanie i działa bez zastrzeżeń.

Obecnie mam taki podział pasma:

Kod: Zaznacz cały

# -----------------DOWNLOAD --------------------
# kasujemy poprzednie kolejkowanie 
tc qdisc del root dev imq0 2> /dev/null 
# tworzymy nowa kolejke glowna 
tc qdisc add dev imq0 root handle 1:0 htb 
# calkowity download 
tc class add dev imq0 parent 1:0 classid 1:1 htb rate 2648kbit ceil 2648kbit 
# download z serwera lan 
tc class add dev imq0 parent 1:1 classid 1:2 htb rate 600kbit ceil 600kbit 
# download z internetu 
tc class add dev imq0 parent 1:1 classid 1:3 htb rate 2048kbit ceil 2048kbit 

# pasmo dla poszczegolnych uzytkownikow 

#z serwera LAN: 
tc class add dev imq0 parent 1:2 classid 1:1001 htb rate 50kbit ceil 500kbit quantum 5120
tc filter add dev imq0 protocol ip preference 1 parent 1:0 u32 match ip src 10.0.0.0/20 match ip dst 10.0.1.1 flowid 1:1001
tc qdisc add dev imq0 parent 1:1001 handle 1001:0 sfq perturb 10
#z internetu: 
tc class add dev imq0 parent 1:3 classid 1:2001 htb rate 200kbit ceil 1000kbit quantum 20480
tc filter add dev imq0 protocol ip preference 2 parent 1:0 u32 match ip dst 10.0.1.1 flowid 1:2001
tc qdisc add dev imq0 parent 1:2001 handle 2001:0 sfq perturb 10


#analogicznie dla następnych adresów IP ...

Ponieważ łącze zaczyna zapychać P2P wiec obecną konfigurację postanowiłem rozbudować o
osobne pasmo przeznaczone na ruch P2P (na razie moduł ipp2p, a potem rozszerzę o 7layer)
Klasa 1:3 ma 300kbit na P2P dla całej sieci.
Każdy użytkownik może pociągnąć max 200kbit p2p. Mam problem z wyfiltrowaniem tego
ruchu i skierowaniem go do odpowiedniej kolejki.

Testowałem skrypt jak poniżej, ale nie udaje mi wyfiltrować pakietów
p2p oznaczonych jako 1.

Kod: Zaznacz cały


# kasujemy znaczenie pakietow  
iptables -t mangle -F PREROUTING 
# znaczymy pakiety P2P 
iptables -t mangle -A PREROUTING -m ipp2p --ipp2p -j MARK --set-mark 1 


# -----------------DOWNLOAD --------------------
# kasujemy poprzednie kolejkowanie 
tc qdisc del root dev imq0 2> /dev/null 
# tworzymy nowa kolejke glowna 
tc qdisc add dev imq0 root handle 1:0 htb 
# calkowity download 
tc class add dev imq0 parent 1:0 classid 1:1 htb rate 2648kbit ceil 2648kbit 
# download z serwera lan 
tc class add dev imq0 parent 1:1 classid 1:2 htb rate 600kbit ceil 600kbit 
# download P2P z internetu 
tc class add dev imq0 parent 1:1 classid 1:3 htb rate 300kbit ceil 300kbit 
# download z internetu (bez P2P) 
tc class add dev imq0 parent 1:1 classid 1:4 htb rate 1748kbit ceil 1748kbit 

# pasmo dla poszczegolnych uzytkownikow 

#z serwera LAN: 
tc class add dev imq0 parent 1:2 classid 1:1001 htb rate 50kbit ceil 500kbit quantum 5120
tc filter add dev imq0 protocol ip preference 1 parent 1:0 u32 match ip src 10.0.0.0/20 match ip dst 10.0.1.1 flowid 1:1001
tc qdisc add dev imq0 parent 1:1001 handle 1001:0 sfq perturb 10
#z internetu (tylko P2P): 
tc class add dev imq0 parent 1:3 classid 1:2001 htb rate 10kbit ceil 200kbit quantum 1700
tc filter add dev imq0 protocol ip preference 2 parent 1:0 u32 handle 1 match ip dst 10.0.1.1 flowid 1:2001
tc qdisc add dev imq0 parent 1:2001 handle 2001:0 sfq perturb 10
#z internetu: 
tc class add dev imq0 parent 1:4 classid 1:3001 htb rate 200kbit ceil 1200kbit quantum 20480
tc filter add dev imq0 protocol ip preference 3 parent 1:0 u32 match ip dst 10.0.1.1 flowid 1:3001
tc qdisc add dev imq0 parent 1:3001 handle 3001:0 sfq perturb 10


#analogicznie dla następnych adresów IP ...

linia:

Kod: Zaznacz cały

tc filter add dev imq0 protocol ip preference 2 parent 1:0 u32 handle 1 match ip dst 10.0.1.1 flowid 1:2001
powinna wyłapać pakiety p2p (polecenie handle 1) skiedowane do IP 10.0.1.1,
ale zwraca mi błąd i nie wiem jak to obejść:

Dodam IMQ jest skompilowane z opcją BB (postrouting i preroiting before NAT)
Może powinno być AB ???
Jak uruchomić powyższy podział pasma???


Myślę także o ustawieniu ruchu p2p z niższym priorytetem, aby nie ustawiać p2p na sztywno
(tak jak teraz 300kbit) ale aby pasmo p2p było przydzielane dynamicznie z pasma aktualnie niewykorzystanego.

Będę wdzięczny za wszelkie porady, a zwłaszcza działające przykłady, które mógłbym przerobić.


aksnet

Awatar użytkownika
bzyk
Moderator w st. spocz.
Posty: 991
Rejestracja: 2004-06-05, 06:32
Lokalizacja: Pszczyna
Kontakt:

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: bzyk » 2009-08-27, 03:49

Pokaż iptables -L -t mangle
In /dev/null no one can hear you scream.

Awatar użytkownika
bojleros
Użytkownik
Posty: 785
Rejestracja: 2005-08-29, 11:12
Lokalizacja: z widokem na familoki :)
Kontakt:

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: bojleros » 2009-08-27, 18:29

aksnet pisze:Każdy użytkownik może pociągnąć max 200kbit p2p. Mam problem z wyfiltrowaniem tego
ruchu i skierowaniem go do odpowiedniej kolejki.
Ipp2p jest stare i łapie mało protokołów. Lepiej od razu zajmij się layer7. Nie jest to jednak rozwiązanie wszystkich problemów bo niektóre protokoły nie dają się jednoznacznie dopasować (zobacz sobie na stronie definicje dla torrent lub skype*). W efekcie będzie tak że część p2p poleci do klas jakie na nie przewidziałeś a część nie :/
aksnet pisze: Dodam IMQ jest skompilowane z opcją BB (postrouting i preroiting before NAT)
Może powinno być AB ???
Ja mam na AB i nie ma problemu z wyłapywaniem po markach w obydwu kierunkach. Całkiem możliwe że tutaj masz błąd.
Ostatnio zmieniony 2009-08-27, 18:34 przez bojleros, łącznie zmieniany 1 raz.

Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: aksnet » 2009-08-27, 21:10

wynik polecenia:
iptables -L -t mangle

Kod: Zaznacz cały

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
MARK       all  --  anywhere             anywhere            ipp2p v0.8.2 --ipp2p MARK set 0x1 
MARK       all  --  10.0.1.1             anywhere            MARK set 0x1389 
MARK       all  --  10.0.1.2             anywhere            MARK set 0x138a 
MARK       all  --  10.0.1.3             anywhere            MARK set 0x138b 
MARK       all  --  10.0.1.4             anywhere            MARK set 0x138c 
MARK       all  --  10.0.1.5             anywhere            MARK set 0x138d 
MARK       all  --  10.0.1.6             anywhere            MARK set 0x138e 
MARK       all  --  10.0.1.7             anywhere            MARK set 0x138f 
MARK       all  --  10.0.1.8             anywhere            MARK set 0x1390 
MARK       all  --  10.0.1.9             anywhere            MARK set 0x1391 
MARK       all  --  10.0.1.10            anywhere            MARK set 0x1392 
MARK       all  --  10.0.1.11            anywhere            MARK set 0x1393 
MARK       all  --  10.0.1.12            anywhere            MARK set 0x1394 
MARK       all  --  10.0.1.13            anywhere            MARK set 0x1395 
MARK       all  --  10.0.1.14            anywhere            MARK set 0x1396 
MARK       all  --  10.0.1.15            anywhere            MARK set 0x1397 
MARK       all  --  10.0.1.16            anywhere            MARK set 0x1398 
MARK       all  --  10.0.1.17            anywhere            MARK set 0x1399 
MARK       all  --  10.0.1.18            anywhere            MARK set 0x139a 
MARK       all  --  10.0.1.19            anywhere            MARK set 0x139b 
MARK       all  --  10.0.1.20            anywhere            MARK set 0x139c 
MARK       all  --  10.0.1.21            anywhere            MARK set 0x139d 
MARK       all  --  10.0.1.22            anywhere            MARK set 0x139e 
MARK       all  --  10.0.1.23            anywhere            MARK set 0x139f 
MARK       all  --  10.0.1.24            anywhere            MARK set 0x13a0 
MARK       all  --  10.0.1.25            anywhere            MARK set 0x13a1 
MARK       all  --  10.0.1.26            anywhere            MARK set 0x13a2 
MARK       all  --  10.0.1.27            anywhere            MARK set 0x13a3 
MARK       all  --  10.0.1.28            anywhere            MARK set 0x13a4 
MARK       all  --  10.0.1.29            anywhere            MARK set 0x13a5 
MARK       all  --  10.0.1.30            anywhere            MARK set 0x13a6 

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
IMQ        all  --  anywhere             anywhere            IMQ: todev 0 
wyjaśnię ze markowanie PREROUTING dla 10.0.1.1 - 10.0.1.30 jest robione
dla ruchu UPLOAD (HTB dla uploadu jest robione tradycyjnie na eth0 przez markowanie pakietów i bez użycia IMQ) IMQ używam z konieczności dla DOWNLOADU ponieważ mam autoryzację PPPoE.

Czy markowanie dla 10.0.1.1 - 10.0.1.30 nadpisuje pierwsze marki ipp2p ?

Podstawowe pytanie:
------------------------
Markowanie pakietów ipp2p dla downloadu powinno być robione w PREROUTING czy może w POSTROUTING ?

Czy filtrowanie tych pakietów powinno być w POSTROUTING ponieważ przekierowanie do IMQ jest w POSTROUTING ?


Wyświetlenie tabeli mangle daje do myślenia. Dzięki za podpowiedź dla Bzyka.
Może jakiś działający i nieokrojony przykład ktoś wklei ???

aksnet
Ostatnio zmieniony 2009-08-27, 21:41 przez aksnet, łącznie zmieniany 2 razy.

Awatar użytkownika
xil
Moderator
Posty: 861
Rejestracja: 2004-06-20, 22:20
Lokalizacja: Białystok
Kontakt:

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: xil » 2009-08-27, 21:54

w tabeli mangle nie wygrywa pierwszy 'trafiony', ale ostatni.
w Twoim wypadku caly ruch pojdzie w kolejki userow bez wzgledu na to, czy ipp2p to wykryl, czy nie.

dodaj po regule:

Kod: Zaznacz cały

MARK       all  --  anywhere             anywhere            ipp2p v0.8.2 --ipp2p MARK set 0x1
taka sama z -j RETURN, co zamknie Ci lancuch.

EDIT:
uzywaj iptables -t mangle -nvL
Ostatnio zmieniony 2009-08-27, 21:58 przez xil, łącznie zmieniany 1 raz.

Awatar użytkownika
bzyk
Moderator w st. spocz.
Posty: 991
Rejestracja: 2004-06-05, 06:32
Lokalizacja: Pszczyna
Kontakt:

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: bzyk » 2009-08-28, 06:08

Poczytaj o connmark. bez tego nic z blokowania p2p nie będzie.
In /dev/null no one can hear you scream.

Awatar użytkownika
bojleros
Użytkownik
Posty: 785
Rejestracja: 2005-08-29, 11:12
Lokalizacja: z widokem na familoki :)
Kontakt:

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: bojleros » 2009-08-28, 09:57

aksnet pisze:Markowanie pakietów ipp2p dla downloadu powinno być robione w PREROUTING czy może w POSTROUTING ?
Zależy czy download ksztaltujesz jako ruch przychodzący interfejsu internetowego (IMQ) czy jako ruch wychodzący interfejsu LAN. W pierwszym przypadku będzie to PREROUTING a w drugim może to być FORWARD lub POSTROUTING.

http://www.docum.org/docum.org/kptd/
Pakiet porusza się z góry na dół grafu.
aksnet pisze:Czy filtrowanie tych pakietów powinno być w POSTROUTING ponieważ przekierowanie do IMQ jest w POSTROUTING ?
Jeżeli przez filtrowanie rozumiesz nadawanie marków to powinieneś to robić w łańcuchu odpowiadającemu kierunkowi przesyłu danych. Zobacz kptd! Pakiet od ściągania pokaże się najpierw w PREROUTINGU na interfejsie internetowym , dalej przejdzie przez FORWARD aby na końcu pokazać się na POSTROUTINGu interfejsu sieci lokalnej. W drugą stronę jest inaczej. Pakiet najpierw pojawia się w PREROUTINGU interfejsu lan, dalej przechodzi przez FORWARD a na końcu zalicza POSTROUTING na interfejsie internetowym.

Patrz na graf !

Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: aksnet » 2009-08-29, 14:45

bzyk pisze:Poczytaj o connmark. bez tego nic z blokowania p2p nie będzie.
Dokładnie tak jak pisze Bzyk.

Przez pół nocy kombinowałem myśląc że da się i bez connmark.
Zapuściłem testowo torrenta (i nic więcej). Znaczyłem pakiety P2P i o dziwo
markowanych przez ipp2p pakietów było bardzo mało w stosunku do wszystkich
przechodzących pakietów (dla mojego IP). Pogrzebałem w sieci z nalazłem wyjaśnienie:
(wklejam dla potomnych którzy będą kiedyś walczyli z tym samym problemem)
... "Zauważcie, że nawet autorzy ipp2p twierdzą, że moduł ten ma "match"
czyli trafienie tylko dla pakietów _charakterystycznych_ dla danego
protokołu, a przecież cały flow nie składa się z tylko takich
pakietów. Stosując takie MARKi markujecie właśnie tylko pakiety
charakterystyczne, a jak markujecie tylko takie pakiety to tylko one
zostają poddane dalszej "obróbce" w QoS. Markować trzeba ale cały
flow, całe połączenie - do czego służy moduł CONNMARK (btw. też o
nim napisali autorzy ipp2p...)..."

autor: Bartek Krawczyk
aksnet
Ostatnio zmieniony 2009-08-29, 16:26 przez aksnet, łącznie zmieniany 1 raz.

Awatar użytkownika
bojleros
Użytkownik
Posty: 785
Rejestracja: 2005-08-29, 11:12
Lokalizacja: z widokem na familoki :)
Kontakt:

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: bojleros » 2009-08-29, 15:41

Z tego co wiem to layer7 jest już wyposażone w taki mechanizm ... Jeżeli się mylę to proszę o informację bo sam jestem zainteresowany :)

Co do torrenta to zauważyłem że połączenia nieszyfrowane mniej więcej trafiają mi do odpowiednich klas , gorzej z połączeniami szyfrowanymi .....

Awatar użytkownika
webster
Użytkownik
Posty: 1265
Rejestracja: 2009-10-06, 11:58
Lokalizacja: Gdańsk
Kontakt:

Re: HTB, ipp2p i ograniczanie P2P - problem

Post autor: webster » 2009-10-20, 09:06

nie lepiej wycinac lacze w zaleznosci od sport ? a nie bawic sie w markowanie?

Kod: Zaznacz cały

LAN=ETH_WCHODZACE
MAX_DOWN=maxymalne_lcze w kbit
MIN_DOWN=Gwarantowane_lacze w kbit
MAX_DOWN_PRZYCIETE= w kbit
MIN_DOWN_PRZYCIETE = w kibt
PORT=port_do_przyciecia

tc qdisc del root dev $LAN
tc qdisc add dev $LAN root handle 1:0 htb default 1
tc class add dev $LAN parent 1:0 classid 1:1 htb rate $MAX_DOWN ceil $MIN_DOWN prio 1 quantum 1500
tc class add dev $LAN parent 1:1 classid 1:2 htb rate $MAX_DOWN_PRZYCIETE ceil $MIN_DOWN_PRZYCIETE prio 2 quantum 1500

tc filter add dev $LAN protocol ip parent 1:0 u32 match ip sport $PORT 0xffff flowid 1:2

Ostatnio zmieniony 2009-10-20, 09:08 przez webster, łącznie zmieniany 3 razy.
††† Chaos Of The Mirror - Valheru †††
††† I ♥ SlackWare RuLeZ †††

Slackware Poland FaceBook

ODPOWIEDZ