© Gui Yongnian, 123RF

Redundante Internet-Uplinks sind in Rechenzentren zwar längst Standard, doch im KMU- und Heimbereich eher noch die Ausnahme. Mit Open WRT und der richtigen Hardware lassen sich aber auch Büros und Wohnungen redundant anbinden.

Ohne Internet geht heute nichts mehr – und das ist nicht mehr nur für Internetfirmen so. Denn selbst klassische Handwerksbetriebe sind oft auf digitale Dienste angewiesen: Kunden kommunizieren per E-Mail, Werkstoffe und Ersatzteile sind nur im Onlineportal des Lieferanten zu bekommen, und die Kollegen hinterlegen unterschriebene Auftragsbestätigungen gleich per Tablet im zentralen Liefersystem.

Entsprechend wichtig ist es für KMUs und durch den zunehmenden Trend zum Home-Office auch für Endanwender, einen Uplink ins Netz zu haben, der zuverlässig funktioniert. In Rechenzentren ist die redundante Anbindung über mehrere Anbieter seit Jahren fester Standard; BGP und diverse andere Protokolle kommen zum Einsatz, um die Downtime so klein wie möglich zu halten, falls mal etwas schiefgeht.

In den Büros von kleinen und mittelständischen Unternehmen und bei Endanwender sucht man redundante Internet-Uplinks dagegen vergeblich. Aus mehreren Gründen: Viele Endanwender wollen sich den Luxus mehrerer Uplinks nicht leisten – ein Argument, das bei KMUs nicht ganz so stark verfängt, weil der Ausfall des Internets hier im Zweifelsfalle zu echtem wirtschaftlichen Schaden führt.

Zudem ist es technisch gar nicht so leicht, zwei Internetverbindungen sinnvoll unter einen Hut oder eher auf einen Router zu bringen. Solche Setups sind selten und passende Geräte oft nur bedingt nützlich. Hinzu kommt noch, dass entsprechende Hardware meist recht teuer ist.

Die gute Nachricht ist: Auch mit Standardhardware und Open WRT lässt sich eine redundante Netzanbindung realisieren. Die Materialkosten sind dabei überschaubar: Oft reichen weniger als 100 Euro. Im Gegenzug erhält man in Form von Open WRT ein Router-Betriebssystem, das viele Möglichkeiten im Gepäck hat, von denen andere Router nur träumen. Dieser Artikel geht anhand eines Beispiels auf die nötigen Voraussetzungen ein und erläutert dann auf Basis von Open WRT und des Mwan3-Pakets, wie sich ein redundanter Uplink bestmöglich einsetzen lässt.

Welcher Anschluss?

Klar: Wer einen redundanten Uplink mit Open WRT nutzen will, braucht zunächst einen redundanten Uplink. Wie er den realisiert, ist dabei der Fantasie des Admin überlassen: Open WRT muss lediglich in der Lage sein, eine Internetverbindung über den jeweiligen Link herzustellen. In Frage kommen also Kabelanbindungen (bei denen üblicherweise das DHCP-Protokoll zum Einsatz kommt), DSL-Leitungen (via PPPoE) sowie LTE-Verbindungen (ebenfalls PPP).

DSL und PPPoE beherrscht Open WRT aus dem Effeff, wer LTE nutzen möchte, verwirklicht das am leichtesten per USB-Modem-Stick, den Open WRT unterstützen muss. Die meisten klassischen Geräte etwa von Huawei steuert Open WRT jedoch problemlos an.

Welche Hardware?

Mindestens so wichtig wie die Wahl des passenden Uplinks ist die Hardware, die diesen nutzt. Mit Open WRT als Router darf freilich kein anderer Router die jeweilige Leitung blockieren. Wer bereits ein DSL- oder ein Kabel-Gateway hat, schaut am besten in dessen Handbuch nach, ob das jeweilige Gerät einen Bridge-Modus unterstützt. In diesem kastriert sich der Router selbst zum simplen Modem und gibt das eingehende Netzsignal an ein anderes Gerät weiter, etwa einen Open-WRT-basierten Router.

Viele Router bieten einen solchen Modus, jedoch unterscheidet sich die Art und Weise, wie der Nutzer ihn aktiviert: Bei Kabelanbietern wie etwa Vodafone ist der Bridge-Modus per Webinterface im Kundenzentrum zu aktivieren. Bei DSL dagegen findet sich in der Konfigurationsoberfläche des Routers oft eine entsprechende Option – inklusive der Anleitung, an welchem LAN-Port danach das DSL-Signal ankommt.

Fast alle Providerrouter lassen sich per Bridge-Modus in ein dummes Modem verwandeln. Eine Ausnahme bildet AVM: Die Fritzboxen konnten bis vor einiger Zeit ebenfalls im Bridge-Modus betrieben werden, mittlerweile ist diese Option aber weggefallen. Wer eine neuere Fritzbox besitzt, dem bleibt nur der Umtausch des Geräts in ein weniger schlaues Modell.

Im Rahmen der Routerfreiheit könnten Anwender freilich auch ein eigenes Kabel- oder DSL-Modem am Anschluss betreiben. Auf der DSL-Seite ist das Vigor Draytek 100 [1] ein potenzieller Kandidat. Für Kabelanschlüsse kommt das DOCSIS-3.1-konforme Technicolor TC4400 in Frage, das in Deutschland bisher allerdings nur bei einem einzigen Anbieter zu bekommen ist [2].

Wer über mehrere funktionierende Internetanschlüsse verfügt und diese mit echten Modems oder zum Modem kastrierten Routern ausstattet, stellt sich noch die Frage nach der geeigneten Hardware für Open WRT (siehe Kasten “Hardware mit mehr Rumms”). Und die ist knifflig zu beantworten. Denn zwar läuft Open WRT auf einer Vielzahl moderner Geräte, die Qualität der Open-WRT-Implementierung unterscheidet sich jedoch stark und hängt vom Hersteller ab.

Hardware mit mehr Rumms

Der Support von Qualcomm-Hardware in Open WRT ist nicht perfekt – in der Mehrzahl der Fälle werden Anwender das zwar nicht merken, doch wer sich in einer entsprechenden Situation befindet, sollte wissen, woran es liegt und was zu tun ist.

Moderne Netzwerk-Chipsätze für LAN und WLAN kommen mit einer Vielzahl von Sonderfunktionen, die Performance-Gewinne ermöglichen. Ein Beispiel dafür ist das Offloading: Dabei übernimmt der Netzwerkchip des Geräts Aufgaben, die andernfalls der Host-CPU zur Last fielen. Und die ist gerade bei typischen Soho-Routern ohnehin nicht sonderlich groß dimensioniert. Indem der Router verschiedene Funktionen wie das Durchlaufen von Paketfiltern oder auch das Handling des Connection Trackings an den Netzwerkchip des Geräts übergibt, erhöht sich also seine Leistungsfähigkeit.

Das Problem: Selbst die eigentlich gut unterstützen Qualcomm-Treiber unterstützten längst nicht jede Offloading-Funktion. Zum Teil hat das technische und zum Teil juristische Gründe. Fakt ist jedoch, dass mit entsprechenden Geräten unter Open WRT wesentlich schlechtere Performance zu erzielen ist als mit der originalen Firmware des Geräts, die Treiber mit Support für jene Funktionen bietet.

Bei schnellen Leitungen spürbar

Besonders bemerkbar macht sich das bei schnellen Uplinks jenseits der 200-MBit-Klasse. An einem Vodafone-Anschluss mit 500 MBit pro Sekunde im Down- sowie 50 MBit pro Sekunde im Upstream war ein TP-Link AC1750 nicht annähernd in der Lage, unter Open WRT die externe Verbindung zu saturieren. Mehr als 250 MByte pro Sekunde waren nicht drin.

Snapshot-Versionen von Open WRT bieten Zugriff auf ein generisches Offloading-Feature des dort genutzten Linux-Kernels, doch selbst der blieb weit hinter den 500 MBit/s zurück und war im laufenden Betrieb zudem instabil. Die letzte stabile Open-WRT-Version kam im Test reproduzierbar auf 240 MBit/s – dann war jedoch das Ende der Fahnenstange ohne Wenn und Aber erreicht und alle vermeintlichen Tuning-Maßnahmen liefen ins Leere.

Wer Open WRT und Multi-Uplink-Konfigurationen hinter dicken Anbindungen – wie in diesem Artikel beschrieben – nutzen möchte, kann noch zum Omnia Turris [3] von der tschechischen Domain-Verwaltung NIC.CZ greifen: Das ist ein auf Open WRT basierter, von NIC.CZ selbst entwickelter Router auf Open-Source-Hardware, der die versprochenen GBit/s im Downstream problemlos erreicht. Mwan3 lässt sich auf dem Omnia Turris nutzen, allerdings ist der Open-WRT-Fork, den Omnia pflegt, prähistorisch – er basiert auf Open WRT 15.05.

Entsprechend alt ist auch Mwan3, manche Tipps und Konfigurationsdateien dieses Artikels lassen sich auf einem Omnia Turris gar nicht nutzen. Zudem schlägt das Gerät mit happigen 300 Euro zu Buche, was die Lösung zumindest im Endanwender-Bereich gleich viel weniger attraktiv wirken lässt. Im KMU-Umfeld ist die Lösung aber wohl meist vertretbar, [4] enthält eine Anleitung für multiple WANs (Abbildung 2).

Abbildung 2: Fast schon Profi-Hardware ist der Omnia Turris von NIC.CZ, der ohne Probleme einen GBit-Link saturiert.

Das hat im Hintergrund auch etwas mit den Herstellern der Chipsätze zu tun, die in Soho-Routern üblicherweise verbaut sind. Da ist auf der einen Seite Qualcomm mit seiner Atheros-Reihe, die unter Linux zu den besser unterstützten Chips zählt. Und andererseits Branchenprimus Broadcom mit seinen diversen Baureihen, deren Linux-Unterstützung qualitativ schwankt.

Die Open-WRT-Entwickler raten jedenfalls zur Qualcomm-Variante, die am Markt jedoch gar nicht so leicht zu bekommen ist. Die Geräte der üblichen Verdächtigen, also Asus, Netgear, Linksys & Co., kommen fast ausnahmslos mit Broadcom-Chips. TP-Link hingegen setzt konsequent auf Qualcomm. Ein möglicher Kandidat für die Rolle als Multi-Uplink-Router ist damit der AC1750 (der oft auch unter der Bezeichnung Archer C7 firmiert), der mit einem Straßenpreis von rund 90 Euro zu Buche schlägt (Abbildung 1).

Abbildung 1: Geräte wie der TP-Link AC1750 eignen sich im Tandem mit Open WRT gut als Home-Router für mehrere Uplinks.

Wer lieber nach anderen Geräten suchen will, muss sich übrigens nicht unbedingt nach solchen mit mehreren WAN-Ports umsehen. Denn die WAN-Ports hängen in aller Regel an denselben Switches im Gerät, an denen auch alle anderen Ports hängen. Daher ist es leicht möglich, einen der bestehenden Switch-Ports nachträglich in einen zweiten WAN-Port umzuwandeln.

Stehen für die Internetanschlüsse Modems von deren Anbietern zur Verfügung, gerät der duale Internet-Uplink damit zu einer gar nicht so teuren Angelegenheit. Ist dagegen der Kauf von Modems notwendig, sollten Anwender mit Kosten von etwa 100 Euro für ein DSL-Modem und von rund 150 Euro für ein Kabelmodem rechnen.

Setup vorbereiten

Im Folgenden geht das Beispiel von einen redundanten Internet-Uplink aus, der sich aus einer DSL-Verbindung und einer Kabelverbindung zusammensetzt. Als Gerät dient der bereits erwähnte TP-Link AC1750 (auch Archer C7), der im durchschnittlichen Elektronikmarkt oder im Onlinehandel ohne großen Aufwand zu haben ist.

Wichtig: Vom Archer C7 sind viele Revisionen im Umlauf. Open WRT unterstützt sie zwar alle, doch ist ein Open-WRT-Abbild nötig, das für die jeweilige Revision auch geeignet ist. Es lohnt sich, die zugehörige Geräte-Seite im Open-WRT-Wiki zu besuchen, um Details zum benötigten Firmware-Abbild zu erhalten.

Klar ist, dass zum Nachvollziehen dieses Artikels auf dem Router eine aktuelle Open-WRT-Version notwendig ist. Wie Open WRT auf die eigene Revision eines Archer C7 oder auf einen anderen Billig-Router kommt, hängt von der Hardware ab. Im Falle des Archer C7 ist das Gerät zunächst per RJ45-Kabel mit einem Computer oder einem bestehenden Netzwerk zu verbinden.

Der Admin muss den Computer so einrichten, dass er einen TFTP-Server betreibt, der über die IP-Adresse 192.168.0.66 erreichbar ist. Im per TFTP feilgebotenen Ordner muss sich das Factory-Abbild von Open WRT 18.06.1 für den Archer C7v4 befinden; die Datei soll den Namen »ArcherC7v4_tp_recovery.bin« tragen, weil der TFTP-Client des Rettungsmodus des Geräts nach genau dieser sucht.

Dann schaltet der Admin den AC1750 per Power-Taste aus, hält mit einem spitzen Gegenstand die Reset-Taste gedrückt, schaltet die Power-Taste wieder ein und hält die Reset-Taste für ungefähr 4 Sekunden weiter gedrückt. Die LEDs des Gerätes flackern kurz auf, dann folgt der Download des Open-WRT-Abbilds per TFTP, und schließlich steht ein Open WRT auf dem Gerät zur Verfügung. Achtung: Durch den Reset ist das Gerät auf seine Werkseinstellungen zurückgesetzt, wer vorher also eine andere IP oder spezielle Passwörter konfiguriert hatte, der muss das neu einrichten.

Immerhin: Wer sich mit dem Computer in dem Netzwerk befindet, an dem auch der Open WRT AC1750 hängt, bekommt von dessen DHCP eine IP-Adresse und kann sich dann per SSH ohne Passwort oder per Webinterface ohne Passwort einloggen. Die IP-Adresse lautet 192.168.0.1. Loggt er sich per Webinterface ein, zwingt Luci den Admin dazu, das Passwort sofort zu setzen, sodass danach auch ein SSH-Login nicht mehr möglich ist.

Konfiguration – das Übliche

Ist ein Gerät auf diese Weise mit Open WRT versorgt, steht im nächsten Schritt die Grundkonfiguration an. Ein großer Teil davon betrifft das lokale Netzwerk: Wer eine besondere DHCP-Konfiguration oder fixe, per DHCP-Clients zugewiesene IP-Adressen will, trägt diese per Luci-Webinterface unter »Network | DHCP & DNS« ein. Auch wer besondere DNS-Forward-Server benötigt, kann die entsprechenden Konfigurationsparameter per Luci setzen. Noch hat der Open-WRT-Router kein Internet – das ändert sich im nächsten Schritt.

Uplink 1

Dann geht es weiter mit der Konfiguration des ersten Uplink. Weil der den WAN-Port des Routers nutzt, ist hier noch keine Bastelei notwendig. Es empfiehlt sich, den WAN-Port mit dem stärkeren Uplink der verfügbaren Leitungen zu kombinieren. Das RJ45-Kabel steckt der Anwender im konkreten Fall also einerseits in das Kabelmodem und andererseits in den WAN-Port des AC1750. Das entspricht dem Vorschlag: Die DSL-Verbindung liefert 65 MBit/s im Downstream sowie 20 MBit/s im Upstream; die Verbindung per Koaxkabel ist mit 500/50 potenter und der Standard.

Unter Umständen ist es nötig, nach der Verbindung mit dem AC1750 das Kabelmodem neu zu starten. Per Luci loggt sich der Admin parallel dazu in Open WRT ein und konfiguriert den Anschluss »LAN« auf »DHCP«. IPv6 aktiviert Open WRT parallel dazu automatisch, wenn vom Anbieter ein wirklicher Dual-Stack anliegt und nicht nur DS-Lite.

Hat alles geklappt, hat »WAN« am Ende des Vorgangs eine IPv4- und eine IPv6-Adresse, und Open WRT auf dem AC1750 ist online. In Vorbereitung auf das Dual-WAN-Setup empfiehlt es sich, in Luci nun auf »Edit« beim WAN-Interface zu klicken und beim Feld » Router Metric« eine »10« einzufügen. Das benötigt Open WRT später zur Priorisierung der Uplinks.

Uplink 2

Etwas kniffeliger wird es beim Uplink 2. Denn für den existiert aktuell in Open WRT ja noch gar kein eigener Port. Doch keine Sorge, das Problem lässt sich schnell korrigieren. Dazu klickt der Admin in Luci auf »Network | Switch«, um sich die Konfiguration des eingebauten Switch anzeigen zu lassen.

Im Falle des AC1750 sind hier zwei VLANs konfiguriert, wobei die Ports eins bis vier im VLAN 0 sind und der Port »WAN« in VLAN 1. Per Klick auf »Add« fügt der Admin nun zunächst ein VLAN 3 hinzu. Danach stellt er sicher, dass der als »Port 3« titulierte Port nur in »VLAN 3« untagged ist; in allen anderen VLANs muss der Wert in der Tabelle hingegen auf »off« stehen. Ein Klick auf »Save & Apply« besorgt das.

Die andere Hälfte der Miete besteht darin, in Open WRT eine Schnittstelle zu definieren, die das neue VLAN nutzt. Verbindet der Admin Port 4 des Archer C7 nun mit seinem anderen Uplink – etwa einem DSL-Modem wie im Beispiel –, dann kommt zwar eine Ethernet-Verbindung zustande. Doch PPPoE fehlt noch, das sich beim Provider einloggt und so die Verbindung herstellt.

Kein Problem: Zunächst klickt der Admin auf »Network | Interfaces«. »Add New Interface« ruft den benötigten Dialog auf. Bei »Protocol of the new interface« wählt er PPPoE oder ein anderes, passendes Protokoll aus. Bei der Schnittstellen- Wahl darunter ist »eth0.3« für das eben erstellte VLAN 3 richtig. Auf diese Weise schafft der Admin eine logische Verbindung zwischen eben jenem VLAN und einer PPPoE-Verbindung auf dem Router. Als Name für die Schnittstelle ist »WAN2« gut geeignet (Abbildung 3).

Abbildung 3: Die zusätzliche WAN-Schnittstelle in Open WRT muss mit einem echten Interface (VLAN oder wie beim Omnia Turris »eth2«) verbunden werden.

Weiter geht es dann mit der Konfiguration der Schnittstellen. Dazu klickt der Admin erneut auf »Network | Interfaces« und wählt bei der Schnittstelle »WAN2« »Edit«. Im folgenden Dialog legt er danach die PPPoE-Verbindungsparameter fest. Wichtig: Wie zuvor bei »WAN« ist auch für »WAN2« eine Routing-Metrik festzulegen, im Beispiel etwa »20«.

Nach dem Speichern der Einstellungen baut Open WRT die Verbindung automatisch auf. Was nun noch fehlt, ist die automatische Umschaltung zwischen den beiden aktiven Verbindungen. Um die kümmert sich Mwan3.

Mwan3 startklar machen

Mwan3 ist eine spezielle Open-WRT-Erweiterung, die den Zugang über zwei oder mehr Internet-Uplinks dynamisch verwaltet. Per »ping« auf vom Admin festgelegte Adressen überprüft Mwan3, ob ein Link funktioniert, und schanzt ihm gegebenenfalls per NAT und dynamische IPtables-Regeln Pakete zu. Das funktioniert in Summe sehr gut, jedenfalls für IPv4. Für IPv6 ist die Sache leider anders – mehr zum Thema verrät der Kasten “Ärger mit IPv6”.

Mwan3 auf Open WRT zum Funktionieren zu bekommen, ist nicht sonderlich schwer. Die Voraussetzungen dafür sind erfüllt: Das System verfügt über zwei Uplinks, die Routing-Metriken gesetzt haben und IPv4 sowie IPv6 beherrschen. Per SSH loggt der Admin sich dann auf seinem Router ein und führt den Befehl »opkg update« aus – das aktualisiert die Open-WRT-Paketlisten. Dann folgt ein »opkg install luci-app-mwan3«, das sowohl den GUI-Teil von Mwan3 als auch die Lösung selbst als Abhängigkeit davon installiert.

Dreh- und Angelpunkt ist anschließend die Datei »/etc/config/mwan3«: In ihr sind die Konfigurationsparameter für Mwan3 definiert. Unter [5] findet sich eine funktionierende Mwan3-Konfiguration, genau passend für das Beispiel aus diesem Artikel.

Mwan3 für IPv6 sicher einrichten

Der erste Block innerhalb der Datei legt die Source-Adresse für Pakete fest, die auf dem Router selbst entstehen. Darauf folgen vier Definitionen für die im System vorhandenen Schnittstellen: zwei für IPv4 sowie zwei für IPv6. Mit Hilfe der »list track_ip«-Direktive legt der Admin fest, welche Hosts Mwan3 per »ping« malträtiert, um herauszufinden, ob sich die Leitung im Online- oder Offline-Zustand befindet. Die anderen Werte sind übliche Standardparameter und lassen sich ohne Änderung übernehmen.

Die »member«-Absätze in der Mwan3-Konfiguration weisen den NICs Metrik-Werte und Gewichte zu. Alleine sind diese Einträge jedoch nutzlos, sie bekommen erst im Kontext der folgenden Policy-Definitionen einen Sinn. Denn erst diese Policies bündeln mehrere Schnittstellen und die damit verbundenen Metriken und Gewichte zu einem Gesamtpaket.

Ganz unten folgen dann schließlich die »rule«-Absätze, die für bestimmte Traffic-Arten von bestimmten Quellen oder mit bestimmten Zielen konkrete Regeln festlegen. Die »https«-Regel im Beispiel legt fest, dass für HTTPS-Verbindungen stets dieselbe Verbindung zu nutzen ist. »sticky« bestimmt, dass Verbindungen nicht zwischen den Interfaces wechseln dürfen.

Load Balancing ist Standard

Genau das ist ab Werk nämlich der Standard-Betriebsmodus von Mwan3 in solchen Setups, in denen mehrere Netzwerkinterfaces vorhanden sind. Mit anderen Worten: Der Router betreibt Load Balancing. Wer das nicht haben möchte, ersetzt in den »rule«-Absätzen am Ende den Wert »balanced« zum Beispiel durch »WAN_WAN2«, um WAN2 nur in jenen Fällen zu verwenden, wenn das erste Interface WAN1 gerade nicht online ist (Abbildung 4).

Abbildung 4: Die »rule«-Einträge in der Mwan3-Konfiguration legen fest, wie Mwan3 Pakete routet.

Übrigens: Wenn Mwan3 erst einmal eingerichtet ist, dann lassen sich sein Status und seine Konfiguration genauso gut auch per Webinterface begutachten. Die Bearbeitung der Konfiguration per Datei und Editor auf der Kommandozeile ziehen die meisten Admins aber mit einiger Sicherheit der Klick-Variante vor (Abbildung 5).

Abbildung 5: Ist Mwan3 eingerichtet, lässt sich per Webinterface auch dessen Konfiguration untersuchen und bei Bedarf verändern.