Freie Software ist beim Eigenbau von Netzwerk-Appliances sehr beliebt. Dies, da mit Hilfe einer BSD- oder Linux-Distribution und einem Second-Hand-Computer im Handumdrehen ein Access Point, eine Firewall oder ein Load Balancer aufgesetzt werden können, die nicht nur günstig, sondern auch voll konfigurierbar sind. Doch eine Geräteklasse ist bislang ein weisser Fleck auf der Eigenbau-Weste der freien Software: die Router.
Zentrale Aufgabe eines Router ist das Ermitteln von Routing-Informationen, das heisst, herauszufinden, wohin ein Paket gesendet werden muss, damit der Anwender beispielsweise die Website der InfoWeek zu sehen bekommt. Dies geschieht mit Hilfe des Border Gateway Protocol, kurz BGP (für eine Erklärung der Funktionsweise siehe Kasten «Wohin des Weges?»). Wie für andere Netzwerkdienste braucht es auch fürs BGP-Handling eine spezialisierte Software. Bislang existieren diverse Implementierungen des BGP:
• Zebra: GPL, buggy und instabil bei hoher Last.
• Quagga: Zebra-Fork, sollte die grössten Bugs von Zebra beseitigen.
• Gated: Ist als Projekt gestorben, nachdem es unfrei wurde.
• BGP in IOS: Proprietäre Implementierung von Cisco für Ciscos Router und deren Betriebssystem IOS.
• BGP in JunOS: Proprietäre Implementierung von Juniper für Juniper-Router und deren Betriebssystem JunOS.
Unzufrieden mit dieser Auswahl hat eine Gruppe von Programmierern rund um Henning Brauer und Claudio Jeker begonnen, unter der Schirmherrschaft des OpenBSD-Projekts eine eigene BGP-Implementierung zu programmieren. OpenBSD hat auch andere sehr erfolgreiche Projekte wie die OpenSSH oder den OpenNTP Daemon hervorgebracht. Höchstes Ziel von OpenBSD-Entwicklern ist es dabei, immer stabile und vor allem äusserst sichere Software zu entwickeln. Unter diesem Motto stehen auch die Prinzipien von OpenBGPD: Sicherheit durch saubere Programmierung und strikte Trennung von Ein- und Ausgangspfaden, Zuverlässigkeit, Implementierung der wichtigsten Features, ohne sich in obskuren Details zu verzetteln, einfache Administrierbarkeit und Effizienz.
Da OpenBGPD für OpenBSD entwickelt wurde und es Bestandteil davon ist, liegt es nahe, es auch als Betriebssystem für den Router zu verwenden. Es gibt aber auch Portierungen für Net- und FreeBSD. Für letzteres existiert sogar ein Package. Aber auch die Installation von Hand geht sehr einfach – das bekannte make && make install reicht bereits aus.
Die OpenBGPD-Implementierung besteht im wesentlichen aus 3 Prozessen:
•
Session Engine (SE): Die Session Engine kümmert sich um die Kommunikation mit den Nachbarn. Dies umfasst unter anderem den Austausch von Kommunikationsparametern, Routing-Informationen und Änderungen von Verbindungszuständen (Updates). Diese leitet sie dann an den RDE weiter. Umgekehrt verschickt die Session Engine selbst Updates aus der Route Decision Engine an die Nachbarn.
•
Route Decision Engine (RDE): Die Route Decision Engine verwaltet die RIB (Routing Information Base), filtert nach vorgegebenen Regeln und berechnet den besten Pfad zu einem Paket-Praefix.
•
Parent: Die SE manipuliert über den Parent Process die Routing-Tabellen des Betriebssystem-Kerns. Damit ist eine Trennung von Benutzerschicht (der Protokoll-Daemon bgpd läuft als unprivilegierter Prozess) und dem Kern selbst gegeben, womit sich Sicherheitslücken im bgpd auf diesen begrenzen lassen und nicht auf den Kern überschwappen. Am anderen Ende kommuniziert die RDE mit der SE, empfängt von ihr die Routing-Informationen der Nachbarn und sendet die eigenen Routen zur Verteilung ebenfalls an die SE.
Der Hauptprozess (Parent) bgpd wird beim Hochfahren des Systems gestartet und forkt sich dann in SE- und RDE-Tochterprozesse, welche beide als unprivilegierte Benutzer in einer Change-root-Umgebung laufen. Das bedeutet, dass diese Prozesse das Dateisystem des Betriebssystems selbst gar nicht sehen und in einer Art Gefängnisumgebung laufen. Selbst wenn es also ein Sicherheitsproblem mit den Daemons geben sollte, könnte ein Angreifer somit nicht auf das gesamte System zugreifen. Als Schnittstelle zum Konfigurieren und Administrieren wird das Tool bgpctl verwendet. Damit kann man sich unter anderem die einzelnen Routen anzeigen lassen, diese manipulieren und aktivieren oder die Konfiguration neu laden.
Eine zukünftige Erweiterung von OpenBSD als Routing-Maschine wird das noch nicht veröffentlichte OpenOSPFD sein. Claudio Jeker, ehemaliger Student an der ETH Zürich, implementiert das Rou-ting-Protokoll «Open Shortest
Path First». Das BGP erhält, wie bereits erwähnt, von anderen Routern die Routing-Tabellen
und Verfügbarkeiten der angeschlossenen Netze. OSPF fügt nun diese Tabellen zusammen und errechnet anhand dieser den jeweils kürzesten Weg zu einem Ziel. Der Vorteil ist, dass in kürzeren Zeitabständen komplette Topologien der Netze aktualisiert werden und somit unter anderem auf Ausfälle oder hohen Verkehr zwischen Netzen reagiert und diese kompensiert werden können. Der Nachteil ist, dass das OSPF-Protokoll viel CPU-Leistung und Speicher verbraucht.
OpenBGPD hat sich als stabile und zuverlässige BGP-Implementierung bewiesen, die zudem auch noch sehr einfach zu pflegen und warten ist. Oftmals ist Spezialhardware zu teuer und die Leistungsanforderungen an den Router erfordern keine speziell dafür konzipierte Lösung. In so einem Fall ist man mit einem flotten Rechner, OpenBSD und OpenBGPD bestens bedient.
Das im Internet am meisten benutzte Protokoll ist TCP/IP, welches in den 70er Jahren von der Forschungseinrichtung DARPA des amerikanischen Militärs in Auftrag gegeben wurde. Eine der Forderungen damals war es, ein Netz aufzubauen, welches den Folgen eines atomaren Angriffes standhalten sollte. Es sollte somit möglich sein, eine Netzwerkroute von Punkt A nach B variabel zu definieren. Anfangs, als es noch einen einzigen Backbone im Internet gab (das National Science Foundation Network, kurz NSFNet), waren die Routen der einzelnen Knoten statisch. Mit der wachsenden Komplexität des Internets und somit dem Wegfall des Backbone wurde es aber unmöglich, die Routen der einzelnen Knotenpunkte zu vereinen beziehungsweise zusammenzuführen. Deshalb wurde ein Protokoll entwickelt, welches die Kommunikation zwischen den Routern definiert und die Routing-Tabellen austauschen kann: BGP war geboren.
Heute lässt sich die Organisation des Internets ein wenig mit einer Landkarte vergleichen. Jedes Unternehmen und jeder Provider, der ein grösseres Netzwerk betreibt, wird dabei als eigenständiger «Staat» angesehen, der sich selber organisiert (Autonomes System, kurz AS). Die Autonomen Systeme sind, wie der Name schon sagt, unabhängig von den anderen Netzen und wissen darum auch «nichts» über sie. Möchte ein Paket nun von Netz A zu Netz B, muss der Weg von A nach B erst ermittelt werden. Dies ist die Aufgabe des Border Gateway Protocol, kurz BGP. Mit Hilfe des BGP wird durch genannte AS-Pfade die Erreichbarkeit von Netzen über Zwischenknoten mitgeteilt. Ein «BGP Speaker» teilt diese den unmittelbar verbundenen Netzen mit, respektive erstellt die Routen zwischen diesen. Anhand dieser Daten ist es den Routern möglich, eine Metrik zu erstellen und damit dann den optimalen Weg zwischen Netz A und Netz B zu ermitteln.
Wie dieser Weg aussieht, lässt sich sehr gut mit dem Werkzeug traceroute herausfinden, das den meisten BSD- und Linux-Distributionen standardmässig beiliegt. Die einzelnen Wegpunkte, die auch als «Hops « bezeichnet werden und zwischen dem Start und dem Ziel liegen, werden einer nach dem anderen mit ihrem Namen, ihrer IP-Adresse und einigen weiteren Informationen angezeigt.
Gregor Longariva (longariva@softbaer.de) ist Solaris-Administrator am Rechenzentrum der Universität Erlangen-Nürnberg und Spezialist für die Unix-Betriebssysteme Solaris, OpenBSD und Linux.
