[CBQ & IP-Tables] kan de upload niet indammen

[KC_Kaas]

Situatie:
Een ADSL verbinding --> server (E-smith 5.6 kernel 2.4.18-5) --> netwerk
Op de server draaien een aantal website's compleet met mail, ftp, enz. Nu heb ik een behoorlijke upload (zo'n 100 Kb/s) dus dat draait vrij lekker. De buren gebruiken mijn lijn voor internet.

Probleem:
Zo nu en dan komt er bij mijn buurman (IP 192.168.0.50) een aantal kleinkinderen langs die op opa's pc p2p programma's installeren en mijn volledige upload opslurpen. Constant 90 Kb upload, zodat er maar weinig overblijft voor de rest / de server.

Mijn oplossing (dacht ik)
Om de upload in te dammen heb ik CBQ gebruikt. Omdat het via NAT laat ik eerst zijn pakketjes marken:

iptables -t mangle -A PREROUTING -i eth0 -p tcp -s 192.168.0.50 -j MARK --set-mark 5

Daarna heb ik dit bestandje gemaakt:

DEVICE=eth0,10Mbit,1Mbit
RATE=80Kbit
WEIGHT=8Kbit
PRIO=5
MARK=5

En die onder de naam: cbq-1281.xxxx in de map '/etc/sysconfig/cbq' gezet. Toen CBQ opgestart met: CBQ start (geen foutmelding). Alleen werkt het dus niet, de upload wordt niet gecapt....

Iemand enig idee wat er fout gaat?

Verdere info
Interne NIC: eth0
Externe NIC: eth1
IP via DHCP met MAC

[ Voor 3% gewijzigd door KC_Kaas op 11-05-2004 17:28 ]

[Koffie]

Move PNS > NOS

[pierre-oord]

simpel:

iptables -t mangle -A PREROUTING -i eth0 -p tcp -s 192.168.0.50 -j MARK --set-mark 5

Dat klopt niet. Het moet zijn:

iptables -t mangle -A POSTROUTING -o eth0 -p tcp -s 192.168.0.50 -j MARK --set-mark 5

Het gaat toch om de uitgang een o dus ipv een i en POSTROUTING (voor het routen, anders is je source address ook geNAT) ipv PREROUTING. Dan werkt het (ik gebruik het zelf ook) [edited @ 22:03 vanwege een klein foutje ]

edit:
-p tcp kun je eventueel weglaten, zo filter je meteen udp etc

[ Voor 24% gewijzigd door pierre-oord op 11-05-2004 22:03 ]

[Verwijderd]

Vraagje voor eigenbelang

ik gebruik wel vaker DC++ en die vreet totaal mn upload weg waardoor ik ruzie krijg met mn familie omdat internet dan zo sloom is. Maar aangezien ik ook een ftpservertje draai zou ik die graag niet willen beperken dus alleen de poorten die DC++ gebruikt, is dat toevallig ook mogelijk zoals:

code:

iptables -t mangle -A PREROUTING -o eth0 --dport 4002 -s 192.168.2.2 -j MARK --set-mark 5

ps ik heb zelf nog geen CBQ geïnstalleerd.

edit:

ik heb een voorbeeldje gevonde voor het limiten van bepaalde poorten met CBQ. werkt blijkbaar toch niet als ik d8.

code:

DEVICE=eth0,10Mbit,1Mbit
RATE=35Kbit
WEIGHT=3Kbit
PRIO=5
#Windows Media Player.
RULE=:1755,192.168.1.0/24
#Real Player uses TCP port 554, for UDP it uses different ports,
#but generally RealAudio in UDP doesn't consume much bandwidth.
RULE=:554,192.168.1.0/24
RULE=:7070,192.169.1.0/24
#Napster uses ports 6699 and 6700, maybe some other?
RULE=:6699,192.168.1.0/24
RULE=:6700,192.168.1.0/24
#Audiogalaxy uses ports from 41000 to as high as probably 41900,
#there are many of them, so keep in mind I didn't list all of
#them here. Repeating 900 nearly the same lines would be of course
#pointless. We will simply cut out ports 410031-41900 using
#ipchains or iptables.
RULE=:41000,192.168.1.0/24
RULE=:41001,192.168.1.0/24
#continue from 41001 to 41030
RULE=:41030,192.168.1.0/24
#Some clever users can connect to SOCKS servers when using Napster,
#Audiogalaxy etc.; it's also a good idea to do so
#when you run your own SOCKS proxy
RULE=:1080,192.168.1.0/24
#Add any other ports you want; you can easily check and track
#ports that programs use with IPTraf
#RULE=:port,192.168.1.0/24

Bron

[ Voor 59% gewijzigd door Verwijderd op 11-05-2004 19:32 ]

[pierre-oord]

Het werkt met het tooltje cbq.init als ik me niet vergis. Je kunt met deze tool RULE=blaat gebruiken, maar ook MARK=blaat en dan met iptables een bepaald pakketje markeren. Naar het schijnt is de RULE manier sneller, echter kreeg ik dit niet werkend bij mij met uploaden, wel met downloaden. Ik gebruik dus ook iptables om pakketjes te markeren.

Op sourceforge staat htb.init (ik geloof dat dat hem toch was, er zijn 2 soort programma's, maar een is nieuwer en werkt ietsje anders, beter!).

edit:
jup, htb.init heet het script.

Overigens staat er op mijn website een howto, alleen het stukje over upload klopt niet, dit moet dmv iptables zoals hier staat.

(VOor kernel 2.4, maar je kunt het vast werkend krijgen op 2.6 met de juiste versies).

[ Voor 22% gewijzigd door pierre-oord op 11-05-2004 19:53 ]

[KC_Kaas]

iptables v1.2.5: Can't use -o with PREROUTING

dit is dan de output. Het moest wel via prerouting toch?

[pierre-oord]

eum, postrouting (na het routen)

edit:
Hier stond onzin

edit2:
iptables 1.2.9 is overigens de nieuwste

[ Voor 111% gewijzigd door pierre-oord op 12-05-2004 09:30 ]

[KC_Kaas]

Hij moet toch juist voor het routen? (omdat het om de upstream gaat)

Hij doet het ook met postrouting niet

[Appesteijn]

Probeer eens met ./tc -s class show dev eth1 en ./tc -s filter show dev eth1 (met eth1 als extern) te kijken of er verkeer in de juiste class wordt gegooid.
Ik heb het destijds met POSTROUTING gedaan.


off-topic

ga je op minddigger of hier verder? Dan weet ik waar ik moet kijken en posten, want ik wil de uitkomst ook graag weten

/off-topic

[ Voor 8% gewijzigd door Appesteijn op 11-05-2004 23:19 ]

[KC_Kaas]

Even alles op een rijtje, dit is wat ik nu gedaan heb:

iptables -t mangle -A POSTROUTING -o eth0 -s 192.168.0.50 -j MARK --set-mark 5

Dit zorgt ervoor dat alle data van 192.168.0.50 naar mijn Interne NIC (eth 0) wordt gemarkt.

Daarna gaat het verkeer door mijn server (via NAT) naar Eth 1 en daar het internet op. Dus moet de uptream zeg maar worden gecaped tussen Eth 0 en Eth 1. Met dit bestand:

DEVICE=eth1,10Mbit,1Mbit
RATE=80Kbit
WEIGHT=8Kbit
PRIO=5
MARK=5

De output van: "tc -s class show dev eth1"

class cbq 11: root rate 10Mbit (bounded,isolated) prio no-transmit
Sent 1569928 bytes 1737 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 1816 undertime 0
class cbq 11:1 parent 11: rate 10Mbit prio no-transmit
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 1874 undertime 0
class cbq 11:1280 parent 11:1 leaf 8033: rate 80Kbit (bounded) prio 5
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 6.75873e+06 undertime 0
[root@einstein cbq]# tc -s class show dev eth1
class cbq 11: root rate 10Mbit (bounded,isolated) prio no-transmit
Sent 4634552 bytes 4905 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 1816 undertime 0
class cbq 11:1 parent 11: rate 10Mbit prio no-transmit
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 1874 undertime 0
class cbq 11:1280 parent 11:1 leaf 8033: rate 80Kbit (bounded) prio 5
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 6.75873e+06 undertime 0

Output :"tc -s filter show dev eth1"

niets

Offtopic
Op dit moment hier, hier was meer respons en de meeste van minddigger huppelen ook hier rond

[Appesteijn]

Nou zelf ook maar even weer lopen kl*ten


iptables --table mangle -A POSTROUTING --out-interface eth1 --source 192.168.1001.0 -j MARK --set-mark 2

CBQ-FILE-INHOUD:

DEVICE=eth1,10Mbit,1Mbit
RATE=150Kbit
WEIGHT=15Kbit
PEAK=160Kbit
PRIO=6
MARK=2

En dan ./cbq-init

./tc -s flter show dev eth1 geeft:

filter parent 1: protocol ip pref 200 fw
filter parent 1: protocol ip pref 200 fw handle 0x2 classid 1:1280

./tc -s class show dev eth1 geeft

class cbq 1: root rate 10Mbit (bounded,isolated) prio no-transmit
Sent 12300615 bytes 14751 pkts (dropped 0, overlimits 0)
borrowed 0 overactions 0 avgidle 624 undertime 0
class cbq 1:1280 parent 1: leaf 1280: rate 150Kbit (bounded) prio 6
Sent 4189511 bytes 5771 pkts (dropped 291, overlimits 1975)
backlog 16p
borrowed 0 overactions 587 avgidle 39805 undertime 0


Als ik bij out-interface eth0 zet dan wordt er niets in de class van 150Kbit gestopt. Zodra ik er eth1 van maak loopt deze class gelijk vol. Ik was aan het uploaden met 40 KB en dit werd na een ./service network restart 18 a 20 KB/s. Ik moet alleen nu weg dus ik kan niet testen of dit nu voor mijn hele netwerk geldt of alleen (zoals zou moeten) voor de gemarkte packets.

edit

Ik heb nu een ander ip-adres laten marken en de rest van het netwerk heeft er geen last van (ze kunnen max uppen). Het lijkt er dus op dat dit zo werkt.

/edit

[ Voor 8% gewijzigd door Appesteijn op 12-05-2004 12:06 ]

[pierre-oord]

Even een korte uitleg van de werking etc van htb:

In het geval van internet op eth0 en netwerk op eth1:

ETH0: Hier limiteer je de upload snelheid mee.
ETH1: Hier limiteer je de download snelheid mee.

Een computer kan niet regelen hoeveel data erin mag komen, dat heeftie maar te accepteren naar verluid, maar hoeveel eruit kan, kan die wel regelen. Door je ETH1 dus te limiten hoopt de data zich intern als het ware op, en gaat de zender vanzelf wel minder sturen. Klinkt krom, maar zo werkt het wel.

Verder heb ik veel betere ervaringen met HTB.init vergeleken met cbq.init. HTB is de opvolger, met hetzelfde idee, hetzelfde script maar aangepast door iemand anders.

Hieronder nog even over het POSTROUTING en PREROUTING verhaal, ik heb het best duidelijk uitgelegd vind ik :

Download normaal:
Pakketje komt binnen eth0 - natROUTING - pakketje gaat eruit eth1

Download limiet:
Pakketje komt binnen eth0 - natROUTING - laten wachten - pakketje gaat eruit eth1
(POSTROUTING, NA routen)

Upload normaal:
Pakketje komt binnen eth1 - natrouting - pakketje gaat eruit eth0

Upload limiet:
Pakketje komt binnen eth1 - laten wachten - natrouting - pakketje gaat eruit eth0
(PREROUTING, voor routen)

En nu het waarom:

Bij download gaat het om naar welke PC het pakketje toe gaat. Ga je voor NAT al daarnaar kijken, dan zie je alleen dat het pakketje naar je internet iP toe wil, niet naar welke client. Maar als je ná het natrouten kijkt, heeft het pakketje plots een destination van een client, en kun je het zodoende ook markeren op die client!

Bij upload gaat het niet om naar welke PC je iets toe zend, maar vanaf welke client het komt, het source (-s) adres dus. Als je het pakketje pas markeert na nat, is het source adres het internet ip adres geworden, dat doet nat tenlostte!


En voor het leeghalen van iptables wat iemand boven me vroeg:
Uit m'n hoofd was dat
iptables -F --table NAT
iptables -F

Ik dacht dat dat genoeg was, niet helemaal zeker, ik heb hier geen script, en ook geen iptables bij de hand helaas. Gelukkig bestaat er "man iptables", en genoeg iptable howto's op internet.

[ Voor 18% gewijzigd door pierre-oord op 12-05-2004 09:46 ]

[Tom_G]

Excuseer me voor het late kicken van dit topic, maar ik heb een nogal relevante vraag.

Ik heb een Linux router (Debian).
- eth0 voor de WAN verbinding (ip via DHCP)
- eth1 voor de LAN verbinding (192.168.5.0/24)

Ook ik had hetzelfde probleem als de TS die ik ook heb kunnen oplossen door het pakket te markeren.

Echter moet dit in deze situatie voor meerdere gebruikers werken. Daarom onderstaand voorbeeld met 2 clients die moeten gelimiteerd worden in hun upload (dit louter ter illustratie, want het moet evengoed schalen naar 10 clients).

code:

iptables -t mangle -A POSTROUTING -o eth0 -s 192.168.5.3 -j MARK --set-mark 5
iptables -t mangle -A POSTROUTING -o eth0 -s 192.168.5.5 -j MARK --set-mark 5

En dan voor iedere pc ook een CBQ rule maken die er zo uitziet:

code:

DEVICE=eth0,10Mbit,1Mbit
RATE=64Kbit
WEIGHT=5Kbit
PRIO=5
MARK=5
RULE=192.168.5.3

code:

DEVICE=eth0,10Mbit,1Mbit
RATE=64Kbit
WEIGHT=5Kbit
PRIO=5
MARK=5
RULE=192.168.5.5

Nu denk/vermoed ik dat het volgende gebeurd:
De RULE definitie is overbodig want omdat het uitgaand verkeer is op eth0, is het pakketje al ge-NAT en bijgevolg is het source adres van de oorspronkelijke client veranderd naar het ip adres van eth0.

Daardoor kan er dus geen rekening gehouden worden met het source adres, en wordt bijgevolg alle verkeer dat gemarkeerd is met 5 geshaped op basis van deze CBQ rules. Waaruit ik denk/afleid dat in bovenstaand geval dus deze 2 clients de opgegeven bandbreedte delen ipv die elk afzonderlijk (dedicated) toegewezen te krijgen.
Klopt deze redenering?

Zo ja, kan er een mouw aan gepast worden? Ik dacht eventueel om mbv iptables ieder pakket per client een andere mark mee te geven (bvb mark 1 voor client 1 en mark 2 voor client 2) en dan per CBQ rule ook diezelfde mark opgeven (en de RULE met het source adres eventueel achterwege te laten).