In letzter Zeit habe ich einen Trend festgestellt. Anstatt einen Router erst dann zu ersetzen, wenn er buchstäblich nicht mehr funktioniert, musste ich schon früher handeln und neue Geräte einbauen, weil ein alter Router nicht mehr mit den steigenden Internetgeschwindigkeiten in der Gegend mithalten konnte. (Übrigens bin ich für dieses Problem sehr dankbar.) Das jüngste Beispiel: Eine ganze Reihe von Netgear ProSafe 318G-Routern hat mich zum letzten Mal im Stich gelassen, als kleine Unternehmen von herkömmlichen T1-Verbindungen mit 1,5-9 MBit/s auf 50 MBit/s über Koaxialkabel umgestiegen sind.
Ja, Koaxialkabel – nicht Glasfaser. Selbst Koax hat sich als zu viel für die alte ProSafe-Serie erwiesen. Diese Geräte konnten nicht nur nicht mithalten, sie fielen auf die Nase. Häufig fielen die alten Router bei Geschwindigkeitstests von 9mbps mit der alten Verbindung auf 3mbps oder weniger mit der 50mbps-Verbindung. Das geht natürlich nicht gut.
Heutzutage scheint die Antwort zunehmend in drahtlosen Routern zu liegen. Diese zeichnen sich in der Regel durch glitzerndes Plastik und farbenfrohe Web-Oberflächen aus, nicht aber durch technische Funktionen und Zuverlässigkeit. Was soll ein Söldner-Sysadmin tun? Im Grunde genommen kann alles, was über zwei physische Netzwerkschnittstellen verfügt, ein Router sein. Und heute gibt es jede Menge relativ schneller, preiswerter und (superwichtig!) voll funktionsfähiger generischer Boxen.
Die Zeit war also endlich gekommen. Angesichts veralteter Hardware und neuer Verbraucherangebote, die meine Anforderungen nicht erfüllten, beschloss ich, meinen eigenen Router zu bauen. Und wenn Sie sich angesichts der sich wandelnden Konnektivitätslandschaft in einer ähnlichen Lage befinden, stellt sich heraus, dass sowohl der Bau als auch der Aufbau recht schnell vonstatten gehen.
Warum es auf die harte Tour machen
Viele von Ihnen murmeln wahrscheinlich: „Klar, pfSense, sicher.“ Einige von Ihnen denken vielleicht sogar über Smoothwall oder Untangle NG nach. Ich habe mit den meisten Firewall-Distributionen herumgespielt, aber ich habe mich für eine einfachere Lösung entschieden: eine einfache CLI-Installation von Ubuntu Server und ein paar iptables-Regeln.
Zugegeben, das ist wahrscheinlich nicht für jeden Leser der praktischste Ansatz, aber für mich war es sinnvoll. Ich habe ziemlich viel Erfahrung darin, iptables und den Linux-Kernel selbst für einen hohen Durchsatz im Internet zu optimieren, und je weniger glänzende Funktionen und Grafiken und klickende Dinge zwischen mir und der Firewall-Tabelle stehen, desto weniger Fluff muss ich aus dem Weg räumen und desto weniger neue, nicht auf den Rest meiner Arbeit anwendbare Dinge muss ich lernen. Jede Regel, von der ich bereits weiß, wie ich sie in iptables erstellen kann, um den Zugriff auf meine Server zu verwalten, kann ich auch auf meine Firewall anwenden – vorausgesetzt, meine Firewall läuft unter der gleichen Distribution wie meine Server.
Außerdem arbeite ich ziemlich viel mit OpenVPN, und ich möchte in der Lage sein, sowohl die Server als auch die Clients weiterhin so einzurichten, wie ich es bereits gewohnt bin. Einige Firewall-Distributionen haben OpenVPN-Unterstützung eingebaut, andere nicht, aber selbst die mit eingebauten Funktionen neigen dazu, andere Dinge zu erwarten, als ich es tue. Auch hier gilt: Je mehr das System mir aus dem Weg geht, desto zufriedener bin ich.
Als zusätzlicher Bonus weiß ich, dass ich auf meinem neuen, vollständig mit Ubuntu ausgestatteten Router alles ganz einfach auf dem neuesten Stand halten kann. Es wird alles direkt von Canonical unterstützt, und es können (und werden) alle automatischen Updates aktiviert werden. Fügen Sie den gelegentlichen Cron-Job hinzu, um den Router neu zu starten (um neue Kernel zu erhalten), und ich bin glücklich.
Hardware, Hardware, Hardware
Wir werden in einem späteren Artikel auf die Vorgehensweise eingehen, aber heute ist es wichtig, festzustellen, warum ein DIY-Router-Build die beste Option sein könnte. Dazu muss man zunächst einmal die heutigen Rahmenbedingungen verstehen.
In der Welt der Verbraucher haben Router meist klitzekleine MIPS-CPUs unter der Haube, die nicht viel RAM haben (um es milde auszudrücken). Diese Router unterscheiden sich voneinander vor allem durch die Schnittstelle: Wie glänzend ist er? Wie viele technische Funktionen hat er? Können die Benutzer ihn leicht bedienen?
Am oberen Ende des SOHO-Marktes findet man ARM-CPUs in Smartphone-Qualität und viel mehr RAM. Diese Router – wie die Nightgear Nighthawk-Serie, auf die wir später noch eingehen werden – verfügen über mehrere Kerne, höhere Taktraten und viel mehr RAM. Sie sind auch wesentlich teurer als die billigere Konkurrenz. Ich habe einen Linksys EA2750 für $89 gekauft, aber der Netgear Nighthawk X6, den ich dazu bekommen habe, war mit $249 fast dreimal so teuer (sogar im Weihnachtsgeschäft!).
Ich wollte trotzdem einen anderen Weg gehen. In letzter Zeit sind eine Menge interessanter und recht preiswerter kleiner lüfterloser x86-64-Rechner auf dem Markt aufgetaucht. Der Trick beim Bau eines Routers ist, einen mit mehreren NICs zu finden. Auf Amazon findet man einige ziemlich sichere Angebote, aber es sind ältere Atom-basierte Prozessoren, und ich wollte einen neueren Celeron. Nach einigem Herumstöbern und Zaudern im Internet habe ich schließlich den Sprung zu Alibaba gewagt und mir einen neuen Partaker Mini PC von der Shenzhen Inctel Technology Company bestellt. Nach 240 Dollar für den Router selbst und weiteren 48 Dollar für eine 120 GB Kingston SSD von Newegg hatte ich etwa 40 Dollar mehr für das Homebrew Special ausgegeben als für den Nighthawk. Würde es sich lohnen?
Ein Herausforderer taucht auf
Bevor wir mit dem Testen beginnen, werfen wir einen kurzen Blick auf die Konkurrenz.
Dieser Nighthawk ist im Vergleich zu den anderen riesig und imposant (sogar noch größer, als das Bild ihn erscheinen lässt). Er ist sogar deutlich größer als mein Homebrew Special, der ein voll funktionsfähiger Allzweck-PC ist, den man als vollwertigen Desktop verwenden kann. Es ist, als hätte DC Comics H.R. Giger gebeten, einen drahtlosen Router für Batman zu entwerfen.
Der Homebrew Special selbst ist irgendwie bezaubernd. Er hat eine blaue und eine rote LED im Inneren des Gehäuses, und nachts strömt das Licht von beiden indirekt aus den Kühlluftöffnungen, was dem Netzwerkstapel einen festlichen Party-Look verleiht. Wenn es irgendwelche Lüfter gäbe, die ein Flackern verursachen würden, würde mich das in den Wahnsinn treiben, aber da es sich um ein gleichmäßiges, sanftes Leuchten handelt, gefällt es mir sogar.
Der Linksys und der Buffalo hingegen sehen genau so aus, wie sie sind – billige Router. Es ist jedoch erwähnenswert, dass das Styling des Linksys eine große Verbesserung gegenüber der Vergangenheit der Marke darstellt. Er sieht mehr nach etwas Professionellem und weniger nach Kinderspielzeug aus. (Aber genug vom Design – es ist an der Zeit, diese armen Router auf Herz und Nieren zu prüfen.)
Die erste offensichtliche Herausforderung ist ein einfacher Bandbreitentest. Man stellt einen Computer auf die LAN-Seite und einen Computer auf die WAN-Seite und lässt ein kleines Tool namens iperf durch die Mitte laufen. Einfach, nicht wahr?
Nun, das würde einen kurzen, langweiligen Artikel ergeben. Das Netzwerk selbst misst Gigabit, die drei Gigabit-Router messen Gigabit, und der 100-Megabit-Router misst 100 Megabit.
In Wirklichkeit ist ein so einfacher Test nicht einmal ansatzweise aussagekräftig. Der einzige Grund, ihn durchzuführen, ist vielleicht, um zu zeigen, wie sinnlos er ist. Die Routerhersteller werden sich immer mehr bewusst, dass die Leute ihre Produkte tatsächlich testen, und kein Hersteller möchte, dass sein Produkt irgendwo anders als an der Spitze der Router-Tabelle von smallnetbuilder steht. Heutzutage sind die Hersteller aktiv auf der Jagd nach Statistiken.
Das Problem ist, dass Statistiken nur Statistiken sind. Eine hohe Zahl bei einem reinen Durchsatztest zu erreichen, ist besser als nichts, aber es ist weit entfernt von der ganzen Geschichte. Ich habe diese Lektion auf die harte Tour gelernt, als ich in den frühen 2000er Jahren für einen T-1-Anbieter arbeitete. Deren extrem teure Adtran-Modems konnten die normale Internetnutzung von 50 bis 100 Personen problemlos bewältigen, aber ein einziger Benutzer, der Limewire oder einen anderen P2P-Client laufen ließ, brachte das ganze System im Handumdrehen zum Absturz. (Die Lösung damals: ein preiswerter, aber toller 150-Dollar-Netopia-Router vor das teure Adtran-Modem setzen. Problem gelöst.)
Selbst für relativ einfaches Routing – keine Deep Packet Inspection, keine Streaming-Malware-Scans oder Intrusion Detection, kein Shaping – sind die CPU und der dem Router zur Verfügung stehende Arbeitsspeicher wichtig, und zwar weit über die Fähigkeit hinaus, die Internetverbindung zu sättigen. Peer-to-Peer-Filesharing ist heutzutage so ziemlich die brutalste Aktivität in einem Netzwerk (sei es Bittorrent, eine der Gnutella- oder eDonkey-Varianten oder das Peer-to-Peer-Downloadsystem einer Spielefirma). Als das P2P-Vertriebssystem von Blizzard eingeführt wurde, hatte ich mit WoW bereits abgeschlossen, aber mein damaliger Mitbewohner noch nicht. Am Tag der Einführung des neuen Peer-to-Peer-Downloadsystems für WoW gab es keine Drosselung. Es versuchte fröhlich, Verbindungen mit buchstäblich Tausenden von Clients gleichzeitig zu finden und aufrechtzuerhalten, und mein Heimnetzwerk brach zusammen wie Gilbert Godfried, der von Terry Tate angegangen wurde. Mein Mitbewohner und ich haben uns unterhalten.
Aufgrund dieser Erfahrungen möchte ich meine Herausforderer nicht nur minimal „testen“ und dann Feierabend machen, sondern sie wirklich zum Schwitzen bringen. Um das zu erreichen, werde ich sie mit Arbeitslasten konfrontieren, die drei Problembereiche belasten: Sättigung der Netzwerkverbindung, schnelles Herstellen und Unterbrechen einzelner TCP/IP-Verbindungen und gleichzeitiges Offenhalten einer großen Anzahl einzelner TCP/IP-Verbindungen.
Ich habe ein Botnet in der Tasche, und ich bin bereit, es zu rocken
Ich habe kurz darüber nachgedacht, eine Art abscheuliches, Docker-betriebenes Monstrum mit zehntausenden von Linux-Containern mit individuellen IP-Adressen einzurichten, die alle nach Verbindungen schreien und/oder Webseiten ausliefern. Dann bin ich zur Vernunft gekommen. Für die Router macht es keinen Unterschied, ob sie Verbindungen zu Tausenden von einzelnen IP-Adressen oder nur zu Tausenden von Ports an derselben IP-Adresse aufrechterhalten. Ich habe ein wenig Zeit damit verbracht, Lee Hutchinsons Lieblings-Webserver nginx in ein lächerliches Lovecraft’sches Monster mit 10.000 Köpfen und einem Appetit auf Zerstörung zu verwandeln.
Für jeden Router habe ich ApacheBench verwendet, um das Herunterladen eines jpeg mit drei verschiedenen Dateigrößen (10K, 100K und 1M) bei vier verschiedenen Gleichzeitigkeitsstufen (10, 100, 1.000 und 10.000 gleichzeitige Clients) zu testen. Damit haben wir insgesamt 12 Tests, ohne unseren anfänglichen iperf-Test, und es lohnt sich, sie alle als eine Art Spektrum zu betrachten.
In den meisten Fällen ist die 10K-Datei die größere Herausforderung. Die geringe Dateigröße bedeutet, dass man viel mehr einzelne Dateien pro Sekunde übertragen kann, bevor die Schnittstelle gesättigt ist, was bedeutet, dass viel mehr TCP-Verbindungen aufgebaut und abgebrochen werden, was die CPU des Routers belastet. Andererseits bedeutet die 1-Meter-Datei, dass Sie auf den höheren Gleichzeitigkeitsstufen garantiert mehr Verbindungen offen halten. Es lohnt sich zu sehen, wie die Router mit dem gesamten Spektrum umgehen, denn jede Stufe bildet eine ziemlich häufige Herausforderung ab, die ein Router bewältigen muss (Herunterladen oder Versenden einer großen Anzahl von E-Mails, Handhabung von Peer-to-Peer-Filesharing oder allgemeines Web-Browsing von vielen Benutzern), wenn sie auf ein extremes Niveau gebracht wird.
Letztendlich musste ich nicht nur nginx, sondern auch den Linux-Kernel selbst optimieren, um zuverlässig die Art von Durchsatz zu liefern, die ich suchte. Die Router selbst sind „Stock“ – sogar mein Homebrew Special wurde nicht getunt – aber die Testserver, Menhir und Monolith (jeder mit AMD FX-8320 8-Core-CPU, 32GB DDR3 RAM und Ubuntu Trusty OS, das komplett auf den neuesten Stand gepatcht wurde) brauchten einige ziemlich ernsthafte Massagen, um diese Art von Last zu bewältigen.
Bei so viel Verrücktheit sollte man sich vergewissern, was die eigenen Server und das Netzwerk tatsächlich leisten können, bevor man voreilige Schlüsse über die Router zieht, die man zwischen ihnen einsetzt. Zunächst habe ich Menhir allein auf der localhost-Schnittstelle (ohne Netzwerk) getestet und dann zwischen den Servern nur über meinen Netzwerk-Switch (ein Netgear ProSafe 16-Port Gigabit, falls Sie sich das fragen).
Die localhost-Ergebnisse hätten nicht besser sein können – ein weitaus höherer Durchsatz als Gigabit bei jedem Test. Ich musste sogar die Skala der Y-Achse des Diagramms manuell begrenzen, damit man die echten Tests überhaupt sehen konnte. Der direkte Netzwerktest war nicht allzu schlecht, aber am oberen Ende stoßen wir offensichtlich an unsere Grenzen. Ich bin mir nicht sicher, ob der Switch selbst oder die Onboard-Netzwerkschnittstellen in beiden Servern das Problem sind, aber irgendetwas ist der Herausforderung nicht ganz gewachsen. Für die Arbeit ist es aber gut genug. Zeit, endlich die Router einzuschalten.
Let’s get ready to rumble!
Ich war ein wenig nervös. Ich hatte mein kleines selbstgebautes Gerät schon ziemlich ins Herz geschlossen – schließlich hatte ich es selbst gebaut. Ich wusste, dass es den älteren Buffalo, den ich aus der Schublade geholt hatte, und das Linksys, das buchstäblich das billigste Gerät mit Gigabit-Schnittstelle bei Staples war, locker übertreffen würde. Aber konnte es diesen lasergesteuerten atomaren Dampfhammer eines Nighthawk schlagen? Ich dachte es, aber ich war mir nicht sicher.
Als die Download-Tests beendet waren, gab es keine Fragen mehr über das Homebrew Special. Ja, es konnte den Nighthawk schlagen … und danach gähnend davonlaufen. Abgesehen von einem kleinen Einbruch bei 10K Dateigröße/10 gleichzeitigen Verbindungen (was die CPU mit den absolut meisten hergestellten und abgebrochenen Verbindungen herausfordert), war die Leistung fast identisch mit der direkten Netzwerkverbindung selbst.
Der Nighthawk ist übrigens wirklich ein großartiger SOHO-Router, von dem ich eine ganze Menge eingesetzt habe. Allerdings fiel er fast sofort ab. Bei 10 Megabyte-Downloads auf einmal war es ein Kopf-an-Kopf-Rennen. Bei jeder weiteren Herausforderung begann die Leistung stark abzufallen.
Der Linksys hat, keine Überraschung, überhaupt nicht gut abgeschnitten. Selbst bei einer so einfachen Aufgabe wie dem gleichzeitigen Herunterladen von 10 Dateien sank der Durchsatz auf fast die Hälfte dessen, was der naive iperf-Test zeigte. Von da an wurde es nur noch schlimmer, und er konnte mehrere Tests nicht einmal abschließen. Auf der positiven Seite zeigt der Linksys, dass Ihr Router wirklich wichtig ist.
Endlich verdient das tapfere kleine Buffalo eine Erwähnung. Obwohl es weniger gekostet hat als das Linksys, als es brandneu war (vor acht Jahren, wohlgemerkt) und fünf Jahre lang in einer Schreibtischschublade schmachtete, ist es vom sprichwörtlichen Barhocker aufgestanden und hat das Linksys in der Hälfte der Tests tatsächlich geschlagen. Und das, obwohl die Netzwerkschnittstelle des Buffalo nur für ein Zehntel der Geschwindigkeit ausgelegt war. Das nenne ich Mut. Wenn das nächste Mal jemand billige Produkte aus China anpreist, werde ich rufen: „Denkt an das Buffalo!“
Bevor wir jedoch irgendwelche Schlüsse ziehen, müssen die Upload-Geschwindigkeiten berücksichtigt werden.
Glücklicherweise hat sich an den Beziehungen zwischen den Routern hier nichts geändert. Der Homebrew sieht immer noch so aus, als ob er gar nicht da wäre, und entspricht fast vollständig einer direkten Netzwerkverbindung. Der Nighthawk dominiert den Linksys nach wie vor, und der kleine Buffalo gibt immer noch sein veraltetes Bestes. In absoluten Zahlen kann man sehen, dass sowohl der Nighthawk als auch das Linksys beim Upload etwas besser abschneiden als beim Download, aber das ist nichts, was man sich auf die Fahnen schreiben könnte. Das Fazit bleibt dasselbe: Das Homebrew Special hält mit dem Netzwerk mit (seltsamerweise sogar besser als eine Direktverbindung im 10.000 Verbindungen/10K-Datei-Test), das Nighthawk ist im Vergleich zum Linksys eindeutig seinen Preis wert, und das Linksys ist, nun ja, preiswert.
Mit diesem letzten Diagramm haben wir allerdings eine neue Reihe von Ergebnissen – die lachsfarbenen Balken, die ziemlich konstant bei etwas über 200mbps über das Diagramm hinweg liegen. Das ist das Homebrew Special, das seine Krypto-Muskeln spielen lässt. Es hat einen OpenVPN-Server laufen. Für diesen Test ist der WAN-seitige Server, Menhir, mit dem eingebauten OpenVPN-Server des Routers verbunden. Der Datenverkehr für die LAN-Seite des Homebrew Special wird über den VPN-Tunnel geleitet, so dass Menhir die LAN-IP-Adresse von Monolith (dem LAN-seitigen Server) über eine ziemlich beeindruckende 2048-Bit-SSL-basierte Verschlüsselung erreicht. Wenn man bedenkt, dass in meiner Gegend noch niemand Internetverbindungen mit mehr als 200 MBit/s anbietet, lässt das meinen inneren Krypto-Nerd vor Freude tanzen. Ich könnte buchstäblich jedes einzelne Byte meines Internet-Verkehrs verschlüsseln, in beide Richtungen, ohne Leistungseinbußen.
Ein kurzer abschließender Vorbehalt
So beeindruckend mein kleines Homebrew-Special auch ist, es gibt eine Sache, die ihm fehlt, die alle drei anderen Kandidaten anbieten: drahtlosen Zugang. Ich könnte eine drahtlose Karte in den Homebrew einbauen, damit er drahtlos funktioniert, aber im Moment habe ich das nicht vor. Ich kenne die verfügbaren PC-Wireless-Karten nur zu gut, und sie sind alle auf dem Eis nicht zu gebrauchen. Selbst billige Geräte wie Linksys oder Buffalo würden in Sachen Funkabdeckung und Reichweite eine glatte Niederlage einstecken, und der Nighthawk spielt nicht einmal in der gleichen Liga. Er ist wirklich ein lasergesteuerter atomarer Dampfhammer, wenn es um drahtlose Reichweite, Abdeckung und gleichzeitige Konnektivität geht. (Ich habe einen von ihnen, der 50+ Benutzer in einer 53.000 Quadratmeter großen Einrichtung von einer Ecke zur anderen abdeckt.)
Abgesehen davon hält Sie nichts davon ab, einen separaten WAP (Wireless Access Point) ausschließlich für Wi-Fi-Aufgaben zu verwenden. In meinem Haus sind das zwei Ubiquiti „Hockey Puck“ WAPs, einer für jede Etage des Hauses. Sie sind etwas aufwändiger zu verwalten als der Nighthawk, aber das Paar kostet nur halb so viel. Es handelt sich um Standard-Linux-Geräte, in die man sich direkt per SSH einwählen kann, und die über eine ziemlich coole kleine Web-Anwendung verwaltet werden, die man… Sie haben es erraten, direkt auf dem Homebrew Special laufen lassen kann. (Die Migration des Ubiquiti-Servers von meiner Workstation auf das Homebrew Special wird eine meiner ersten Aufgaben nach diesem Artikel sein, und ich werde ihn dann aktiv vor meinem Heimnetzwerk einsetzen.)
Im Namen der Gründlichkeit sollten wir eine gemeinsame Einschränkung beachten, etwas, das alle Consumer-Netzwerkgeräte, die ich jemals verwaltet habe, aufweisen: den Wunsch, nach fast jeder Änderung neu zu starten. Einige dieser Neustarts dauern weit über eine Minute. Ich habe nicht die geringste Ahnung, warum das so ist, aber was auch immer der Grund sein mag, das Homebrew Special ist nicht von diesem Industriestandard befallen. Man nimmt eine Änderung vor, wendet sie an und ist fertig. Und wenn Sie das Special neu starten müssen? Es ist in 12 Sekunden wieder einsatzbereit. (Ich habe die Zeit gemessen, indem ich die abgebrochenen Pings gezählt habe.)
Wenn diese Zahlen Sie also überzeugt haben und Sie Ihr eigenes Homebrew Special bauen wollen, brauchen Sie nur einen PC mit zwei physischen Netzwerkschnittstellen. Das kann ein spezieller Mini-PC sein, wie der, den ich hier verwendet habe, oder ein beliebiger alter Kasten, den Sie herumliegen haben und in den Sie zwei Netzwerkkarten stecken können. Lassen Sie sich von dem ersten Screenshot nicht einschüchtern. Es ist gar nicht so schwer, einen wirklich schnellen Router selbst zu bauen. Und wenn Sie nach einem Fahrplan verlangen, werden wir Ihnen den Weg von „hier ist ein normaler Computer“ bis „hier ist ein Router, und so konfigurieren Sie ihn“ in Kürze erläutern.
Jim Salter (@jrssnet) ist Autor, Redner, Kleinunternehmer, Söldner-Sysadmin und Vater von drei Kindern – nicht unbedingt in dieser Reihenfolge. Seine ersten Erfahrungen mit Open Source machte er 1999, als er Apache auf seinem eigenen FreeBSD 3.1-Server einsetzte, und seitdem ist er ein leidenschaftlicher Verfechter von FOSS. Er hat auch http://freebsdwiki.net und http://ubuntuwiki.net.
erstellt und pflegt sie.