Die Geschwindigkeit, mit der Daten über Netzwerke transportiert werden, wächst dank fortschreitender Technologien stetig. Doch Geschwindigkeit allein ist nicht das einzige Kriterium, um die Bedürfnisse des Anwenders in Bezug auf die Datenübertragung zufriedenzustellen. Oft ist es auch notwendig, bestimmten Datenverkehr vorrangig zu behandeln oder bestimmten Anwendungen eine Mindestbandbreite zu garantieren. Weitere Anforderungen können das Verbieten oder Umleiten von Datenpaketen beinhalten.
Das Betriebssystem Linux stellt dafür zwei Werkzeuge zur Verfügung, die diese Bedürfnisse abdecken. Dabei handelt es sich zum einen um die Firewall, die seit der Kernelversion 2.6 mit dem iptables-Befehl realisiert wird. Zum anderen behandelt das Programm „tc“ sämtliche Anforderungen, welche das Bandbreitenmanagement oder die Priorisierung des Netzwerkverkehrs betreffen.
In der vorliegenden Arbeit werden zu Beginn das Prinzip und die Funktionsweise der Linux-Firewall betrachtet. Im Anschluss daran werden einige Möglichkeiten vorgestellt, die das Programm „tc“ anbietet, um den QoS-Anforderungen gerecht zu werden. Im letzten Schritt wird das Verhalten beider Programme beobachtet, wenn Pakete innerhalb drei verschiedener Netzwerke verschickt und kontrolliert werden müssen.
Das Ergebnis dieser Beobachtungen führt zu dem Schluss, dass mit Hilfe dieser beiden Anwendungen ein Netzwerk derart gestaltet werden kann, dass es sowohl sicher ist, als auch QoS-Anforderungen zufriedenstellend erfüllt.
Inhaltsverzeichnis
1 Einleitung
2 Die Funktion des Linux-Kernels in Bezug auf Firewalling
2.1 Die Filter-Tabelle
2.2 Die NAT-Tabelle
2.3 Die Mangle-Tabelle
2.4 Die Raw-Tabelle
3 Traffic Control
3.1 Classless Queueing Disciplines
3.1.1 pfifo_fast
3.1.2 bfifo und pfifo
3.1.3 Stochastic Fairness Queueing (SFQ)
3.1.4 Token Bucket Filter (TBF)
3.1.5 Weitere Classless Queueing Disciplines
3.2 Classful Queueing Disciplines
3.2.1 PRIO QDisc
3.2.2 Hierarchical Token Bucket (HTB)
3.2.3 Weitere Classful Queueing Disciplines
3.3 Filter
3.3.1 Klassifikation anhand Markierungen: Der fw-Filter
3.3.2 Klassifikation anhand der Routing-Tabelle: Der route-Filter
3.3.3 Flexibel klassifizieren mit dem u32-Filter
4 Aufbau und Bewertung einer Testumgebung mit Firewall und Traffic Control
4.1 Die Testumgebung
4.2 Anforderungen an die Firewall und den QDiscs
4.3 Vorbereitungen
4.3.1 Konfiguration der Netzwerkkarten
4.3.2 Installation von SSH
4.3.3 Installation des Programmes iperf (jperf)
4.4 Errichtung der Firewall
4.5 Erstellung der QDiscs für sämtliche Schnittstellen
4.5.1 Schnittstelle eth0: Die Entlastung der Modem-Warteschlange
4.5.2 Schnittstelle eth1: Der Intra-/Internet-Server in der DMZ
4.5.3 Schnittstelle eth2 und eth4: Die Clients im LAN
4.6 Messungen
4.6.1 Messungen ohne Bandbreitenentlehnung
4.6.2 Messungen mit der Möglichkeit einer Bandbreitenentlehnung
5 Erkenntnis und Ausblick
Literaturverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
Anhang A: Das Firewall-Skript „firewall_on“
Anhang B: Das QDisc-Skript „qdisc_on“
1 Einleitung
Der Wunsch vernetzter Applikationen ist, ihre Daten so schnell als möglich über das Netzwerk zu schicken. Das Betriebssystem Linux in seiner Grundkonfiguration erfüllt diesen Wunsch auch nach dem Best-Effort-Prinzip.
Dieses Prinzip befriedigt jedoch nicht immer alle Bedürfnisse. Manche Anwendungen, wie etwa die Sprachtelefonie, verlangen nach niedrigen Latenzzeiten. Zusätzliche Bandbreite zu kaufen eliminiert das Problem keineswegs, andere Applikationen können immer noch entsprechend viele und große Pakete ins Netz schicken. Dadurch wird der Versand der bandbreitenschonenden VoIP-Pakete auf ein unerträgliches Ausmaß blockiert.
Ein anderes Problem beinhaltet die Bandbreitenbegrenzung. Oft ist es notwendig, einem Benutzer nur eine gewisse Bandbreite zuzugestehen. Ein typisches Beispiel ist ein InternetProvider, der für einen niedrigeren Tarif auch nur eine limitierte Bandbreite zur Verfügung stellen möchte. Ebenso scheint auch eine Bandbreitenbegrenzung nach außen hin sinnvoll zu sein. Ein Modem verfügt im Normalfall nur über eine einfache Warteschlange, in der es den ausgehenden Netzwerkverkehr in keiner Weise priorisieren kann. Es macht durchaus Sinn, wenn es eine Möglichkeit gäbe, die Pakete, die das Netzwerk verlassen, vor dem Modem entsprechend ihrer Dringlichkeit und fairen Behandlung zu ordnen und diese dann dem Modem mit gedrosselter Geschwindigkeit weiterzureichen.
Die Lösung für diese und andere Probleme lautet Traffic Control. Linux stellt mit dem tcBefehl dafür ein mächtiges Werkzeug zur Verfügung, mit dem es möglich ist, den Netzwerkverkehr zu kontrollieren, begrenzen, priorisieren und aufzuteilen.
Kapitel 2 behandelt die Linux-Firewall. Eine richtig konfigurierte Firewall trägt nicht nur zur Sicherheit eines Systems bei. Sie wird auch für das Traffic Control benötigt, indem sie etwa Vorarbeiten wie das Markieren bestimmter Pakete leistet. Diese markierten Pakete dienen dann dem Traffic Control zur Klassifikation.
Das nachfolgende Kapitel 3 beleuchtet einige Ausprägungen von Queueing Disciplines, also jenen Mechanismen, die dafür zuständig sind, die Pakete für ihre Weiterleitung entsprechend aufzubereiten.
Im vierten Kapitel wird zuerst eine Batch-Datei für eine Firewall Schritt für Schritt aufgebaut. Im Anschluss daran erfolgt die Erstellung eines Skripts, welches den Traffic Control auf dem Router realisiert und in weiterer Folge als Grundlage für diverse Bandbreitenmessungen dient.
2 Die Funktion des Linux-Kernels in Bezug auf Firewalling
Iptables ist der Paketfilter von Linux. Er ist seit der Kernelversion 2.4 integrierter Bestandteil von Linux und ist der Nachfolger von ipfwadm (Kernelversion 2.0) und ipchain (Kernelversion 2.2). Mit Hilfe von iptables ist es möglich, sowohl lokale als auch NetzwerkFirewalls zu realisieren.
Iptables verwendet folgende vier Tabellen, in der sämtliche Regeln verwaltet werden:
- Filter-Tabelle
- NAT-Tabelle
- Mangel-Tabelle
- Raw-Tabelle
In jeder Tabelle befinden sich eine unterschiedliche Anzahl an Ketten, den sogenannten Chains. Darin werden Filterregeln definiert, die Schritt für Schritt abgearbeitet werden. Trifft eine Filterregel zu, dann wird diese ausgeführt und die Kette verlassen (Ausnahme: Logging). Am Ende der Kette befindet sich eine Default Policy, die nur dann ausgeführt wird, wenn keine der davor definierten Regeln auf ein Paket angewendet werden konnte.
Die Filterregeln bestimmen, was mit einem Paket geschehen soll, auf das eine bestimmte Regel zutrifft. So können etwa Pakete mit bestimmten Eigenschaften akzeptiert (ACCEPT) oder verworfen (DROP) werden. Werden Pakete mittels DROP verworfen, so erhält der Absender des Paketes keine Information darüber. Soll dieser über diesen Zustand anhand einer ICMP-Fehlermeldung informiert werden, so muss man das Paket mittels REJECT verwerfen. Neben diesen drei Zielen existieren noch eine Reihe anderer, die in der Manpage 1 ausführlich beschrieben sind.
Die Default Policy sollte einen restriktiven anstatt einen permissiven Ansatz verfolgen, d.h. wenn die vorher durchlaufenen Filterregeln nicht gegriffen haben, soll das entsprechende Paket verworfen werden.
Da die definierten Regeln nach einem Neustart des Rechners nicht mehr gültig sind, sollten diese in ein Skript, das beim Systemstart automatisch ausgeführt wird, geschrieben werden.
In den nachfolgenden Kapiteln 2.1 bis 2.4 werden die einzelnen Tabellen genauer betrachtet.
2.1 Die Filter-Tabelle
In dieser Tabelle erfolgt die Filterung der Pakete. Anhand der Filterkriterien wird entschieden, ob ein Paket verworfen oder angenommen wird. Die Filter-Tabelle beinhaltet drei Ketten (INPUT, OUTPUT, FORWARD). Die Anordnung der Ketten ist in Abbildung 1 ersichtlich:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Die Filter-Tabelle und ihre Ketten
Trifft ein Paket am Rechner ein, so wird zuerst festgestellt, ob das Paket für den Rechner selbst bestimmt ist oder ob es weitergeleitet werden soll. Im ersten Fall durchläuft es anschließend die INPUT-Chain, wird verifiziert und im Erfolgsfall an den lokalen Prozess abgeliefert. Analog dazu verhält es sich für Pakete, die ins Netz weitergeleitet werden sollen. Diese durchlaufen jedoch statt der INPUT-Chain die FORWARD-Chain. Es kann auch der Fall eintreten, dass der lokale Prozess Pakete erzeugt, die den Rechner verlassen müssen. Diese Pakete werden von der OUTPUT-Chain behandelt.
Die Möglichkeiten der Filterung sind mannigfaltig. So können etwa Pakete anhand deren IP-Adresse (sowohl Quell- als auch Zieladresse), Ports (Quell- und Zielports) und/oder verwendetem Protokoll untersucht werden.
Ein Novum bei iptables gegenüber seinen Vorgängern ist die Stateful Inspection. Mit deren Hilfe ist es nun möglich, ansonsten zu verweigernde Pakete zu erlauben, wenn sie Teil einer bereits bestehenden Verbindung sind (Connection Tracking) oder in Relation zu einer anderen, erlaubten Verbindung stehen2.
2.2 Die NAT-Tabelle
Diese Tabelle ist für die Maskierung von Paketen zuständig und besteht aus drei Ketten (OUTPUT, PREROUTING, POSTROUTING). Abbildung 2 zeigt die Anordnung dieser Ketten in Verbindung mit den Ketten der Filtertabelle.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Die NAT- und Filter-Tabelle und ihre Ketten
Ein Source-NAT (SNAT) ist nur in der POSTROUTING-Chain erlaubt. Unter SNAT versteht man das Ändern der Absenderadresse. Dies ist z. B. notwendig, wenn man von einem lokalen Netzwerk auf einen Rechner im Internet zugreifen will. Da der entfernte Rechner nichts mit der lokalen IP-Adresse anfangen kann (abgesehen von der Tatsache, dass private IP-Adressen nach RFC 1918 im Internet nicht erlaubt sind), ist ein Mapping auf dem Router notwendig. Beim Mapping wird die lokale Source-IP-Adresse des Absenders auf die öffentliche, im Internet bekannte IP-Adresse ausgetauscht und in einer Tabelle gespeichert. Eventuelle Antwortpakete werden dann mithilfe dieser Tabelle wieder zurückgenattet, d.h., die öffentliche IP-Adresse wird durch die lokale ersetzt.
Hier ist auch ersichtlich, warum das SNAT nur in der POSTROUTING-Tabelle erlaubt ist. SNAT verändert das Paket und eine Filterung kann nur auf das originale Paket angewandt werden. Ein Filter, der z. B. einer lokalen IP-Adresse 192.168.1.2 den Zugriff auf einen bestimmten Internetdienst gestattet und einer lokalen IP-Adresse 192.168.1.3 untersagt, kann zwischen diesen beiden Paketen nicht mehr differenzieren, wenn in beiden Paketen die gleiche, öffentliche IP-Adresse eingetragen ist.
Ein ähnliches Ziel wie SNAT ist MASQUERADE. Auch hier darf eine Bearbeitung nur in der POSTROUTING-Chain erfolgen. Der Unterschied liegt darin, dass bei SNAT die öffentliche IP-Adresse explizit angegeben werden muss und bei MASQUERADE diese IP-Adresse automatisch ermittelt wird. Besitzt man eine dynamisch zugewiesene IP-Adresse, ist diese Variante zu bevorzugen.
Destination-NAT (DNAT), auch Port-Forwarding genannt, ist hingegen nur in der PREROUTING- oder in der OUTPUT-Chain möglich. In diesem Fall wird die Zieladresse eines ankommenden Pakets geändert. Eine typische Anwendung ist ein Webserver im lokalen Netz, der sich auf einem anderen Rechner als die Firewall befindet (idealerweise in einer DMZ). Erhält die Firewall nun ein Paket mit dem Ziel-Port 80 (TCP), so wandelt er die IP- Adresse in der PREROUTING-Chain in die entsprechende lokale IP-Adresse um. Danach erfolgt die Bearbeitung in der FORWARD-Kette der Filter-Tabelle und bei erfolgreicher Behandlung schlussendlich die Weiterleitung an den entsprechenden Rechner.
2.3 Die Mangle-Tabelle
Die Aufgabe der Mangle-Tabelle ist, Pakete zu modifizieren, bevor sie die NAT- und Filterketten durchlaufen. Daraus folgt, dass die Filterregeln auf bereits geänderte Pakete angewendet werden. Die Mangle-Tabelle besteht ab der Kernel-Version 2.4.183 aus den fünf Ketten INPUT, OUTPUT, FORWARD, PREROUTING und POSTROUTING. Abbildung 3 zeigt das Zusammenspiel aller Ketten sämtlicher Tabellen, einschließlich der Raw-Tabelle, die in Kapitel 2.4 behandelt wird.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Sämtliche Tabellen inkl. deren Ketten
Mittels der Mangle-Tabelle können u.a. das TOS-Feld oder der TTL-Wert eines Pakets verändert werden. Für die Filter der QDisc ist jedoch das Ziel MARK interessant: Dabei werden Pakete mit einer Zahl markiert, die jedoch das Paket selbst nicht verändern. Die Markierung erlischt, sobald das Paket die Firewall wieder verlässt. Die Art und Weise, wie diese markierten Pakete den Filtern der QDisc dienlich sind, ist in Kapitel 3.3.1 erläutert.
2.4 Die Raw-Tabelle
Die Raw-Tabelle besteht nur aus der PREROUTING-Chain und der OUTPUT-Chain, wobei ein vom Netzwerk kommendes Paket vor allen anderen Ketten zuerst die PREROUTING- Kette und ein lokal erzeugtes Paket zuerst die OUTPUT-Kette der Raw-Tabelle durchläuft (siehe Abbildung 3).
Mit der Raw-Tabelle ist es z. B. möglich, bestimmte Pakete vom Connection Tracking auszuschließen.
3 Traffic Control
Traffic Control ist notwendig, um den vorhandenen Netzwerkverkehr gezielt zu beeinflussen. Dabei stellt Traffic Control einen Überbegriff dar, der aus folgenden Elementen besteht4 :
- Shaping
- Scheduling
- Classifying
- Policing
- Dropping
- Marking
Unter Shaping versteht man eine beabsichtigte Verzögerung der Weiterleitung von Paketen, sodass eine gewünschte Bandbreite erreicht wird.
Scheduling ist ein Mechanismus, der eingehende Pakete so anordnet, dass diese in der gewünschten Reihenfolge die Queue wieder verlassen. Im einfachsten Fall handelt es sich dabei um einen einfachen FIFO-Scheduler. Prinzipiell kann aber jeder Traffic Controll- Mechanismus, der den ausgehenden Netzwerkverkehr bearbeitet, als Scheduler betrachtet werden.
Beim Classifying werden Pakete, die unterschiedlich in Bezug auf die Weiterleitung behandelt werden müssen, klassifiziert und abschließend in eine speziell für diese Art von Paket vorgesehene Queue gestellt.
Policing ist ebenso wie das Shaping ein Mechanismus, der den Netzwerkverkehr begrenzt. Der Unterschied jedoch ist, dass Shaping auf der ausgehenden Seite angewandt wird und Policing den eingehenden Datenverkehr kontrolliert. Liegt die Bandbreite nicht über einem bestimmten Limit, darf der Netzwerkverkehr passieren. Wird dieses Limit jedoch überschritten, so werden so viele Pakete verworfen, bis die definierte Bandbreite wieder hergestellt ist. Das ist der nächste Unterschied gegenüber dem Shaping-Mechanismus: Beim Policing ist kein Mechanismus dafür vorgesehen, Pakete in eine Warteschlange zu stellen und zu verzögern.
Unter Dropping versteht man einen Mechanismus, der Pakete mit bestimmten Eigenschaften verwirft.
Beim Marking werden die ersten sechs Bits im TOS-Feld des IP-Headers modifiziert (bei IPv4), um die Priorität des Pakets zu kennzeichnen. Diese markierten Pakete werden dann von den anderen Routern innerhalb einer administrativen Domain entsprechend behandelt. Bezüglich des TOS-Felds ist noch anzumerken, dass sich dessen Bedeutung innerhalb der letzten Jahre geändert hat. Im RFC 7915 aus dem Jahr 1981 hat das TOS-Feld, welches das zweite Oktett im IP-Header ist, folgende Bedeutung:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: TOS-Feld
Die ersten drei Bits spezifizieren dabei die Dringlichkeit eines IP-Pakets. Die QoS- Eigenschaften werden in den darauf folgenden drei Bits festgelegt. Der Host kann dabei bestimmen, ob er einen geringen Delay (D), einen hohen Durchsatz (T) oder Zuverlässigkeit (R) wünscht. Bit 6 und 7 bleiben unbenutzt. Theoretisch kann ein Router anhand dieser drei Felder QoS bewerkstelligen, praktisch wird dieses Feld heutzutage ignoriert. Aus diesem Grund wurde das TOS-Feld etwas modifiziert, um es den Differentiated Services, kurz DiffServ, anzupassen. Abbildung 5 zeigt den Unterschied.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: DiffServ-Feld
Die ersten sechs Bits geben hier an, zu welcher Dienstklasse ein Paket gehört. Diese Dienstklassen umfassen unter anderem auch die historischen Klassen, damit eine Kompatibilität gewährleistet ist.
Die beiden nachfolgenden Kapitel 3.1 und 3.2 geben einen grundlegenden Überblick über einige der in Linux verwendeten Traffic Control-Werkzeuge.
3.1 Classless Queueing Disciplines
Klassenlose QDiscs sind nicht annähernd so flexibel wie ihre klassenbehafteten Pendants. Trotzdem reicht es in bestimmten Fällen, auf diese zurückzugreifen. Will man lediglich den Netzwerkverkehr für eine gesamte Schnittstelle limitieren oder Wartezeiten fair verteilen, so reichen die klassenlosen QDiscs vollkommen aus.
Eine weitere Existenzberechtigung der Classless QDiscs liegt in der Natur der Classful QDiscs: An deren Leaf-Klassen müssen sich letztendlich wieder klassenlose QDiscs befinden.
3.1.1 pfifo_fast
Die pfifo_fast-Queue wird den physikalischen Netzwerkschnittstellen vom Kernel defaultmäßig zugeordnet. Hierbei handelt es sich um eine Queue, die drei sogenannte Bänder beinhaltet, wie in Abbildung 6 schematisch dargestellt ist. Jedes dieser Bänder arbeitet nach dem First-In-First-Out-Prinzip. Dabei werden die einzelnen Bänder unterschiedlich bevorzugt: Befinden sich in Band 0 noch Pakete, so werden eventuell vorhandene Pakete in
Band 1 nicht weitergeleitet. Analog verhält es sich zwischen Band 1 und dem niedrigstprioren Band 2.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: pfifo_fast
Die Entscheidung, welches Paket welchem Band zugeordnet wird, wird anhand des TOS-Feldes im IP-Header getroffen. Diese vier Bits (Bit 3 bis 6 im Type-Of-Service-Oktett) kennzeichnen das Paket in Bezug auf die gewünschten QoS-Eigenschaften und werden in6 folgendermaßen spezifiziert:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Bedeutung der TOS-Bits
Aufgrund des 4 Bit breiten Feldes ergeben sich 16 mögliche Kombinationen, die der Linux-Kernel auf eine bestimmte Priorität mappt und diese Priorität in weiterer Folge einem Band zuordnet. Die modifizierte Tabelle 2 beschreibt die defaultmäßige Zuordnung von TOS-Bits zu den Bändern7. Hier ist unter anderem ersichtlich, dass Paketen von interaktiven Anwendungen, die eine minimale Verzögerungszeit benötigen, eine Zuordnung zu Band 0 erfolgt. Das ist auch notwendig, denn ein Mapping auf ein anderes Band bedeutet für das Paket, dass es unter Umständen so lange auf den Weitertransport warten muss, bis die höherprioren Bänder leer sind. Dies würde die Verzögerungszeit negativ beeinflussen.
Die Umsetzung der Linux Priority auf die Bänder (priomap) kann man sich auf der Kommandozeile anzeigen lassen. Die standardmäßige Einstellung sieht folgendermaßen aus:
1, 2, 2, 2, 1, 2, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Priority Mapping
Diese Ausgabe kann man anhand eines Beispiels folgendermaßen interpretieren: Pakete mit interaktivem Inhalt sind laut Tabelle 2 der Linux Priority 6 zugeordnet. An der sechsten Stelle der Ausgabe - von 0 beginnend - wird angezeigt, dass diese Pakete dem Band 0 zugeteilt werden.
Die Größe der Queue kann nicht mit dem tc-Befehl verändert werden. Diese Einstellung muss über ifconfig bzw. ip vorgenommen werden.
3.1.2 bfifo und pfifo
Diese beiden QDiscs sind schlichte FIFO-Queues. Sie priorisieren eingehende Pakete in keiner Weise. Der Algorithmus dieser beiden Warteschlangen, in Abbildung 7 dargestellt, ist auch dementsprechend simpel: Trifft ein zu sendendes Paket ein, wird es am Ende einer Liste eingefügt. Soll ein Paket gesendet werden, so wird jenes verschickt, dass sich am Anfang der Liste befindet.
Mit dem Parameter „limit“ kann die maximale Queue-Größe eingestellt werden. Hier liegt auch der Unterschied zwischen diesen beiden QDiscs: bfifo interpretiert diesen Wert als Byte-Größe, pfifo hingegen als die Anzahl der Pakete.
Wird die Liste zu groß, werden keine weiteren Pakete mehr akzeptiert. Dies bezeichnet man auch als „tail drop“8.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7: bfifo/pfifo
3.1.3 Stochastic Fairness Queueing (SFQ)
Dieser Algorithmus sorgt für Fairness für alle bestehenden Verbindungen. Dazu verwendet er 127 FIFO-Queues, die alternierend nach dem Round-Robin-Verfahren senden (siehe Abbildung 8).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: Stochastic Fair Queueing
Welche Verbindung an welche Warteschlange gekoppelt wird, wird dabei durch ein Hashverfahren entschieden. Dabei kann es vorkommen, dass sich mehrere Verbindungen eine Queue teilen müssen. Damit diese Unfairness so weit als möglich beseitigt wird, wechselt der SFQ-Algorithmus die Hashfunktion in periodischen Abständen.
Die Dauer dieses Zeitabstandes kann dabei optional angegeben werden (perturb). Ein weiterer optionaler Parameter bestimmt die Paketgröße, die eine Queue auf einmal senden darf (quantum). Hier gilt es zu beachten, dass der übergebene Wert die MTU nicht unterschreitet; größere Pakete würden die Warteschlange in diesem Fall nie verlassen.
Durch die Verwendung eines Round-Robin-Verfahrens entsteht bei diesem Algorithmus auch der Vorteil, dass die Auswirkungen eines DoS-Angriffs abgeschwächt werden9.
3.1.4 Token Bucket Filter (TBF)
Token Bucket Filter arbeiten als Shaper. Sie werden dazu verwendet, um die ausgehende Datenrate gezielt zu drosseln. Das passiert auf Basis eines sogenannten Buckets, der kontinuierlich mit Tokens gefüllt wird. Ein Token repräsentiert dabei eine bestimmte Bytegröße.
Wird ein Paket zum Senden freigegeben, so benötigt es die entsprechende Anzahl an Tokens, um weitergeleitet werden zu können. Ist diese Menge im Bucket nicht vorhanden, so kann das Paket nicht gesendet werden und muss so lange in einer Queue verweilen, bis die erforderliche Menge an Tokens verfügbar ist. Diese Queue ist als innere Klasse des TBF realisiert, deren Größe der Benutzer durch den limit-Parameter festlegen kann. Wenn die Queue voll ist, werden weitere einlangende Pakete verworfen. Abbildung 9 verdeutlicht das Prinzip des TBF.
Folgende drei Szenarien sind möglich, wenn weiterzuleitende Pakete eintreffen:
- Die Pakete treffen mit derselben Geschwindigkeit ein, wie entsprechende Tokens erzeugt werden:
Die QDisc kann jedes Paket sofort weitersenden, da genügend Tokens vorhanden sind und diese auch nicht restlos verbraucht werden.
- Die Pakete treffen langsamer ein, wie entsprechende Tokens erzeugt werden:
Auch in diesem Fall wird jedes Paket aufgrund der Existenz von Tokens sofort weitergeleitet. Der Bucket füllt sich bis zu einer vordefinierten Grenze (mittels burst-Parameter) mit Tokens, wird diese erreicht, werden weitere Tokens verworfen.
- Die Pakete treffen schneller ein, wie entsprechende Tokens erzeugt werden:
Jedes Paket wird mit der größtmöglichen Geschwindigkeit weitergeleitet, so lange Tokens vorhanden sind. Wenn das letzte Token verbraucht ist, werden die weiteren Pakete in eine Queue gestellt und können erst dann gesendet werden, wenn die benötigte Anzahl an Tokens wieder zur Verfügung steht. In diesem Szenario erfüllt der TBF seine eigentliche Aufgabe der Bandbreitenbegrenzung, wobei er einen kurzfristigen Burst in der Größe des Buckets erlaubt.
Will man auch diesen kurzfristigen Burst nicht gestatten bzw. limitieren, so kann man dafür den peakrate-Parameter verwenden. Die peakrate ist dabei als ein zweiter TBF realisiert, welcher einen kleineren Bucket verwendet.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 9: Token Bucket Filter
3.1.5 Weitere Classless Queueing Disciplines
Die oben angeführten QDiscs sind die bekanntesten und am meisten dokumentierten klassenlosen Algorithmen. Es existieren aber noch weitere, teilweise in den Man-Pages unerwähnten, Classless Queueing Disciplines, u.a.:
- ESFQ (Extended SFQ): Im Prinzip handelt es sich um denselben Algorithmus wie beim SFQ, jedoch hat man die Möglichkeit, mehr Parameter zu beeinflussen. So kann der Benutzer etwa bestimmen, welcher Hash-Algorithmus verwendet wird.
- RED bzw. GRED ((Generic) Random Early Drop): Bei diesem Algorithmus wird die Tatsache ausgenutzt, dass TCP die Bandbreite automatisch verringert, wenn zu viele Pakete verloren gehen. RED verwirft gezielt ankommende Pakete, sobald die Queue eine bestimmte Größe erreicht hat. Durch diesen Algorithmus erreicht man eine Verbesserung der Latenzzeit.
3.2 Classful Queueing Disciplines
Jeder Netzwerkschnittstelle kann nur eine QDisc zugeordnet werden. Für einfache Strukturen reichen die klassenlosen QDiscs aus. Werden die Strukturen jedoch komplexer, so sind diese nur unter Zuhilfenahme von Klassen zu bewerkstelligen.
Mit Hilfe von Klassen und Filtern, auf die später noch eingegangen wird, ist es möglich, jede Art von Netzwerkverkehr unterschiedlich zu behandeln.
Die Basis einer Classful QDisc bildet die Root-QDisc, welche direkt an die Netzwerkschnittstelle angebunden ist. Eine oder mehrere Klassen werden der Root-QDisc hierarchisch untergeordnet. Diesen Klassen können in weiterer Folge wiederum Klassen oder QDiscs angehängt werden. Am Ende des Baumes befinden sich die sogenannten leaf classes , an denen noch eine abschließende (klassenlose) QDisc angehängt werden muss, da die Klassen selber keine Pakete verarbeiten können. Wenn die letzte QDisc nicht explizit angegeben wird, dann wird die Default-QDisc pfifo_fast verwendet.
Die Funktionsweise einer Classful QDisc gestaltet sich grundsätzlich auf folgende Art: Treffen Netzwerkpakete in der Root QDisc ein, werden diese dort anhand von Filterregeln klassifiziert werden und an die entsprechenden Klassen weitergeleitet. Diese Kindklassen können wieder eigene Filterregeln verwenden, um die Pakete einer neuen Klassifikation zu unterziehen. Letztendlich kommt das Netzwerkpaket bei einer klassenlosen QDisc am Ende des Baumes an. Anzumerken an dieser Stelle ist noch, dass ein Netzwerkpaket keinesfalls den ganzen Baum durchlaufen muss, bis es zu der QDisc anlangt, die für dessen Bearbeitung verantwortlich ist. Es ist sogar üblich, dass in der Root QDisc eine Default-(leaf)Klasse angegeben wird, an die jene Pakete direkt weitergeleitet werden, die keinen Filterregeln entsprechen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 10: Klassenhierarchie
In Abbildung 10 wird eine typische Klassenhierarchie gezeigt. An oberster Stelle befindet sich die Root QDisc (1:), der direkt 2 Klassen untergeordnet sind (1:1 und 1:2). Die Klasse 1:1 ist die Elternklasse von den beiden Klassen 1:10 und 1:11. Die beiden letztgenannten Klassen stehen in einer Sibling-Beziehung zueinander. Der Klasse 1:2 ist nur die Kindklasse 1:20 untergeordnet. Allen drei Leaf-Klassen ist zu guter Letzt noch jeweils eine QDisc angehängt, die die Pakete entsprechend verarbeiten.
Die Bezeichnungen der Klassen und QDiscs bestehen aus einer Major- und einer Minor-Nummer (jeweils ein 16-Bit-Integerwert). Die Major-Nummer kennzeichnet die QDisc, der eine Klasse angehört, die Minor-Nummer die Klasse selbst. Die Minor-Nummer einer QDisc ist immer 0, die Angabe dieses Wertes ist optional. Anders bei den Klassen, hier muss die Minor-Nummer ein ganzzahliger Wert größer 0 sein. Des Weiteren müssen die Minor-Nummern innerhalb einer QDisc eindeutig sein.
3.2.1 PRIO QDisc
Die Funktionsweise dieser QDisc ist ähnlich der von pfifo_fast. Die Bänder sind in der PRIO QDisc jedoch als Klassen realisiert. Diese Klassen - per Default drei - müssen nicht explizit erstellt werden, sie werden beim Anlegen der QDisc automatisch erzeugt. Band n entspricht dabei der Minor-Nummer n+1, d.h., die höchstpriore Klasse hat die Klassen-ID :1.
Mit dem optionalen bands-Parameter kann man die Anzahl der Klassen bestimmen, die die PRIO QDisc erzeugen soll. Ebenfalls optional, aber bei Modifizierung des bands-Parameters zwingend, ist der priomap-Parameter. Die Funktionsweise der priomap ist in Kapitel 3.1.1 beschrieben.
Neben dem Vorteil, dass man die Anzahl der Bänder bestimmen kann, bietet die PRIO QDisc noch einen weiteren: Die Art und Weise, nach welchen Kriterien eingehende Pakete klassifiziert werden, ist nun nicht mehr alleine auf die TOS-Bits beschränkt. Als weitere Möglichkeit steht eine Klassifizierung anhand eines Filters, der an die QDisc angehängt ist, zur Verfügung. Die dritte Option besteht darin, dass ein Prozess mit entsprechend ausgestatteten Rechten die Zielklasse mittels SO_PRIORITY selbst bestimmen kann10.
Die Vorteile dieser QDisc entsprechen denen der pfifo_fast: Pakete, die eine minimale Verzögerung fordern, können in eine hochpriore Klasse weitergeleitet werden, um deren QoS-Anforderungen nachzukommen. Jedoch entstehen auch Nachteile. Herrscht in den Klassen mit niedriger Klassen-ID viel Netzwerkverkehr, kann es vorkommen, dass die Pakete in den niederwertigeren Klassen nie oder selten zum Zug kommen (Starvation). Abhilfe schafft hier ein Shaper, z.B. ein TBF, der die Bandbreite für die hochprioren Klassen auf ein vernünftiges Maß reduziert.
3.2.2 Hierarchical Token Bucket (HTB)
Der HTB-Algorithmus ist im Linux-Kernel ab Version 2.4.20 enthalten. Für ältere Versionen steht jedoch ein Patch zur Verfügung11.
Während beim klassenlosen TBF die Sendeleistung nur generell begrenzt werden kann, so ist es beim HTB durch den Einsatz von Klassen und einer geeigneten Definition der Struktur der Klassenhierarchie möglich, das Sendeverhalten in Bezug auf die Übertragungsbandbreite gezielter zu steuern. Der Algorithmus verwendet für jede einzelne Klasse das obengenannte Prinzip des Token Bucket Filter. So kann man etwa - entsprechende Filterregeln vorausgesetzt - Bandbreiten für bestimmte User, IP-Adressen, Portnummern u.v.m. garantieren. Über diese garantierte Bandbreite hinaus kann auf Wunsch auch ein Limit definiert werden, falls Bandbreite an anderer Stelle nicht genutzt wird (Borrowing).
Eine einfache Hierarchie eines HTB ist in Abbildung 11 dargestellt. Als Gesamtbandbreite werden von der Root-QDisc 1000 kbit/s zur Verfügung gestellt. Die Kindklassen werden so konfiguriert, dass beide Benutzer eine garantierte Bandbreite von jeweils 500 kbit/s verwenden können. Das Quantum von User A wird hier noch einmal aufgeteilt, einerseits in eine garantierte Bandbreite von 400 kbit/s für allgemeine Daten, andererseits in eine garantierte Bandbreite von 100 kbit/s für Sprachtelefonie.
[...]
1 Russell, Rusty., iptables (8). [manual page]
2 Amberg, Eric., Linux-Server mit Debian GNU/Linux. 2. Auflage. Heidelberg, München, Landsberg, Frechen, Hamburg : mitp, 2009.
3 Spenneberg, Ralf., Linux-Firewalls mit iptables & Co. München : Addison-Wesley Verlag, 2006.
4 Brown, Martin A., "Traffic Control HOWTO." [Online] 1.0.2, Oktober 2006. [Zitat vom: 15. Dezember 2009.] http://www.tldp.org/HOWTO/pdf/Traffic-Control-HOWTO.pdf.
5 Postel, Jon., RFC 791. [Online] September 1981. [Zitat vom: 22. Jänner 2010.]
http://www.ietf.org/rfc/rfc791.txt.
6 Almquist, Philip., RFC 1349. [Online] Juli 1992. [Zitat vom: 15. Dezember 2009.]
http://www.ietf.org/rfc/rfc1349.txt.
7 Hubert, Bert., "Linux Advanced Routing & Traffic Control HOWTO." [Online] 1.43, 29. Oktober 2003. [Zitat vom: 15. Dezember 2009.] http://lartc.org/lartc.pdf.
8 Kuznetsov, Alexey N., bfifo/pfifo (8). [manual page]
9 Kuznetsov, Alexey N. tc-sfq (8). [manual page]
10 Kuznetsov, Alexey N. tc-prio (8). [manual page]
11 Devera, Martin und Cohen, Don., "HTB Linux queuing discipline manual - user guide." [Online] 5. Mai 2002. [Zitat vom: 15. Dezember 2009.] http://luxik.cdi.cz/~devik/qos/htb/userg.pdf.