© photocase.com

Als Kind des Internet hat Linux seit seiner frühen Jugend eine klare Affinität zum Netzwerk. Ob Linux auf Standard-PCs sich mit der spezialisierten Hardware der Netzwerkausrüster messen kann und wo das freie System seine Stärken am besten ausspielt, zeigt dieser Lagebericht.

Trends sind nicht nur in der Mode wichtig, auch die Technik folgt Modeerscheinungen und wichtigen Entwicklungen, die jenseits hohler Marketingversprechen handfeste Vorteile aufweisen. Die folgenden Seiten geben einen Überblick und zeigen, wo sich Linux derzeit positioniert. Dabei unterscheiden die Autoren augenzwinkernd die kommerzielle Closed-Source-Welt und das freie Linux-Universum – wohl wissend, dass sich beide beliebig überlappen. Tabelle 1 hilft bei den vielen Abkürzungen.

Hohe Aufmerksamkeit erlangten in den vergangenen drei Jahren WLANs, Seamless Roaming (IP-Mobilität) und VoIP (Voice over IP). Beim Load Balancing gab es im gleichen Zeitraum einen Ruck weg von der reinen Lastverteilung hin zur Applikationsoptimierung. Im LAN auf OSI-Layer 2 bis 4 geht der Trend weg von reinen Switches hin zu hoch integrierten Multipurpose-Routern, die sich durch Buzzwords wie Layer-3-Switching, Layer-4-Switching, Multilayer-Switching oder Switching-Router verkaufen. Cisco liefert nur noch wenige große Switches mit dem Switch-Betriebssystem Cat OS aus. Meist arbeiten die Geräte heute unter IOS, dem Betriebssystem für Router (Abbildung 1).

Abbildung 1: Cisco rüstet sogar die Switches der Catalyst-Express-500-Serie mit IOS aus, dem hauseigenen Router-Betriebssystem, statt wie früher mit Cat OS.

Zukunftsthemen

Für die kommenden Jahre zeichnen sich Themen ab wie IP-Mobility, IPv6 und die Rückkehr der Workinggroups in Form von Ad-hoc-Netzwerken und Zeroconf-Utilities. Interessanterweise ähneln sich IPv6 und Zeroconf [1] bei der Grundkonfiguration eines PC. Im Hardwaresektor setzen sich die vor etwa fünf Jahren begonnenen Trends fort. Auf Layer 2 und 3 geht es hin zu Wirespeed-Forwarding mit Hilfe leistungsfähiger Netzwerkprozessoren. Das so genannte Switching Silicon befindet sich dabei nahe beim Ethernet-Controller (Abbildung 2).

Abbildung 2: Spezialisierte Router-Hardware setzt die Vermittlungsintelligenz nahe an die Interfaces. Damit hält der Router schritt mit dem Netzwerk. Der zentrale Netzwerk-Prozessor pflegt die Routingtabelle.

Moderne Implementierungen von Firewallsoftware (zum Beispiel das Check-Point-Secure-XL-API) setzen oft auf den Click Modular Router [2]. Der ist das Resultat einer Doktorarbeit am MIT (Massachusetts Institute of Technology) aus dem Jahr 2001. Ihr Autor Eddie Kohler bezeichnet den Weg eines Pakets durch das System als Pfad oder Forwarding Path. Im Router transportieren Module (Elements) das Paket auf seinem Pfad, wobei jedes Element für eine bestimme Aufgabe optimiert ist.

Je nach Einsatzzweck des Endgeräts (zum Beispiel Firewall, Proxy-Server oder Router) dürfen Elemente entfallen, hinzukommen oder in anderer Anordnung arbeiten. Ein Standardrouter kommt mit 16 Elementen aus.

Click Modular Router

Der Click Modular Router läuft im Kernelspace von Linux oder anderen Unixen. Das modulare Konzept erlaubt es, bei spezialisierten Geräten (etwa Firewalls) alle zum Forwarding benötigten Features zeitsparend ohne Umwege auf dem Forwarding Path abzubilden. Das erhöht den Durchsatz eines Standard-PC (Abbildung 3) so weit, dass er mit Routern auf spezialisierter Hardware (Abbildung 2) gleichzieht.

Abbildung 3: Ein Router auf PC-Hardware muss alle Aufgaben über die CPU abwickeln. Die Netzwerkkarten kümmern sich nur um die Protokolle der Schicht 2 und informieren das Betriebssystem per Interrupt über neu eintreffende Daten.

Eine erste Implementierung dieser Technik war auf Nokias OpenBSD-basierter IP-Appliance für Check Point Firewall-1 verfügbar (unter dem Namen Flows). Später hat der Hersteller die Implementierung in Check Point Secure XL umbenannt und auf Linux und einige Jahre darauf auch für Solaris verfügbar gemacht. Leider sind den Autoren derzeit keine nicht kommerziellen Implementierungen des Click Modular Router bekannt, die Linux-basierte Router gleichermaßen beschleunigen würden.

Virtuelles Netz

Bei VPNs gab es einen interessanten Trend hin zur SSL-Technik (Secure Sockets Layer): SSL-VPNs unter Linux sind mit OpenVPN [3] oder SSL-Explorer [4] deutlich einfacher aufzusetzen als herkömmliche IPsec- oder PPTP/L2TP-VPNs. Kommerzielle Hersteller hatten zwar vor vier Jahren ebenfalls den Vorteil von SSL/TLS bei der Verschlüsselung erkannt, scheuten aber wohl den direkten Vergleich mit am Markt eingeführten IPsec-VPNs und den damit verbundenen Erwartungen der Benutzer.

Ganz im Gegensatz dazu positioniert sich OpenVPN offen als umfassende, plattformübergreifende VPN-Technik. SSL-VPNs in kommerziellen Produkten sind ausgefeilte Reverse-Proxies, auf die der User mit einem SSL-fähigen Webbrowser zugreift und über sie auch seine Applikationen fernstartet und -steuert. Diese Technik gibt es mit dem SSL-Explorer auch in einer freien Variante.

Layer 2: VLANs und Switching

Die wichtigsten Komponenten auf OSI-Schicht 2 sind Switches im Core-, Distribution- und Access-Layer von Netzwerken. Sie erfordern hochspezialisierte Hardware, die mit dem Durchsatz ihrer vielen Anschlüsse Schritt hält. Hier ist es für Linux schwer, sichtbar in Erscheinung zu treten. Linux findet sich vor allem eingebettet in den Produkten exotischer Netzwerkausrüster und in einzelnen optionalen Highend-Komponenten modularer Switches, etwa dem Cisco 6509, und in der Highend-Produktreihe der Firma Extreme Networks [5] in Form des Linux-basierten Switch-Betriebssystems Ex OS.

Nicht alle bekannten Netzwerkausrüster, die Linux oder Vx-Works als Grundlage ihrer Switches verwenden, wollen zugeben, was da im Untergrund werkelt. Viele nutzen vorgefertigte Asic-Bausteine für ihre Switches (das so genannte Switching Silicon von Broadcom, Marvell, Vitesse oder Switchcore), ergänzen noch eine Mehrzweck-CPU (Mips oder PowerPC), installieren Linux oder Vx-Works und integrieren alles mit Hilfe modularer, vorgefertigter Netzwerksoftware zu einem 24-Port-Switch.

Virtuelles LAN

Für den Endanwender sichtbarer sind Technologien im Mainstream-Kernel, die auf jeder Mehrzweck-Hardware (sprich PC) laufen, etwa VLAN-Trunking nach 802.1q (siehe VLAN-Artikel in diesem Heft). Unter Linux ist dies fast ein alter Hut, verfügbar seit Kernel 2.4.14 und voll funktionsfähig seit Version 2.4.18 gilt Bridging als voll funktionsfähig, also seit über viereinhalb Jahren.

Bereits vor sechs Jahren war es bei Check-Point-Firewalls möglich, unter Linux eine Netzwerkkarte in den Trunk-Mode zu setzen und ihr in jedem VLAN eine IP-Adresse zuzuweisen. Die VLAN-Interfaces sind dann im Check-Point-GUI verfügbar und lassen sich als separate DMZs konfigurieren. Durch die Sicherheitsbrille betrachtet handelt es sich hier um ein zusätzliches Feature, dessen Implementierung eventuell Bugs und Schwachstellen haben könnte, die einem Angreifer dienlich sind.

Die Funktionalität von 802.1q ist auch als Terminierung von Layer-2-VPNs zu sehen. Carrier setzen diese Diskriminierungen auf Layer 2 ein, um zum Beispiel Mietleitungen auf einer Infrastruktur oder einem Backbone abzubilden.

Neue Bridges für das WLAN

Bridging im Betriebssystem (statt auf einem Switch) wird bei Wireless-Netzwerken wieder interessant, nachdem es im Ethernet in den letzten sieben Jahren konstant an Bedeutung verlor. Die Bridge-Utils ([6], der »brctl«-Befehl) laufen heute auf jeder Mainstream-Distribution. Die Technik ist eine wichtige Komponente von Wireless-Netzwerken. Deren Accesspoints dienen als Bridge zwischen dem 802.11a/b/g WLAN-Link und dem Ethernet-Link.

Wer sich unter Linux einen Wireless-Accesspoint zusammenstellen will [7], der der Konkurrenz kommerzieller Wireless-Accesspoints funktional nahe kommt, braucht den Host-AP-Daemon [8], den Madwifi-Treiber [9], die bereits erwähnten Bridge-Utils und optional die Wireless-Tools [10]. Für große WLANs ist besonders das Madwifi-Projekt interessant:

• Es erlaubt virtuelle Accesspoints, bei denen ein physikalischer
  Accesspoint mehrere unabhängige SSIDs (Service Set
  Identification) erhält.
• Madwifi implementiert ein Wireless Distribution System.

Das Kürzel WDS bezeichnet bei WLAN-Netzwerken zwei grundverschiedene Technologien: die genannten Wireless Distribution Systems für Routing in Mesh-Netzwerken sowie Ciscos Wireless Domain Services.

Verrücktes Wifi

Linux-Accesspoints bestehen aus der Triade von Madwifi-Treiber, Hostapd und Bridge-Utils. Der Einsatz des Verschlüsselungsstandards 802.1x auf den Wireless-Endstationen ist unter Linux dank Open1x/Xsupplicant [11] kein Problem. Arbeitet Linux als Accesspoint, dann ist zwischen einzelnen APs, wie man sie zu Hause betreibt, und kommerziellen High-Density-Netzwerken zu unterscheiden.

Um ein WLAN für viele Anwender in großen Gebäuden zu beitreiben, begrenzt man meist die abgestrahlte Leistung mittels RF-Management (Radio Frequency, also Funk). Das verkleinert die Zelle, die ein Accesspoint versorgt, und führt zu weniger Interferenzen und höherem Durchsatz.

Telefonieren im WLAN

VoWLAN (Voice over WLAN) funktioniert zum Beispiel am besten, wenn der Accesspoint ungefähr die gleiche Leistung abstrahlt wie das 802.11-Telefon (5 bis 20 Milliwatt). Bei gutem RF-Management gelingt es, auf mittelgroßen Flächen mehrere Accesspoints zu verteilen. Es entstehen Netzwerke, die auch den Ausfall weniger Accesspoints durch automatisches RF-Management wieder wettmachen. Die Versorgung mit IP und VoWLAN bleibt sichergestellt.

Je mehr Accesspoints ein Unternehmen betreibt, desto größer ist der Bedarf, dass sich diese entweder selbst organisieren (ein Mesh-Netzwerk, Wireless Distribution Service) oder von einer zentralen aus Managementplattform administriert werden (Wireless Domain Service oder Wireless Control System, WCS).

Kluge Masche

Sehr fortgeschritten ist unter Linux die Implementierung drahtloser Mesh-Netzwerke. Bei dieser Ansammlung von Wireless-Bridges kommen die meisten Accesspoints ohne aufwändige IP-Verkabelung aus. Sie kommunizieren drahtlos miteinander und organisieren sich um einen (meist drahtgebundenen) Internetzugang herum, Internet Tap genannt. Das Mesh-Netzwerk regelt alle Teilaspekte der Kommunikation von der Link Discovery bis hin zum inhärenten Mesh-Routingprotokoll, das den Verkehr der Clients zu einem Internet Tap steuert.

Die in Deutschland entwickelte Software Meshlinux [12] verwandelt im Nu alte PC-Hardware in moderne Mesh-Router [13]. Die Aussage, dass Meshlinux für alte Hardware gedacht sei, stammt von der Homepage des Projekts und ist offenbar wörtlich zu nehmen. Die Autoren haben die Distribution im Selbstversuch nicht dazu überreden können, ihre IDE-Festplatten zu erkennen. In der Vergangenheit gab es zusätzlich noch Meshcube der deutschen Firma 4G, das heute leider vom Markt verschwunden ist. Das Produkt war vielleicht seiner Zeit zu weit voraus.

Ein wichtiger WLAN-Aspekt sind Vertraulichkeit und Authentizität der übermittelten Daten. Während Mesh-Netzwerke meist als offene Netzwerke arbeiten, wollen kommerzielle Anbieter das nahtlose Roaming von Wireless-Clients (automatischer Wechsel zwischen den Accesspoints) mit dynamisch erzeugten Verschlüsselungsschlüsseln in Rekordzeiten möglich machen. Damit wären Telefongespräche auf dem WLAN mit TKIP oder AES verschlüsselt. Die passenden Buzzwords heißen RF-Tuning, Encryption, Seamless Roaming und Voice over WLAN (VoWLAN). Auch Asset Tracking ist in diesen Produkten möglich: Der Manager weiß jederzeit, welches Gerät wo online ist.

Intelligenz im Netz

Die Hürde bei VoWLAN ist, Schlüssel nicht wie üblich zwischen Client und Accesspoint auszuhandeln, sondern mit einer zentralen Instanz. Sonst müsste beim Roaming der nächste Accesspoint die Verbindung unterbrechen, bis er neue Keys ausgehandelt hat. Als Vision soll der Klinikarzt sein mobiles Telefon zwischen GSM und WLAN wechselnd verwenden. Zu Hause ist er unter seiner GSM-Mobilnummer erreichbar. Kommt er in die Klinik, erreichen ihn die Kollegen mittels VoWLAN über seine interne Durchwahl, ohne dass er sein Telefon wechseln oder umstellen müsste.

Egal was von solchen Visionen zu halten ist: Bei Mesh-Netzwerken unter Linux fehlt es zurzeit an Dokumentation und passender RF-Planungssoftware. Vorhandene kommerzielle RF-Planer taugen für Mesh-Netzwerke nur begrenzt, da sie für herkömmliche WLANs ausgelegt sind.

Layer 3: IP-Routing

Die Tabelle 2 listet verpflichtende und optionale Funktionen eines modernen Routers. Bei kommerziellen Produkten kann es passieren, dass der Lieferumfang oder die Lizenz in der Grundausstattung nicht einmal BGP sprechen (Border Gateway Protocol); gegebenenfalls sind auch IPsec und Firewallfunktionen, die über einfache Accesslisten hinausgehen, getrennt zu lizenzieren.

Unter Linux entfällt zwar der Kostenaspekt, die Modularisierung ist aber ebenso vorhanden. Passende Software, etwa fürs IP-Routing (Quagga [14], Xorp [15], Vyatta [16] oder Bird [17]) will einzeln installiert sein. Quagga verwaltet alle gebräuchlichen Routingprotokolle zudem mit je einem eigenen Daemon, den das System gesondert startet und der auch jeweils seine eigene Konfigurationsdatei erwartet. Auf der Kommandozeile sehen sich Quagga und Cisco IOS täuschend ähnlich. Jeder Benutzer, der sich unter Quagga zurechtfindet, wird auch mit Cisco IOS zurechtkommen und umgekehrt.

Der Name Netzwerk weist schon darauf hin, dass es im Idealfall mehrere Wege von einer Quell-IP-Adresse zum Ziel gibt. Dynamische Routingprotokolle finden und beschreiben diese Pfade automatisch [18]. Statische Routen kennen dagegen nur ein Gateway und reagieren nicht von selbst auf Veränderungen in der Netzwerktopologie, verursacht zum Beispiel durch den Ausfall eines Routers.

Routingprotokolle

Routingprotokolle unterscheiden sich als IGP (Interior Gateway Protocol) und EGP (Exterior Gateway Protocol). IGPs arbeiten innerhalb eines autonomen Systems (AS), während EGPs üblicherweise die Gateways unterschiedlicher autonomer Systeme miteinander verbinden. Ein AS hat nichts mit geografischen Gegebenheiten, IP-Adressen oder Subnetzen zu tun. Am nächsten kommt ihm die Vorstellung einer Gruppe von Routern, die sich unter einer gemeinsamen Administration befinden. Das Internet ist aus diesem Betrachtungswinkel ein loser Verbund vieler autonomer Systeme, die sich mit dem De-facto-Standardprotokoll BGP organisieren.

Praxistest

Um sich einen Überblick über die Routingprogramme unter Linux zu verschaffen, haben die Autoren ein Szenario mit den wichtigsten IGP- und EGP-Protokollen getestet: OSPF (Open Shortest Path First) und BGP (siehe Abbildung 4). In einer Simulation liefen vier autonome Systeme, die je eine andere Implementierung von Routingprotokollen verwendeten: Quagga, Xorp, Vyatta und Bird sowie als Vergleich ein Cisco IOS. Auf allen vier Produkten haben sich die Routingprotokolle OSPF und BGP den Erwartungen entsprechend verhalten, es gab nur wenige Überraschungen.

Abbildung 4: Unter Laborbedingungen simulieren vier Loopback-Interfaces mehrere autonome Systeme, um die BGP-Implementierung zu testen.

Tabelle 3 vergleicht den Funktionsumfang der Linux-Routersoftware. Unabhängig von der isolierten Betrachtung der OSPF- und BGP-Implementierungen haben die Tester eine Reihe von Features sehr vermisst: NAT (Network Address Translation), GRE/IP-Tunnel (Generic Routing Encapsulation), Loopback-Interfaces und VRRP (Virtual Router Redundancy Protocol).

Ähnlich wie bei den Wireless-Accesspoints lassen sich diese unter Linux modular zum Beispiel durch IPtables und IProute2 nachinstallieren und verwalten. Dem Resultat fehlt aber die hohe Integration eines kommerziellen Routers.

OSPF

Open Shortest Path First (OSPF) ist ein Link-State-Protokoll. Das so genannte optimierte Link-State-Routingprotokoll (OLSR [19]) oder das ältere MMRP (Mobile Mesh Routing Protocol [20]) werden auch zum Organisieren von Mesh-Netzwerken diskutiert [21]. Am weitesten fortgeschritten unter den vier getesteten Routing-Daemons ist Quagga: Patches erweitern das Programm um Wireless-MANET-OSPF-Funktionen (Mobile Ad-hoc Network).

Im Test verstanden sich alle OSPF-Implementierungen problemlos, an keiner Stelle war es nötig, etwa die Default-Timer oder die MTU zu verändern. OSPF über unterschiedliche Medien (Point to Point und Point to Multipoint) funktionierten problemlos. Virtuelle Links über Transit Areas waren beim Versuchsaufbau leider nicht prüfbar.

Unangenehm viel auf, dass es mit keiner der Open-Source-Implementierungen möglich war, mehr als eine Instanz des OSPF-Prozesses zu starten. Auf einem Cisco-Router laufen theoretisch bis zu 65535 OSPF-Instanzen. Die Anzahl der OSPF-Prozesse ist in der Praxis aber von untergeordneter Bedeutung.

BGP

Die Tester stellten an BGP (Border Gateway Protocol) höhere Anforderungen als an OSPF, da BGP Internet-weit funktionieren muss und deutlich komplexer ist. Aus der Praxis kommend verlangten sie von der BGP-Implementierung zum Beispiel folgende Fähigkeiten:

• Confederations bilden (Labortest: im letzten Schritt die beiden
  autonomen Systeme 65513 und 65514 zu einer Confederation
  zusammenfassen).
• Private AS entfernen (Nummer 64512 bis 65535).
• Route-Maps und Policy Routing, um zum Beispiel einzelne Links
  zu bevorzugen (»local_preference«) oder um bestimmte
  Routing-Updates zu filtern oder zu aggregieren.

Lediglich an sehr komplexen Aufgaben scheiterten alle vier Testkandidaten. Zum Beispiel schaffte es keiner, ankommende BGP-Updates für alle Netzwerke zu unterdrücken, deren drittes Oktett eine gerade Zahl darstellt. Auf kommerziellen Routern ist das kein Problem. Auch Interface-Dampening war mit keinem der Kandidaten möglich. Die Konfiguration von Route-Dampening klappte dagegen klaglos.

Alle vier Routing-Anwendungen, ob Quagga (Listing 1), Xorp, Vyatta oder Bird, verlassen sich auf das Forwarding des Linux-Kernel. Keine arbeitet mit dem Click Modular Router zusammen oder bringt eigene Beschleuniger mit. Sie implementieren die gebräulichen Routingprotokolle (siehe Tabelle 3 für eine Gegenüberstellung) und manche sind sogar schon fit für IPv6 und OSPFv3. Quagga beherrscht kein NAT, kein Multicast-Routing (PIM-SM, PIM-DM, IGMP) und auch das Verwenden von Loopback-Interfaces ist mühsam. Ohne Hilfe von IProute2 beherrscht keine der Implementierungen GRE und IP-Tunnel.

01 hostname bgpd
02 password zebra
03 log stdout
04 !
05 router bgp 7675
06 bgp router-id 72.72.72.0
07 network 11.11.11.0/24
08 neighbor 192.168.79.22 remote-as 1000
09 neighbor 192.168.79.22 ebgp-multihop 255
10 neighbor 192.168.79.22 remove-private-AS
11 neighbor 192.168.79.22 soft-reconfiguration inbound
12 !
13 route-map MYTEST permit 10
14 line vty

Quaggas Kommandozeileninterface ist dem von Cisco IOS täuschend ähnlich, während Xorp und Vyatta mehr dem Jun OS von Juniper Networks gleichen. Der Trend bei kommerziellen Produkten geht zu höherer Integration der Komponenten. NAT und das Erzeugen beliebig vieler Loopback-Interfaces gehören heutzutage bei jedem Mehrzweckrouter bereits zum Standard.

Wer einen günstigen Router für den reinen Einsatz als OSPF- oder BGP-Speaker benötigt, findet in Quagga die beste Software. Quagga ist die älteste und beste Implementierung von BGP auf Linux. Wer den Router in seinem LAN einsetzen will, kommt meist an Features wie NAT und eventuell VLANs nicht mehr vorbei und wird an Xorp oder Vyatta mehr Freude finden.

Bird steckt noch am Anfang seiner Entwicklung – zu früh, um es für den produktiven Einsatz zu empfehlen. Zudem verwirrt die Dokumentation mit ihrem sehr akademischen Ansatz.

Ein Linux-System mutiert nicht allein durch die Installation einer Routingsoftware zum Router. Vor dem Einsatz steht eine gründliche Härtung auf dem Pflichtprogramm. Ein Nessus-Scan [22] auf einem nicht gehärteten Linux-System mit einer Quagga-Installation brachte im Test zehn offene Ports zum Vorschein, wogegen es bei der Live-CD von Vyatta nur zwei waren.

Layer 4: Lastverteilung

Lastverteilung im klassischen Sinn – also wenn ein Load Balancer ankommende Verbindungen (zum Beispiel HTTP-Requests auf Port 80) über eine virtuelle IP-Adresse auf mehrere reale Server verteilt – heißt heute bei vielen kommerziellen Herstellern Legacy Load Balancing. Die Technologie ist hinreichend bekannt und hat nur noch wenige Überraschungen auf Lager. Folglich geht die Produktentwicklung in diesem Bereich nicht mehr so hurtig vonstatten.

Application Optimizer und Application Accelerator Appliances sind die Nachfolgeprodukte der Legacy Load Balancer. Sie bestehen aus einem Mix an Technologien: Caching (Reverse-Proxy), HTTP/1.1-Komprimierung, Bandbreitenmanagement und TCP Connection Optimizing/Compression.

Nicht alles ist wirklich neu. Das HTTP/1.1-Protokoll stammt aus dem Jahr 1999, und Anno 2000 gab es mit dem Apache-Modul Mod_gzip [24] bereits die erste Kompression für Webserver unter Linux [25]. Mit ihrer Hilfe bauen sich Webseiten mit wenigen Bildern in einem HTTP-/1.1-fähigen Browser deutlich zackiger auf. Fotos und Grafiken liegen in der Regel bereits komprimiert vor.

Zusätzlich zur Komprimierung optimieren neuere Appliances die TCP-Verbindungen zwischen Client und Server (etwa per TCP- oder Connection-Splicing) und sie wagen sich an das Caching dynamisch generierter Webseiten. Letzteres geht von der Annahme aus, dass auch dynamische Inhalte reproduzierbar sind. Zum Beispiel eine E-Mail in einer Webmail-Applikation: Auch wenn sie der Browser zum zehnten Mal anfordert, bleibt sie unverändert. Wenn sich die E-Mail über Komponenten der URL eindeutig identifizieren lässt, schaffen es moderne Appliances, sie im Cache zu halten. Unter Linux erreicht die Kombination aus Squid und Memcached [26] ähnliche Ziele [27].

Linux ist in diesem Marktsegment groß als TMOS vertreten (Traffic Management Operating System) und bildet die Grundlage der F5 BIG-IP (Abbildung 5). Den freien Produkten Squid, Mod_gzip, Memcached oder Linux Virtual Server [28] fehlt vor allem eine hohe Integration, wodurch sich Aufbau und Betrieb eines freien Application Optimizers aufwändig gestaltet.

Abbildung 5: Der Hersteller F5 Networks rüstet seine Applikationsbeschleu-niger der BIG-IP-Familie mit spezialisierten Asic-Bausteinen und einem Linux-Betriebssystem aus.

Layer 4 oder 7: VPN

Ähnlich wie bei den Legacy Load Balancern gibt es auch bei den Layer-4-VPNs (sprich: IPsec) wenig Neues. Der relativ junge AES-Algorithmus ist in allen Implementierungen verfügbar und seine Akzeptanz wird die von 3DES bald überholen. Es gibt hier zahlreiche freie sowie kommerzielle Implementierungen auf Linux, bis hin zur SINA-Box der Firma Secunet [29], einem VPN-Gateway mit BSI-Zulassung bis zur Sicherheitsstufe Geheim [30].

Spannender geht es auf OSI-Layer 7 zu. Unter dem Namen SSL-VPN haben sich unter Linux und in der kommerziellen Welt zwei sehr unterschiedliche Produkte entwickelt. Kommerzielle SSL-VPN-Appliances sind entweder Webapplikationen oder Reverse-Proxies, die jeder Anwender mit einem Webbrowser über HTTPS erreichen und nutzen kann. Je nach Grad der Integration klappt dann auch gleich der Zugriff aufs Intranet, auf die Fileserver oder sogar GUI-Applikationen. Wohl um nicht mit den Erwartungen der IPsec-gewohnten Anwender konfrontiert zu werden und gar als IPsec-Konkurrenz zu gelten, vermarkten die Hersteller ihre SSL-VPN-Appliances aber nicht als Ersatz für IPsec.

Anders sieht es da beim OpenVPN-Projekt aus. Fernab von dem Druck, ein Produkt entwickeln zu müssen, das durch Alleinstellungsmerkmale in eine vorgegebene Nische passt, konnten es sich die Entwickler leisten, direkt in Konkurrenz zu IPsec-VPNs zu treten. Das Ergebnis war im Linux-Magazin schon mehrmals Thema von Artikeln und ist eine der derzeit besten VPN-Technologien. OpenVPN verwendet die Handshake-Phase von SSL/TLS, um Algorithmen und Sitzungsschlüssel auszuhandeln. Bei den kommerziellen SSL-VPNs passiert dasselbe im Webbrowser und es geht dann auch im Rahmen einer Webapplikation weiter. OpenVPN arbeitet als eigenständige Software, die IP-Subnetze über UDP oder TCP sicher tunnelt.

Den kleinen Nachteil eines zusätzlichen Overhead durch UDP oder TCP gleicht eine viel einfachere Firewall- und Router-Übertragung aus. Auch IPsec greift für NAT-Traversal auf UDP-Encapsulation zurück, meist UDP-Port 4500. Wenn einfache Accesslisten auf Routern oder simple DSL-Firewalls Probleme haben, die Hin- und Rückpakete des UDP-Protokolls zu erlauben, laufen sogar IPsec-VPNs gelegentlich über TCP-Verbindungen (meist auf Port 10000).

Derzeit bleiben zwei Hürden, die Linux in der Netzwerktechnik behindern. Zum einen ist es die Affinität des freien Betriebssystems zu unspezifischer Mehrzweckhardware, die sich perfekt für Server, Desktop und Appliances eignet, beim Gebrauch als Highspeed-Switch aber dedizierter Hardware unterliegt. Zum anderen fehlt eine vergleichbare Integration der Applikationen, wie sie in kommerziellen Routern oder Wireless-Accesspoints vorherrscht. Wer unter Linux eine ähnliche Funktionalität will, muss viele Pakete zusammenstellen, deren Dokumentationen voneinander abhängen und mit der geplanten Anwendung zum Teil wenig zu tun haben.

Manchmal der Zeit voraus

Im Detail ist Linux-Software dagegen kommerziellen Implementierungen oft um Jahre voraus. Vieles erreicht nicht die Reife für einen produktiven Betrieb oder geht unverdienterweise in der Bedeutungslosigkeit unter. Zum Beispiel nutzen leider nur kommerzielle Anwendungen den hochinteressanten Click Modular Router. Gelegentlich wandern sogar reife Implementierungen wie der »gated« in die kommerzielle Welt ab und verschwinden folglich aus Linux-Distributionen.

In vielen Fällen ist die Welt aus Linux-Sicht aber in Ordnung. Viele Techniken existieren zuerst auf Linux und entwickeln sich dort weiter. Erst recht spät erkennen kommerzielle Netzwerkausrüster den Bedarf und versuchen sich auf die Überholspur zu setzen. Bei den MANET-Erweiterungen zu OSPFv3 ist das heute abzusehen, ebenso bei IPv6. (fjl)