Der IPCop als QoS-System war damals meine Facharbeiter-Prüfung. Die eigentliche Funktion dieser Firewall-Lösung liegt eigentlich mehr in der Absicherung des LANs und WLANs gegenüber einer DMZ und/oder dem Internet. Ich werde Euch in dem Artikel zeigen, wie man den Cop mit Hilfe einiger Addons zu einem QoS-System umwandeln kann.

Wozu braucht man QoS (Quality of Service) überhaupt?

Wer als Online-Spieler nebenbei Downloads/Uploads über seinen Internet-Anschluss laufen hat (sei es, weil er selber downloaded oder ein anderer im Netzwerk es tut), der wird die Probleme mit Paketverlusten und stark erhöhten Latenzen während des Spielens kennen. Besonders schlimm wird das Ganze, wenn Filesharing dazu kommt. Hier kann ein zentrales QoS-Management helfen und die Symptome etwas eingrenzen.

Eine weitere Möglichkeit bietet das Trafficshaping: Bestimmte Dienste (http, ftp, ssh etc.) oder Hosts können hierbei in ihrer Bandbreite limitiert oder eine bestimmte Bandbreite garantiert werden. Das ist vor allem dann sinnvoll, wenn man z.B. noch genügend Bandbreite für Skype oder TS3 übrig haben will, um keine abgehakten Gespräche zu haben, obwohl im Hintergrund oder bei anderen LAN-Teilnehmern noch irgendwelche Downloads oder automatische Updates laufen. Oder ein bestimmter Server in der DMZ soll eine garantierte Bandbreite bekommen, um immer ausreichend erreichbar zu sein.

QoS macht aus eurer 16000er Leitung keine 18000er Leitung. QoS steht für eine bestimmte Dienstgüte (Bandbreite, Latenz), weitestgehend unabhängig von der Aus- und Belastung der Leitung. Daher wird mit QoS die Bandbreite sogar eher kleiner, ist dafür aber nach genauen Kriterien (Regeln) unter den Hosts und/oder Diensten verteilt.

Verstößt QoS nicht gegen die Netzneutralität?

QoS ist genau das, was große Internet-Provider im Internet durchsetzen wollen, um z.B. von Videoportalen wie youtube.com Geld zu kassieren, damit deren Traffic bevorzugt zu den Endkunden geleitet wird, was dann einen Wettbewerbsvorteil gegenüber anderen Videoportalen verschafft. Das funktioniert natürlich auch andersrum: Endkunden werden von den Providern dann bestimmte „youtube XXL“- oder „Video-Superspeed“-Optionen zu ihrem Internetanschluss angeboten bekommen, damit der Endkunde die Videos dann schneller laden kann – wobei „schneller laden“ wohl die falsche Wortwahl ist, ein „Nicht-Ausbremsen“ der Videos gegenüber anderen, die diese Optionen dann nicht hinzubuchen, trifft es wohl eher. Zur Zeit benutzt man QoS in NGN-Netzen, um z.B. VoIP-Telefonie in einer vernünftigen Qualität sicherzustellen, was an sich auch eine gute Maßnahme ist, solange man einfach ALLE VoIP-Daten gegenüber ALLEN anderen Datenpaketen bevorzugt, unabhängig deren Herkunft, Ziel oder Inhalt.

In diesem Artikel geht es aber um den Übergang LAN<->Internet. Was der Provider im Anschluss mit den Daten macht, liegt nicht mehr in unserer Hand. Durch viele Tests stellte sich aber heraus, dass gerade der Übergang von einem gut bestückten LAN hin zum Internet die größten Optimierungsmöglichkeiten hinsichtlich Latenz und Bandbreite bietet.

Aber genug der Vorworte, bevor wir jetzt loslegen noch einige Hinweise:

Die hier verwendete Version 1.4.21 ist veraltet. Zum Zeitpunkt der Artikel-Erstellung ist die Version 2.02 aktuell. Für den „neuen“ IPCop gibt es (noch) keine passenden QoS-Addons, nur ein vereinfachtes Script zur Trafficlimitierung.
Der 1.4.21er Cop wird unter Umständen Probleme mit neuer Hardware bekommen, vor allem auch, weil er noch auf den 2.4er Linux-Kernel basiert. Wenn ihr das hier also nachstellen wollt, klärt erstmal die Kompatibilität ab. Problematisch sind vor allem AHCI-/Raid-Sata Controller (wenn möglich im BIOS auf „IDE-kompatibel“ umstellen) und Netzwerkkarten (PCIe-Varianten z.B.). Da wir hier auch noch einen modifizierten IPCop-Kernel verwenden, wird auch das Nach-Kompilieren von Treibermodulen problematisch.
Ansonsten reicht sogut wie jeder alte x86-fähige Rechner aus, wichtig ist nur, dass er mindestens 2 Netzwerkkarten (für Rot+Grün Konstellation) besitzt, die vom IPCop auch erkannt werden.
Die SMP-Variante des modifizierten Kernels von xpapa (embcop.org) produziert leider Kernel-Panics, so dass man auf Mehrkern-Unterstützung verzichten muss. Die Original-IPCop-SMP-Kernel funktionieren hingegen einwandfrei.

1. Installation des IPCop

Die Installation kürz ich hier stichpunktartig ab und ist auch abhängig vom jeweiligen Netzwerkaufbau. Ich nehm hier die einfache RED+Green Anordnung mit dem meist vorhandenen DSL-Router als Gateway für die rote Schnittstelle (statische IP-Vergabe, IP muss natürlich im „LAN“-Bereich des DSL-Routers sein, ansonsten geht natürlich auch DHCP, falls ein entsprechender DHCP-Dienst im DSL-Router läuft). Wer bei seinem DSL-Router die Routerfunktionalität abschalten kann, bzw sogar nur ein Modem hat (z.B. beim Kabelmodem), kann auch dem IPCop die Einwahl überlassen. Hierzu muss dann aber bei der roten Schnittstelle die PPPoE-Einwahl ausgewählt und die entsprechenden Einwahldaten (gibts vom Provider) angegeben werden. Wer hier genaueres wissen will, den verweis ich auf die offizielle Anleitung.

Start des Setups
automatische Formatierung und Partitionierung der Festplatte
automatische Erkennung der Netzwerkkarte für die GREEN-Schnittstelle
IP-Adresse der GREEN-Schnittstelle: 192.168.0.1 (muss sich natürlich vom LAN-Netz des DSL-Routers unterscheiden)
Subnetmaske GREEN-Schnittstelle: 255.255.255.0
Tastaturlayout: de (Deutsch)
Zeitzone: MEZ
Hostname: ipcop
Domainname: localdomain
Typ der Netzwerkkonfiguration: GREEN+RED
Treiber- und Karten-Zuordnungen: automatische Erkennung der 2. Netzwerkkarte und Zuweisung zur RED-Schnittstelle
Adress-Einstellungen: Statisch
IP-Adresse RED-Schnittstelle: 192.168.1.2 (IP muss sich im LAN des DSL-Routers befinden und darf nicht vergeben sein)
Subnetmaske RED-Schnittstelle: 255.255.255.0 (selbe wie beim DSL-Router)
DNS-Server: 192.168.1.1 (DSL-Router IP)
Gateway: 192.168.1.1 (DSL-Router IP)
Aktivierung des DHCP-Servers (nicht zu verwechseln mit dem DSL-Router seitigen DHCP-Server)
Passworteingabe für „root“, „admin“ und „backup“
Neustart

Nach dem Neustart kann man die IPCop Admin-Oberfläche im Browser über https://ipcop.localdomain:445 erreichen. Das geht natürlich nur über einen Client, der sich im „grünen“ Netz befindet – entweder mit nem Ethernet-Kabel direkt an der grünen Schnittstelle (1 PC only), oder an einem gemeinsam angeschlossenen Switch (für ein größeres LAN).

Jetzt kann man bequem Einstellungen über die Weboberfläche oder per ssh (nach Freischaltung) vornehmen. Die herunterladbare Version 1.4.20 sollte dann als erstes über das Webfrontend auf Version 1.4.21 aktualisiert und der ssh-Zugriff aktiviert werden. Die einzelnen Optionen sind im offiziellen Admin-Handbuch beschrieben.

2. Installation benötigter Addons

2.1. modifizierten Kernel mit L7-Filter/IMQ-Unterstützung installieren

Voraussetzung für die Installation des QoS- oder QoS_NG Addons ist die Installation eines Kernels, der vor allem Layer-7 Pattern und das IMQ-Interface unterstützt. Der Standard-Kernel des IPCop beherrscht dies nicht. Man sollte sich auch im klarem sein, dass dieser Schritt den IPCop dann inkompatibel mit für den originalen IPCop kompilierten Treibern macht. Die Kernel stammen von xpapa von der embcop.org-Seite, die leider nicht mehr gepflegt wird.

Kernel runterladen und am besten unter /tmp speichern.UMP-Kernel: ipcop-1.4.21-kernel-2.4.36.tar.bz2
SMP-Kernel: ipcop-1.4.21-kernel-2.4.36.6-smp.tar.bz2 (produzierte bei mir wie gesagt nach einigen Tagen kernel panics)
cd /tmp
mit
tar xvfj ipcop-1.4.21-kernel-2.4.36.tar.bz2 –C /
entpacken.
touch /var/run/need-depmod-`uname -r` ausführen
neustarten

2.2. QoS-Addon installieren

Der Autor dieses Addons ist Markus Hoffmann und auf seiner Seite findet man noch so manch andere interessante Addons. Hier nochmal Dank an seine Arbeit.

Addon runterladen und nach /tmp speichern (ich nutze selber das QoS_NG-Addon)QoS (hfsc-Protokoll): qos_ipcop_1.4.21.tar.gz
QoS_NG (htb-Protokoll): qos_ng_ipcop_1.4.21.tar.gz
cd /tmp
entpacken:
tar xfz qos_ng_ipcop_1.4.21.tar.gz
cd qos_ng
./install
eintipseln. (nicht qos_ng/install benutzen, da sonst Fehler bei der Installation auftreten und der Oberordner gelöscht wird!)
Die „Update layer7-patterns right now ?“-Frage kann man beneinen, da es die Quelle, die im Script angegeben ist, nicht mehr gibt. Die L7-Pattern werden manuell aktualisiert.

2.3. Layer-7-Pattern aktualisieren

Damit wir auch die letzten Layer-7 Pattern haben, laden wir uns die nochmal gesondert runter. Die Original-L7-Protokolle gibts zur Zeit bei der ClearFoundation, die auch das ClearOS basteln.

L7-Pattern runterladen und am besten wieder nach /tmp kopieren:
l7-protocols-2009-05-28.tar.gz
cd /tmp
tar xfz l7-protocols-2009-05-28.tar.gz
alte L7-Protokolle entfernen:
rm -rf /etc/l7-protocols/*
neue L7-Protokolle hinzufügen:
cp -R l7-protocols-2009-05-28/* /etc/l7-protocols/

So, damit haben wir das Grundgerüst beisammen. In der Weboberfläche wurde jetzt übrigens unter dem Menü „Dienste“ der Menüpunkt „Trafficshaping“ durch „QoS“ ersetzt. Wenn man alles richtig gemacht hat, sollte die QoS-Oberfläche in etwa so aussehen:

3. QoS richtig einstellen

Hierzu gibt es wieder eine gute Anleitung und der Witz dabei, die befindet sich in der Weboberfläche unter „Hilfe“ :). Ergo erspar ich mir die ersten Schritte und gebe lieber ein paar fortgeschrittene Tips.

3.1. Kernelmeldungen und r2q-Wert anpassen

Setzt die garantierte Bandbreite irgendeiner Klasse nicht auf 0 oder 1 kbit/s runter, ihr bekommt sonst Kernelmeldungen (var/log/messages), dass das Quantum bestimmter Klassen zu klein oder zu groß ist und man solle den „r2q“-Wert ändern:

Jan  1 23:41:29 ipcop kernel: HTB: quantum of class 20002 is big. Consider r2q change.
Jan  1 23:41:29 ipcop kernel: HTB: quantum of class 10175 is small. Consider r2q change.

So in etwa sieht das dann aus. Ich nehme bei unserem ADSL-Anschluss (11000/900kbit sync) einen unteren Wert von 30kbit für die Filesharing-Upload-Klasse. Des Weiteren würde ich in der Datei /var/ipcop/qos/bin/qos.pl die r2q-Berechnung ändern (ab Zeile 293, nach „Specify queue discipline“ suchen). Wie man sieht, hat der liebe Herr Hoffmann hier auch schon einiges rumprobiert. Ich empfehle folgendes:

Die Zeile

$R2Q = int ( ($RATE * 1024) / 16384 );

auskommentieren:

# $R2Q = int ( ($RATE * 1024) / 16384 );

und stattdessen folgendes einfügen:

if ( "$IFACE" eq "eth1" )
{
$R2Q=3;
}
else
{
$R2Q=12;
}

„eth1“ solltet ihr mit eurem „Upload“-Interface (also dem RED Interface) ersetzen (bei Modem ist das z.B. ppp0). Damit wird für das RED-Interface der r2q von 3 gesetzt und für alle anderen Interfaces (ich benutze nur noch das IMQ-Interface als „Download“-Interface) der Wert von 12 (also primär für asynchrone Leitungen gedacht). Mit diesen Settings hab ich bei mir keine Kernelmeldungen mehr. Am Ende noch abspeichern und QoS in der Weboberfläche neustarten. In der /var/log/messages könnt ihr dann nachschauen, ob bei euch alles passt, zur Not müsst ihr bisschen rumtüfteln (die Formel ist übrigens: quantum = rate/r2q).

3.2. Root-Klassen

Bei der Wahl der Root-Klassen solltet ihr immer folgende Standardregeln im Hinterkopf behalten:

Upload Shaping wird auf dem Roten Interface (eth1 oder ppp0 meistens) vorgenommen.
Für das Internet-Download Shaping benutzt ihr das IMQ-Interface.
Für Host orientiertes Download Shaping müsst ihr das Green-Interface (eth0) benutzen.

Hintergrund: Das IMQ-Interface hat als Ziel immer die rote Schnittstelle (man kann also keinen Host im LAN als Ziel angeben!). Weiterhin hat das IMQ-Interface den Vorteil, (Internet-)Download-Shaping zu ermöglichen, ohne die meist deutlich höheren, Lan seitigen Geschwindigkeiten (z.B. 16MBit ADSL2 vs. 100MBit Fast-Ethernet) begrenzen zu müssen. So lange man nur 2 Schnittstellen im IPCop benutzt, ist das nicht weiter kritisch. Hat man aber auch noch eine DMZ oder WLAN, dann würde man ohne IMQ-Interface auch den Traffic zwischen Grün<->(Orange || Blau || IPCop) beschneiden. Wenn man so wie wir in der DMZ einen vorgelagerten Proxy-Cache verwendet, würde jeglicher Traffic, der aus dem Cache des vorgelagerten Proxy kommt, ausgebremst.

3.3. Ack-Priorität auf die höchstpriorisierte Upload-Klasse setzen

Das sollte man auf jeden Fall tun, wie in der Anleitung ja schon beschrieben. Dadurch bricht nämlich der Download nicht so krass zusammen, wenn jemand den Upload „besetzt“.

3.4. Download shapen/priorisieren

Benutzt das IMQ-Interface, wenn ihr den Downstream der Internetverbindung shapen und priorisieren wollt. Erstellt ihr hier Regeln, könnt ihr auch keine Ziel-Adresse angeben, das Ziel ist nämlich immer das Rote Interface.
Wollt ihr den Internet-Download zielbasiert im LAN (also 192.168.1.35 bekommt 1000kbit und 192.168.1.50 bekommt 500kbit etc.) shapen, müsst ihr dies mit dem Grünen Interface machen (in der Regel eth0), was wiederum den Nachteil hat, dass dann der komplette grüne Traffic auf diese Bandbreiten begrenzt wird, auch wenn z.B. nur Daten zwischen Blau/Orange und Grün ausgetauscht werden sollen (es sich also gar nicht um Internet-Traffic handelt).
Wollt ihr bestimmte Dienste, die im Internet erreichbar sind, klassifizieren, benutzt den Dienst als Quellport.
Portranges werden mit Doppelpunkt und Leerzeichen vor und nach dem Doppelpunkt! angegeben, also z.B. 6112 : 6119

3.5. Upload shapen/priorisieren

Wer eine richtig gute Ping in der höchsten Klasse haben möchte, sollte die maximale Rate der RED-Interface root-Klasse nicht auf 90% (wie in der Anleitung und bei der Erstellung empfohlen) sondern eher auf 50-60% setzen. Zumindest gilt dieser Prozentsatz bei uns mit 900kbit gesynctem Upstream. Es kann sein, dass bei bedeutend stärkerem Upload das wieder nach oben gesetzt kann, das konnte ich mangels passendem Internet-Anschluss noch nicht testen :P.
Wollt ihr bestimmte Dienste, die im Internet erreichbar sind, klassifizieren, benutzt den Dienst als Zielport.
Wollt ihr bestimmte Dienste, die bei euch aus dem Internet erreichbar sind (also Server, die bei euch in Green/Orange/Blue stehen), klassifizieren, benutzt den Dienst als Quellport.
Genauso könnt ihr natürlich auch euren heimischen „Internet“-Server per Quell-IP klassifizieren.Hier wird dann die lokale IP des Servers eingetragen.
Portranges werden mit Doppelpunkt und Leerzeichen vor und nach dem Doppelpunkt! angegeben, also z.B. 6112 : 6119

3.6. Reihenfolge der Regeln

Die Reihenfolge der Regeln ist nicht ganz unwichtig, da es durch bestimmte Konstellationen durchaus zu Überschneidungen kommen kann. So kann man eine allgemeine Layer-7 Regel für http haben, die in Klasse 250 „matchen“ soll und eine weitere Port 80 basierte Regel mit einer bestimmten Quell-IP, die in Klasse 220 matchen soll. Dann wird man feststellen, dass letztere nicht wirkt.

Es gilt:

Layer-7 Regeln haben Vorrang gegenüber Port-basierten Regeln
Innerhalb der jeweiligen Varianten gilt die Reihenfolge in den Dateien /var/ipcop/qos/settings/layer7/rules und /var/ipcop/qos/settings/other/rules. Hier kann man dann auch bequem per copy/paste die Reihenfolge ändern – im Gegensatz zur Weboberfläche, wo man nur löschen und neu anlegen kann.

3.7. Vorsicht mit den Layer-7 Regeln

Mit den Layer-7 Regeln sollte man vorsichtig sein und lieber den ein oder anderen Test machen, denn einige Layer-7 Muster haben ein Over- oder Undermatching (es wird zu viel oder zu wenig Traffic erkannt) oder fressen mehr Performance. Eine Übersicht dazu gibts hier.

4. Beispielregeln

Ich hab hier mal meine Regeln als Beispiel, denn irgenwie kann man noch so viel faseln, nen Screenshot sagt mehr als tausend Worte. Unsere Verbindung ist eine ADSL-Leitung mit 32 festen IP-Adressen und 11000/900kbit Down-/Upstream.

Das TOS-Feld im IP-Header kann man mit dem Addon zwar ändern, man sollte aber nicht erwarten, dass das irgendwie von einem Provider ausgelesen und interpretiert wird – das würde sich dann nämlich entgegen der eingangs erwähnten Netzneutralität stellen. Außerdem würde sowas eh nur abused werden.

Zu den Regeln: Wie man sieht, hab ich mich mehr auf einer Dienst orientierten und weniger auf einer Host orientierten Priorisierung konzentriert. Das hat den Vorteil, dass es vollkommen egal ist, wieviel Rechner im LAN hängen. Die höchste Priorität haben vor allem Online-Games bekommen, die niedrigste die Filesharing-Programme. Ebenfalls sieht man gut, dass ich den Upload stark eingeschränkt habe, um eine bessere Latenz zu gewährleisten.

5.Tests

Hier kann man den eingebauten Test des Addons benutzen. Damit das ganze überhaupt Sinn macht, sollte man im Grünen Netz noch min. einen Download anschmeißen, der die Leitung auch auslastet. Das ICMP-Protokoll sollte dabei in die höchstpriorisierte Klasse und der entsprechende Download in eine niedrigere Klasse. Ich nehm dafür immer gern den FTP-Testserver von QSC.

So sieht das dann bei mir aus:

Unter „Status“ kann man überprüfen, ob die Regeln auch greifen. Hier sollte man auf die Spalten „pkts“ und „bytes“ achten. Des Weiteren hab ich noch ein sehr interessantes Script gefunden, was man auf der Konsole anschmeißen kann:

monitor_tc_top.tar.gz

in /tmp kopieren

reinwechseln:

cd /tmp

und mit

tar xfz monitor_tc_top.tar.gz

entpacken. Die Perl-Datei monitor_tc_top.pl mit einem Editor öffnen und die Werte

$arg{sleep} = "500000" ; # Refresh-Intervall
$arg{dev} = "eth2 imq0" ; # Netzwerkschnittstellen

anpassen. Am Ende kann man mit

perl /tmp/monitor_tc_top.pl

das Script starten und sieht nun das Trafficshaping zwischen den einzelnen Klassen.

So, das wars soweiten. Wenn es noch Fragen, Anregungen, gefundene Fehler gibt oder falls ich noch was wichtiges vergessen haben sollte, freue ich mich auf eure Kommentare.

Firewall IPCop 1.4.21 als QoS-System