Selbst gestrickt

Auf der Kostenseite schlagen Hardware-Router enorm zu Buche. Beispielsweise benutzt Cisco ein eigenes Betriebssystem (IOS), für das man sich jedes Feature bezahlen lässt; die zum Bereitstellen verschiedener Schnittstellen benötigten Hardwarekomponenten zieren Preisschilder, die jede PC-Rechnung in den Schatten stellen. Oft genügen die Konfigurationsmöglichkeiten der bestehenden Hardware-Router nicht den Ansprüchen versierter Administratoren.

Auch wenn nicht jeder Low-Cost-PC aus dem Supermarkt für diese Aufgabe geeignet ist, kann ein alter Pentium 100 mit einer 120-MByte-IDE-Festplatte, 128 MByte RAM und geeigneter Software viele Aufgaben in diesem Bereich genauso gut erledigen. Da liegt der Gedanke nahe, den Router durch eine PC-Lösung zu ersetzen. Deshalb wurde das Open Router Project (ORP) ins Leben gerufen, mit dem Ziel, eine einfach zu konfigurierende Linux-Lösung zu schaffen, die in den meisten Konfigurationen eine Hardwarelösung ersetzen kann. Darüber hinaus soll sie dem, der sich nicht vor dem Shell-Prompt fürchtet, die Flexibilität bieten, die man von einem Unix-System erwartet.

Hardware für einen Linux-Open-Router

Über welche Schnittstellen ein Selbstbau-Router verfügen muss, hängt natürlich von der Aufgabenstellung ab. Beispielsweise erfordert der Anschluss einer SDSL-Provider-Leitung ans Firmennetz mindestens zwei Ethernet-Ports (Netzwerkkarten). Bei der Auswahl sollte man nicht sparen, in der Praxis haben sich Markenkarten mit einem Chipsatz von Digital, Intel oder 3Com immer noch als schneller und stabiler erwiesen, als die No-Name-Produkte aus Taiwan. Ganz abzuraten ist von Netzwerkkarten, die den Benutzer über den verwendeten Chipsatz im Dunkeln lassen. Auch wenn einige dieser Produkte Linux-Treiber als externe Patches mitliefern, erweisen sich diese meistens als weniger stabil als die im offiziellen Linux-Anwenderkernel enthaltenen - abgesehen von den als experimentell markierten. Dabei sind Gigabitkarten nur bei einer Anbindung an ein bestehendes Netz sinnvoll. Die maximale theoretische Performance des PCI-Busses würde nicht ausreichen, den Datenstrom von einer Gigabitkarte zu einer anderen zu bewältigen. Dies erfordert spezielle Hardware - aber Gigabit-Internetanschlüsse sind auch dünn gesät.

Will man hingegen eine Primärmultiplex-Standleitung bedienen, braucht man Spezialhardware wie die PC300/TE von Cyclades, die intern wie eine synchrone serielle Leitung erscheint, nach außen jedoch mit der hdb3-Leitungskodierung der Deutschen Telekom klarkommt, dem typischen Übertragungsverfahren über weite Strecken in Deutschland, wenn keine Glasfaser im Spiel ist.

ISDN-Karten dagegen arbeiten mit dem AMI-Code, Support dafür soll in spätere Versionen des Open-Router-Projekts einfließen. Wer ISDN- und Ethernet-Support jetzt schon benötigt, kann die Zeit entweder mit einer großen Consumer-Distribution wie Red Hat, SuSE, Debian oder einer Diskettendistribution wie Floppy FW, Linux Router Project oder MPS (siehe Kasten ‘Quellen’) überbrücken. ATM und X.21 sind in Vorbereitung.

CPU-Leistung nicht immer ausschlaggebend

I/O-Performance - die Leistungsangabe bei Routern - genauer wie viele Daten pro Zeiteinheit von einem ‘Kabel’ zum andern durchgeleitet werden, hängt von sehr vielen Parametern ab. Im Vordergrund stehen PCI-Chipsatz, Netzwerkkarte, Speicherdurchsatz und BIOS-Einstellungen, weniger wirken sich Prozessortakt oder die Leistung der Festplatte aus.

Bei der benötigten CPU-Leistung kommt es auf den Anwendungszweck des Routers an. Muss er beispielsweise einen Tunnel verschlüsseln, also einen hohen Rechenaufwand treiben, ist natürlich eine schnelle CPU sinnvoll. Sind dagegen nur Pakete von einem Interface an das andere zu senden sowie hier und da mal ein Announcement im Netz zu machen, schafft dies auch ein antiquiertes Modell. Diese ‘Intransit Router’ müssen keine Rechenweltmeister sein, ein Pentium mit 100 MHz reicht dafür völlig aus. Für einen VPN-3DES-Router mit einer 2-MBit-Leitung sollte es dagegen schon ein PII-300 sein; bei 622-MBit-VPNs ist es klar, dass ohne intelligente Zusatzhardware kein PC in der Lage ist, diese Aufgabe zu meistern.

In der Grundkonfiguration benötigt der Open Router nur wenig Speicher, 6 MByte reichen für das System inklusive Menüsystem, Secure-Shell, Webserver und Routing-Daemons. Letztere haben zu diesem Zeitpunkt allerdings noch keine Routen gelernt oder gespeichert. Bei der Wahl des Speichermediums für den Selbstbau-Router muss man zwischen Kosten, Fehleranfälligkeit und Komfort abwägen. Im Prinzip bieten sich drei Wege an:

Eine Option kann eine SCSI- oder IDE-Platte sein. Der Standardkernel des ORP enthält Treiber für alle gängigen PCI-SCSI-Adapter sowie generische IDE-Treiber. Ein Tuning der Platten via hdparm ist Zeitverschwendung, da für den Durchsatz des Routers irrelevant. Hauptproblem dieses Ansatzes: Festplatten beinhalten bewegliche, mechanische Teile, die einen Ausfall verursachen können.

Eleganter bootet das System von einer Flashdisk. Dem Komfort eines leisen Geräts und der relativ großen Ausfallsicherheit des Dateisystems steht der hohe Preis entgegen. Der Open Router passt zurzeit in eine 16-MByte-Flashdisk, muss beim Start aber in eine RAM-Disk entpackt werden. 64 MByte RAM sind hier das Minimum, 32 MByte für das Root-Dateisystem, 8 MByte für die Programme und der Rest für Routingdaten und Puffer.

Verfügt man sowieso über einen gesicherten RAID-Server, kann man sich die hohen Kosten für eine Flashdisk sparen und das System via PXE/DHCP und TFTP starten. Der eingesetzte Bootloader Grub unterstützt das Starten sowohl von Festplatten oder Flashdisk als auch über bootfähige Netzwerkkarten mit einem PXE-BIOS. Sicherheitsfanatiker können ihren Router auch von CD-ROM starten, haben dann unter Umständen aber Schwierigkeiten beim Sichern ihrer Konfiguration.

Derzeit unterstützt das ORP nur den PCI-Bus. Spezialbusse existieren bei einem IA32-System nicht, sieht man einmal von AGP ab, ISA ist überholt. Auf die Schwierigkeiten dank fehlendem Autoconfig und PnP-BIOS kann man heute gern verzichten - vom geringeren Busdurchsatz ganz zu schweigen.

Mehrere Einsatzszenarien denkbar

Für den praktischen Einsatz der ORP-Distribution bieten sich mehrere Möglichkeiten an.

Small-Office/Home-Office-Router verbinden typischerweise kleine Rechner oder Netze mit einem großem Netz wie dem Internet oder Firmen-LAN. Aus Kostengründen benutzt man hier oft eine Wählverbindung statt einer Standleitung. Die Verbindung zur Außenwelt erfolgt mit ISDN, analogen Modems oder DSL als Leitungsprotokoll kommen PPP oder SLIP (Serial-Line-IP) infrage. Das lokale Netz hängt typischerweise via Ethernet am Router. Für eine einfache Verwaltung der Netzknoten dienen DHCP und eventuell RIP (siehe ‘Routing-Protokolle’). Will man mehr als einen Rechner über eine Provider-Verbindung mit nur einer zugewiesenen IP-Adresse mit dem Internet verbinden, ist eine Maskierung der Verbindung nötig. Die Einrichtung der NAT (Network Address Translation) erledigt man unter Linux 2.4 mit iptables. Eine Konfiguration kann via Menu/Web erfolgen.

Verbindungs-Router kommen meist in kleineren Firmen mit einer Standleitung zum Einsatz. Sie haben die Aufgabe, eine Standleitung zu bedienen und so ein ein kleines Netz permanent an das Internet/Intranet anzuschließen. Als Verbindungsmedium zur Außenwelt kommen hier oft E1 (Primärmultiplexanschluss 2 MBit/s), SDSL (bis 8 MBit/s) oder auch Funk (bis 10 MBit/s) zum Einsatz. Die Daten sind entweder in HDLC- oder PPP-Rahmen verpackt. Als Routingprotokoll benutzen sie im Firmennetz meist RIP, in manchen größeren Firmen auch OSPF (siehe ‘Routing-Protokolle’).

Border-Router kommen meist bei ISPs zum Einsatz, die über mehr als einen Uplink (Verbindung zu einem anderem ISP) verfügen. Sie müssen in der Lage sein, dem Peer (Partner-Router am anderen Leitungsende) und dem Rest des Internet mitzuteilen, welche Netze über welchen Uplink zu erreichen sind und im Falle einer Leitungsstörung den betroffenen Netzen einen alternativen Weg von und ins Internet bereitzustellen. Als Routing-Protokoll benutzen sie meist BGP (siehe ‘Routing-Protokolle’). Manchmal kommunizieren die Border-Router auch via OSPF mit dem Backbone des Providers. Auf solchen Routern kann der Einsatz von ‘Type of Service Routing’ und ‘Quality of Service’ manchmal sinnvoll sein, damit der Internetanbieter seine Kosten niedrig halten kann und seine Kunden nicht mit einem schlechten Durchsatz verärgert.

Nicht alles ist möglich

Ein derart komplexes Setup mit dem Open Router durchzuführen setzt sowohl fundierte Kenntnisse im Bereich IP-Routing voraus, als auch keine Scheu davor, selbst Shell-Skripts zu schreiben und mit Tools wie ip, tc oder iptables das benötigte Setup abzubilden. Typischerweise benötigen solche BGP-Router viel Hauptspeicher (RAM), da diese Systeme keine ‘Defaultroute’ kennen und folglich sehr viele Wege speichern müssen. 128 MByte bilden das absolute Minimum für alle BGP-Internetrouten, 192 MByte sind aber empfohlen.

Lassen sich die bisher vorgestellen Aufgaben mit mehr oder weniger Aufwand mit dem Open-Router-Projekt bewältigen, so eignet es sich für folgende Router-Typen nicht.

Access-Router ermöglichen vielen Kunden oder Mitarbeitern die Einwahl in ein Netz. Die Verwaltung der Benutzerdaten erfolgt entweder über das offene RFC-Protokoll Radius oder Ciscos hausinternes TACS+. Zur Einwahl benutzen die Geräte einen Modempool oder spezielle Hardware, die via S2M/E1-Schnittstelle an das Telekommunikationsnetz angeschlossen wird. Zwar existiert mit dem ‘Portslave Projekt’ eine Emulation für einen Portmaster II, die der Open Router nicht unterstützt und in der näheren Zukunft auch nicht unterstützen wird. Die Anbindung an das Netz erfolgt meist via (Fast-)Ethernet.

Backbone-Router sind die Hochleistungsarbeitspferde in modernen Provider-Netzen. Dank parallel angeordneter Spezialchips bedienen sie meist mehr als eine Glasfaserstandleitung mit bis zu 320 GBit/sec (mehrere STM64-Verbindungen) - Kapazitätsbereiche, die für Standard-PC-Hardware in sehr großer Ferne liegen.

Linux mit umfangreichen Bordmitteln

Betrachtet man die Frage, was der GNU/Linux-Kernel von Haus aus für die hier betrachteten Aufgaben bietet, sollte als erstes das Stichwort Multicast-Routing fallen. Dies erlaubt beispielsweise das Senden von Multimediadaten an mehrere Rechner, ohne die Daten auf dem Netz mehrfach zu emittieren. Darüber hinaus unterstützt Linux neben IPv4 auch das neue IPv6-Protokoll, das als wesentliche Neuerung die Erweiterung des Internetadressraums bietet. Weiter beherrscht es diverse Tunnelprotokolle wie IPinIP oder GRE (Generic Router Encapsulation von Cisco). Auch erlaubt es der Kernel, einem physikalischem Interface mehr als nur eine Adresse zuzuordnen. Die Fähigkeiten des Netfilter, der Traffic-Control-Mechanismen und der verschiedenen Queue-Algorithmen runden das Angebot ab.

Aber auch in der nicht-IP-Welt kann sich Linux der Protokolle wie AppleTalk, IPX, X.21, DECNET und ATM bedienen. Das Open-Router-Projekt unterstützt diese zurzeit leider noch nicht, aber die Planungen dazu laufen bereits.

Zusätzliche Werkzeuge im ORP

Neben dem im Kernel enthaltenen Programmcode kommen beim ORP Userspace-Daemons zum Einsatz. Hier seien jene aus dem GNU/Zebra-Projekt erwähnt, die die Routing-Protokolle RIP, RIPNG, OSPF und BGP sowie einige IPv6-Routing-Mechanismen bereitstellen. Für die automatische Adressvergabe dient der ISC dhcpd als DHCP-server.

Um dem fortgeschrittenen Administrator das Leben zu erleichtern, besteht das ORP aus einem kompletten POSIX-1-System sowie einem Perl 5.6.0. Das Perl-System kommt unter anderem bei der Webverwaltung zum Einsatz. Mit der Hilfe von Shell- und Perl-Skripts lässt sich die Open-Router-Distribution leicht automatisieren und erweitern.

Dagegen unterstützt eine beim Booten automatisch startende Menüstruktur unerfahrene Benutzer. Die Weboberfläche soll eine komfortable und praktische Ergänzung dazu sein. All diese Mechanismen sollen dem Benutzer helfen, den Open Router mächtig und trotzdem einfach zu konfigurieren. Für die Entwickler ist aber gerade an dieser Stelle noch viel Arbeit zu leisten.

Einsteiger müssen lediglich mit dem Standardeditor - einem vi-Clone - umgehen können, um den Paketfilter, DHCP-Server oder andere Dienste zu verwalten. Wer die Routing-Daemons spezifisch konfigurieren will, muss sich an die an Ciscos IOS angelehnte Setup-Sprache gewöhnen. Beim Einsatz von Features wie Advanced Policy Routing, Traffic Control oder TOS/IP als Routing-Key erfolgt die Parametrierung auf Shell-Ebene (bash) mit den Kommandozeilentools ip und tc.

Eine Integration von VPN-Fähigkeiten wie das IPSec-Protokoll haben die Entwickler in der mittelfristigen Planung. Diese wird voraussichtlich FreeS/WAN [1] benutzen. Die Remote-Administration kann via SSH erfolgen, der Benutzer muss aber seinen Key auf das System kopieren, beziehungsweise mit passwd ein Root-Passwort vergeben und im sshd-Setup das Login via Passwort einschalten. Aus Sicherheitsgründen ist die voreingestellte Authentifizierungsmöglichkeit nur über einen RSA-Schlüssel gegeben.

Für die Protokollierung empfiehlt es sich, einen Syslog-Server einzurichten, der alle Meldungen vom Router empfängt und speichert. Damit lässt sich auch nach einer Hackerattacke oder einem Hardwareversagen nachvollziehen, was passiert ist.

Von der Idee zur Distribution

Hinter dem Open-Router-Projekt steht die Idee, aus Standardkomponenten eine universell einsetzbare Plattform für Routing- und Netzwerkaufgaben zu entwickeln. Das System soll sich sowohl von einem weniger erfahrenen Administrator über eine Menüstruktur oder Weboberfläche als auch von einem Profi mit Perl- und Shell-Skripts administrieren lassen. Die Grafik zeigt den schematischen Aufbau.

Der Open Router soll sich sowohl beim Linux-Heimanwender als DSL-Router, als auch bei der mittleren Firma mit einer 2-MBps-Leitung oder bei einer Netzwerkparty als nützlich erweisen. Der folgende Abschnitt gibt einen Überblick über die einzelnen Bausteine des Projekts.

Eine bequeme Möglichkeit, sein Netz vor unerwünschten Besuchern, seien es Skriptkinder oder verrückt spielende Suchmaschinen, zu schützen, bietet der Paketfilter. Er bildet quasi die Grenzkontrolle zwischen Internet und Intranet. Einen wirkungsvollen Schutz oder gar eine Firewall kann der Paketfilter nicht darstellen, da er für einen geübten Hacker kein Hindernis darstellt, gegen Skriptkinder reicht seine Wirkung oft schon aus.

Derzeit funktionieren Start und Stopp des Paketfilter über die Menüs von der Konsole, die Anpassung erfolgt über eine per vim zu editierende dokumentierte Konfigurationsdatei. Darüber hinaus empfiehlt sich die Lektüre des IPTABLES-HOWTOs (siehe Kasten ‘Quellen’).

Wenn doch etwas schief gehen sollte, ist es für eine spätere Analyse wichtig festzustellen, was wann und wie passiert ist. Dafür benötigt das System die genaue Uhrzeit, was die standardmäßige Installation von NTPv4 sicherstellt. Dadurch kann der Router seine Systemzeit von einem anderem Server im Netz beziehen und sie bei Bedarf an seine Clients weitergeben. Im NTP-Server Menu kann man via ‘edit configuration’ den Default-Server ntp1.ptb.de anpassen, ‘help’ gibt eine kurze Hilfe aus. Der Aufruf von ntpq überprüft die Funktion des Server.

Sollte die Kommunikation mit anderen Rechnern im Netz nicht klappen, kann dies eventuell am aktivierten ECN (Explicit Congestion Notification) liegen, einer Methode die Kommunikation auf TCP-Basis zu optimieren. Als bekanntester Vertreter solcher Internetserver ist hier Microsofts Hotmail zu nennen. Aber auch Hardwarehersteller wie Zyxel halten sich manchmal nicht an die RFCs und bereiten hier Schwierigkeiten. ECN lässt sich einfach abschalten, indem man unter ‘net.ipv4.tcp_ecn’ den Wert von ‘1’ auf ‘0’ setzt.

cd /mnt
bzip2 -dc /tmp/orp-0.01.cpio.bz2 | cpio -ivd

Ausblick

Alle Möglichkeiten, die das System bietet, lassen sich hier natürlich nicht erschöpfend beschreiben. Allein der Kernel wäre ein Kapitel für sich. Außerdem gilt es noch viele Funktionen zu implementieren und das Benutzer-Interface so zu komplettieren, dass sich alle Standardfunktionen darüber steuern lassen.

Dabei liegen die Schwerpunkte auf IPv4 und IPv6, Support für ATM und X.21 sollen schnellstmöglich folgen. Die Weboberfläche befindet sich derzeit in einem rudimentären Zustand. So erlaubt sie zwar das Konfigurieren der Interfaces sowie das Starten und Herunterfahren der Daemons, bietet jedoch noch keinen Ersatz für die Menüstruktur und wirkt noch sehr provisorisch. Dieses soll sich aber zur Release-Version grundlegend ändern, sodass auch alle Aufgaben via Browser administrierbar sein sollten.

Beim ORP handelt es sich um ein junges Projekt. Die Entwickler wollen für den Austausch mit potenziellen Anwendern auf der Webseite des Projekts einen Feature-Request implementieren. Wie bei jeder Open-Source-Entwicklung wissen die Autoren nicht, wie weit es sich entwickelt. Für einen Patch, Fix oder Bugreport sind sie immer dankbar.

Lukas Grunwald
Alexandros Zachos
studieren Informatik an der TU Braunschweig und arbeiten als Consultants bei DN Systems, Hildesheim

Literatur

[1] Christian Zeng; Sichere Datennetze; Mithörschutz; Einrichtung der freien VPN-Lösung FreeS/WAN; iX 12/2000, S. 161 ff.