UBR
Anmeldungsdatum: 12. November 2017
Beiträge: 13
|
Servus Community, ich hätte eine Frage bezüglich Bandbreitelimitierung. Ich suche ein Tool für mein Script, wo ich meine Bandbreite auf 16 Mbit per User limitieren kann.
Es ist auch okay, wenn es auch per Port gehen würde, aber ich finde im Netz nur sehr komplizierte Antworten. Es wäre nice, wenn einer diese Frage beantworten könnte. Mit freundlichen Grüßen,
Braveen
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
UBR schrieb: […] Bandbreitelimitierung
Das wird unter Linux konfiguriert mit dem Programm tc aus dem Packet iproute2.
[…] ich finde im Netz nur sehr komplizierte Antworten
Die Aufgabe IST kompliziert …
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Etwas einfacher geht es mit wondershaper, welcher unter der Haube auch tc verwendet.
|
UBR
(Themenstarter)
Anmeldungsdatum: 12. November 2017
Beiträge: 13
|
Naja wo kann ich den User bestimmen?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
UBR schrieb: Naja wo kann ich den User bestimmen?
Das geht nicht einfach so. Wondershaper kann mit Interfaces umgehen, das heißt man könnte verschiedene User über verschiedene Interfaces routen, und diese dann beschränken. Das ist aber nichts, was ich schon gemacht hätte, und dazu wirst du vermutlich auch keine Step-by-step-Anleitung finden. Da muss man eben bisschen probieren.
|
raptor2101
Anmeldungsdatum: 8. Juni 2009
Beiträge: 1249
Wohnort: Stuttgart, Deutschland
|
UBR schrieb: Naja wo kann ich den User bestimmen?
Wenn du rein auf Technologien setzt die bis Layer 4 gehen, wo soll da die Info über den User herkommen? Bandbreitenlimitierung auf Userbasis geht maximal am Gerät wo der User auch identifizierbar ist, wenn die TrafficControl an einem Router gemacht werden soll, ist die Benutzerinfo schlicht nicht vorhanden. Hier ist imho einzig eine Lösung mit authentifizierendem Proxy möglich und das geht nur für bestimmte Protokolle.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
raptor2101 schrieb: Wenn du rein auf Technologien setzt die bis Layer 4 gehen, wo soll da die Info über den User herkommen?
Aus dem netfilter-Framework des Kernels.
Bandbreitenlimitierung auf Userbasis geht maximal am Gerät wo der User auch identifizierbar ist
In dem Falle wäre das das lokale System – dort ist der User noch identifizierbar. Ansonsten könnte man auch versuchen den User codiert über Paket-Markierungen mitgeben.
Hier ist imho einzig eine Lösung mit authentifizierendem Proxy möglich und das geht nur für bestimmte Protokolle.
SOCKS funktioniert protokollunabhängig.
|
raptor2101
Anmeldungsdatum: 8. Juni 2009
Beiträge: 1249
Wohnort: Stuttgart, Deutschland
|
misterunknown schrieb: raptor2101 schrieb: Wenn du rein auf Technologien setzt die bis Layer 4 gehen, wo soll da die Info über den User herkommen?
Aus dem netfilter-Framework des Kernels.
Jop, das geht aber nur auf Maschine die den Traffic erzeugt. Wie soll das mit Incomming Traffic
Bandbreitenlimitierung auf Userbasis geht maximal am Gerät wo der User auch identifizierbar ist
In dem Falle wäre das das lokale System – dort ist der User noch identifizierbar. Ansonsten könnte man auch versuchen den User codiert über Paket-Markierungen mitgeben.
Wie soll das bei Incomming Traffic gehen? Der Traffic ist schon an deinem Router ... Hier ist imho einzig eine Lösung mit authentifizierendem Proxy möglich und das geht nur für bestimmte Protokolle.
SOCKS funktioniert protokollunabhängig.
Geht SOCKS out of the BOX mit jedem beliebigen Protokoll/Programm? Ich dachte das muss das Programm unterstützen, zumal wenn vorher ein Auth-Packet rausgehen muss...?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Incoming kannst du ohnehin nur indirekt, also - schon empfangene Pakete droppen oder verzögern in der Hoffnung, daß die Gegenseite dann eben runterregelt. Besser als nichts. Pro Benutzer im LAN hatte ich vor Uuurzeiten mal was gebastelt (FairNAT). Das war einfach nur Router mit HTB und einer Klasse für jeden. Aber auf einem System bekommst du das so ohne weiteres nicht aufgeteilt. Pro Benutzer auf der gleichen Maschine muss man irgendwas erfinden z.B. mit erlaubtem Port-Range pro User? Vielleicht irgendwas mit Netzwerk-Namespaces? Da bin ich nicht auf dem aktuellen Stand, hab ich noch nie gebraucht. Allgemein vielleicht mal drüber nachdenken... ob es wirklich notwendig ist? Bevor du da ein ultrakompliziertes System aus dem Boden stampfst, kannst du ja auch mal blind ein PRIO / SFQ / ESFQ draufwerfen, vielleicht reicht das ja schon, daß jeder mal darf. Wenn es um spezielle Anwendungsfälle geht z.B. wenn das rsync Backup die Leitung dicht macht... rsync hat seine eigene Option zur Bandbreitenlimitierung und manche andere Programme haben dies auch.
|
raptor2101
Anmeldungsdatum: 8. Juni 2009
Beiträge: 1249
Wohnort: Stuttgart, Deutschland
|
frostschutz schrieb: Incoming kannst du ohnehin nur indirekt, also - schon empfangene Pakete droppen oder verzögern in der Hoffnung, daß die Gegenseite dann eben runterregelt. Besser als nichts.
Prinzip hoffnung 😀
Pro Benutzer im LAN hatte ich vor Uuurzeiten mal was gebastelt (FairNAT). Das war einfach nur Router mit HTB und einer Klasse für jeden. Aber auf einem System bekommst du das so ohne weiteres nicht aufgeteilt.
bassierte das nicht auf dem Owner Package (netfilter) das schon vor ebenso Uuurzeiten stark zusammengestuzt wurde?
|
dirkolus
Anmeldungsdatum: 17. Mai 2011
Beiträge: 2003
Wohnort: dahoam
|
Ich hätte für diese Anforderung Squid angesehen, der Web-Proxyserver bietet durchschnittliche Bandbreitenbegrenzung über Dead-pools (zumindest wenn's um HTTP-Traffic geht) und es können einzelne User eingerichtet werden. Nein, gemacht hab ich sowas auch noch nicht.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
raptor2101 schrieb: Jop, das geht aber nur auf Maschine die den Traffic erzeugt. Wie soll das bei Incomming Traffic gehen? Der Traffic ist schon an deinem Router ...
Niemand hat gesagt, dass es schön oder sinnvoll geht, aber wondershaper macht genau das. Wie frotzschutz schon schrieb, werden die Pakete verzögert oder gedroppt. Das ist übrigens lustigerweise genau der Mechanismus bei Kabel-Internetanschlüssen. Dort wird die Drosselung auch erst auf der Kabelbox gemacht^^
Geht SOCKS out of the BOX mit jedem beliebigen Protokoll/Programm? Ich dachte das muss das Programm unterstützen, zumal wenn vorher ein Auth-Packet rausgehen muss...?
Das geht auch transparent, beispielsweise mit tsocks. Es gibt wenige Ausnahmen, wo das nicht ohne weiteres funktioniert. frostschutz schrieb: Pro Benutzer auf der gleichen Maschine muss man irgendwas erfinden z.B. mit erlaubtem Port-Range pro User? Vielleicht irgendwas mit Netzwerk-Namespaces? Da bin ich nicht auf dem aktuellen Stand, hab ich noch nie gebraucht.
Incoming-Traffic ist ja in solchen Fällen fast immer einer Verbindung zuzuordnen, die vom System selbst aufgebaut wurde, von daher kann man mit dem Owner-Modul von iptables die Verbindung entsprechend markieren, und anhand dessen beispielsweise Policy-Routing mit verschiedenen IPs/Interfaces für einzelne User arbeiten. Ob man für sowas Netzwerk-Namespaces nehmen kann, wäre mal interessant zu erörtern, allerdings Wie gesagt, sind wir uns aber sicherlich alle einig, dass das extremes Gebastel ist, welches den Aufwand nicht lohnt.
|
raptor2101
Anmeldungsdatum: 8. Juni 2009
Beiträge: 1249
Wohnort: Stuttgart, Deutschland
|
misterunknown schrieb:
Incoming-Traffic ist ja in solchen Fällen fast immer einer Verbindung zuzuordnen, die vom System selbst aufgebaut wurde, von daher kann man mit dem Owner-Modul von iptables die Verbindung entsprechend markieren, und anhand dessen beispielsweise Policy-Routing mit verschiedenen IPs/Interfaces für einzelne User arbeiten. Ob man für sowas Netzwerk-Namespaces nehmen kann, wäre mal interessant zu erörtern, allerdings
Genau das wird "schwierig" bzw ist davon abhängig, dass alle Geräte deine Markierung nicht wegmachen (oder dein "Conntrack" sehr stabil läuft)
Wie gesagt, sind wir uns aber sicherlich alle einig, dass das extremes Gebastel ist, welches den Aufwand nicht lohnt.
Zustimmung. Hinzu kommt, dass das entsprechende Modul schon seit geraumer zeit (in Teilen) als "broken" gilt ("NOTE: pid, sid and command matching are broken on SMP"). Ich habe es im Einsatz aber nur auf einzelnen Dedizierten Servern um Traffic unterschiedlicher Dienste (alle gehen über HTTPS raus 😉) getrennt voneinander zu drosseln.
|