Tyblog

“ Meinen idealen Router für 50 Dollar bauen “

Nachdem mein Asus N66U den Geist aufgegeben hat, habe ich ein paar Optionen in Betracht gezogen: einen anderen All-in-One-Router, ein Upgrade auf etwas wie einen EdgeRouter oder etwas Eigenes zu brauen.Als ich den Artikel von Ars Technica las, in dem die Vorzüge eines selbstgebauten Routers angepriesen wurden, war die Entscheidung gefallen: DIY ist angesagt.

Ich habe einen gewissen psychologischen Komplex, wenn es darum geht, meine eigenen übertechnisierten Lösungen zu entwickeln, aber ich habe mir einige allgemeine Ziele gesetzt: Das Endergebnis sollte billig sein, wenig Strom verbrauchen, von Linux gut unterstützt werden und erweiterbar sein.

Übrigens erfüllen ARM-Boards viele dieser Anforderungen, und einige wie der Raspberry Pi haben so viel Aktivität in der Community ausgelöst, dass es eine große Unterstützung für die ARM-Plattform gibt, auch wenn sie sich anders anfühlt als x86.

Ich habe es geschafft, ein Gerät zusammenzuschustern, das nicht nur spottbillig für das ist, was es tut, sondern auch extrem leistungsfähig ist.

Wenn Sie Interesse daran haben, Ihren eigenen Heimrouter zu bauen, zeige ich Ihnen hier, dass dies nicht nur machbar, sondern auch relativ einfach zu bewerkstelligen ist und eine riesige Menge an Nützlichkeit bietet – von Traffic Shaping über Netflow-Monitoring bis hin zu dynamischem DNS.

Ich habe es mit dem espressobin, Arch Linux Arm und Shorewall gebaut.

Das Bild zeigt das Board in einem 3d-gedruckten Gehäuse.Leider ist der espressobin nicht populär genug, um eine große Auswahl an käuflichen Gehäusen zu bieten, wie es der Raspberry Pi hat, aber es gibt einige gute Modelle für den 3d-Druck da draußen.

Als Randbemerkung: Die folgende Dokumentation ist nicht als umfassende Schritt-für-Schritt-Anleitung gedacht, um das Gleiche selbst zu tun.Obwohl ich viele der Entscheidungen abdecken möchte, die in den Aufbau eingeflossen sind, sollte die Konfiguration von etwas so Wichtigem wie einem Router/einer Firewall wirklich kein Copy/Paste-Job sein und sollte besser lose durch die Schritte hier mit einem gründlichen Verständnis des Wie und Warum angeleitet werden.

• Das Warum
• Teil Eins: Hardware
  • Was ist mit WiFi?
• Teil Zwei: Software
  • Betriebssystem
  • Firewall
• Teil Drei: Der Grundaufbau
  • OS-Installation
  • OS-Konfiguration
  • Firewall
  • DHCP
• Teil Vier: Zwischenspiel
• Teil Fünf: Upgrades
  • Netflow Monitoring
  • Traffic Shaping
• Abschluss

Das Warum

Es gibt eine Menge solider Router, die man kaufen kann, die keine ISP-Reifenfeuer sind und wahrscheinlich mehr als geeignet wären (ich schaue dich liebevoll an, EdgeRouter Lite).Es gibt hier einige legitime Vorteile:

• Es ist tatsächlich sehr erschwinglich. Mein Router hat meine Benchmarks mit Bravour bestanden und verfügt über jede Funktion, die ich von Linux übernehmen könnte (was eine lange Liste ist).
• Es ist sicher. Es kommt mir so vor, als würde jeden Monat eine neue Sicherheitslücke in irgendeinem Endkundengerät bekannt gegeben. Im Vergleich dazu weiß ich bei einer selbstverwalteten Firewall genau, welche Dienste gefährdet sind (und wenn iptables kaputt ist, hat die Welt größere Probleme). Für alle Neinsager: Der einzige Port, der auf meiner Firewall abgehört wird, ist ein zufälliger, hoch nummerierter Port für die ssh-Authentifizierung mit öffentlichem Schlüssel. Also ja, ich halte ihn für sicherer als irgendeinen Huawei-Router für Privatkunden.
• Er hat tolle Funktionen. Sicher, mein espressobin kann routen und als Firewall dienen, aber ich habe auch einige andere nützliche Funktionen eingebaut.
• Er ist leistungsfähig. In den kleinen Benchmarks, die ich durchgeführt habe, kann der espressobin den Datenverkehr wirklich pushen, ohne ins Schwitzen zu kommen.
• Es hat wirklich Spaß gemacht, ihn zu bauen. Wenn man a) einen neuen Router braucht oder b) sich mit einem ARM-Einplatinenprojekt vertraut machen will, könnte das eine gute Wahl sein.

Teil eins: Hardware

Technisch könnte man einen Router mit jedem Computer mit zwei NICs zusammenbauen, aber wir können das genauso gut mit weniger Strom, einem kleineren Formfaktor und zu einem günstigeren Preis.ARM-Boards sind die ideale Lösung: Sie sind superbillig, leistungsfähiger als man denkt und werden von vielen Varianten auf dem Markt gut unterstützt.

Der bekannteste Konkurrent ist der Raspberry Pi, aber ohne zwei NICs oder Gigabit-Netzwerke ist er keine gute Option.Außerdem muss man für Dinge wie eine GPU bezahlen, die in einem Headless Network Device nicht notwendig sind.

Die gute Nachricht ist, dass letztes Jahr der espressobin veröffentlicht wurde, und er ist sehr leistungsfähig.Es fühlt sich an, als sei es speziell für diese Art von Dingen gebaut worden: Gigabit-Netzwerk, ein eingebauter Switch und kein Schnickschnack, den man sonst für etwas allgemeineres braucht (es gibt nicht einmal einen Display-Ausgang, nur eine serielle Konsole).

Obwohl das Board noch recht jung ist, unterstützen sowohl Armbian als auch Arch Linux Arm die Hardware, und beide Projekte leisten dabei großartige Arbeit.

Wenn Sie die Welt von Linux auf ARM noch nicht erkundet haben, gibt es hier nicht viel zu befürchten.Armbian und Arch Linux Arm bieten alles, was man für aarch64 braucht, nativ in den Repos der Distributionen an, so dass es wenig gibt, was sich auf einem 64-Bit-ARM-Chip fremd anfühlt, und es lohnt sich auf jeden Fall, wenn man die Erschwinglichkeit der Hardware und den geringen Stromverbrauch berücksichtigt.

Hier sind einige der Highlights für mich:

• Das Board enthält einen eingebauten Topaz-Netzwerk-Switch. In meinen Netzwerktests ist der Datenverkehr, der nur über die LAN-Schnittstellen läuft, in Bezug auf die Geschwindigkeit nicht von dem Datenverkehr zu unterscheiden, der über einen Vanilla-Switch läuft. Wenn Sie von einem NAS streamen oder anderweitig hohe Anforderungen an die Kommunikation zwischen Geräten haben, die den Router überqueren, kann dies einen großen Unterschied machen.
• Die serielle Konsole ist ein Bürger erster Klasse. Bei meinen Raspberry Pis war ich manchmal frustriert, weil ich bei der Fehlersuche nach meinem HDMI-Display greifen musste, aber der espressobin hat einen seriellen Micro-USB-Anschluss für einfachen Konsolenzugriff.
• Der aarch64-Chip ist großartig. Er hat nicht nur alles gemeistert, was ich ihm vorgeworfen habe, sondern wussten Sie, dass er von Meltdown nicht betroffen ist? Die Cortex-A53-Chips sind nicht von dem spekulativen Ausführungsfehler betroffen, was ein zusätzlicher Bonus ist.

Wie sieht es mit WiFi aus?

Ich möchte an dieser Stelle erwähnen, dass ich versucht habe, den espressobin auch als drahtlosen Zugangspunkt zu verwenden.das Board hat einen Mini-PCIe-Steckplatz, der gut für eine drahtlose Karte geeignet ist, und obwohl es hätte funktionieren sollen, kann ich definitiv sagen, dass es keine gute Idee ist.

Ohne in peinliche Details zu gehen, gibt es eine Reihe von Problemen, die den Aufwand nicht wert sind.Ich konnte die 5Ghz-Bänder in keinem Szenario zum Laufen bringen, mein 2,4Ghz-Hostapd-Dienst reagierte alle zwölf Stunden oder so nicht mehr, und die Geschwindigkeiten waren schockierend schlecht.

Im Allgemeinen denke ich, dass dies ein Versagen der espressobin-Hardware ist: Karten, die sonst unter Linux gut unterstützt werden sollten (einige der Karten, die ich getestet habe, waren ath9k- oder ath10k-basiert), funktionieren einfach nicht mit der mPCIe-Schnittstelle des Boards.Sogar die offiziell empfohlenen Karten hatten Probleme – die RTL8191SE funktionierte nur sporadisch, und selbst die von Globalscale hergestellte Karte funktioniert nicht so, wie sie angepriesen wird.

Wenn Sie übrigens eine gut unterstützte Karte auf dem espressobin finden, antworten Sie bitte auf den entsprechenden Forumsthread, den ich zu diesem Thema gestartet habe.

Nach alledem war es von Anfang an meine Absicht, meinen AP von meinem Router zu trennen, unabhängig davon, ob ich am Ende einen espressobin verwende oder nicht.Die Trennung der Aufgaben von Firewalling/Routing und Wireless ist eine gute Lösung, und man kann sehr gute dedizierte AP-Geräte bekommen, die keine andere Funktion als das Senden eines Signals haben, um es einfach und leistungsfähig zu halten.

Ich habe schließlich ein Ubiquity UniFi-Gerät gekauft und bin sehr zufrieden damit.

Zweiter Teil: Software

Hier gibt es zwei große Auswahlmöglichkeiten: Betriebssystem und Firewall-Software.

Betriebssystem

Die erste Entscheidung, die man treffen muss, ist die, ob man dies von einer Distribution, die aarch64 unterstützt, per Hand aufspielen möchte oder eine vorgefertigte Firmware-ähnliche Lösung wie OpenWRT verwendet.Ich persönlich habe die Erfahrung gemacht, dass ich immer dann, wenn ich eine geschrumpfte Lösung wie Tomato/OpenWrt oder FreeNAS für einen Build verwende, frustriert bin, wenn ich nicht in der Lage bin, wirklich hineinzukommen und Dinge zu optimieren, also werde ich eine allgemeine Linux-Distribution für das Betriebssystem verwenden.

Wie ich bereits erwähnt habe, unterstützen Armbian und Arch Linux ARM das Board, und espressobin hat eine offizielle Dokumentation für Ubuntu (sowie Yocto, das ich bis jetzt nicht kannte).Ich werde Ihnen zwar nicht sagen, welches für Ihren Anwendungsfall am besten geeignet ist, aber hier ist der Grund, warum ich Arch Linux Arm bevorzugt habe:

• Ich bin total begeistert von Rolling-Release-Distributionen.
• Ich bin auch davon überzeugt, dass man mit topaktuellen Distros arbeiten kann. Im Falle eines Routers ist es schön, nahe am Upstream zu sein, wenn potenziell sicherheitsrelevante Updates veröffentlicht werden.
• Arch bietet uns eine saubere Basis, auf der wir aufbauen können, ohne irgendwelche fremden Dienste. Das bedeutet, dass wir mit einer minimalen Basis genau wissen können, was wir nach dem Zusammensetzen der Teile installiert, offengelegt und ausgeführt haben werden.
• Ich kenne und mag die Arch Linux ARM Leute. Hi WarheadsSE!

Firewall

Einige Namen wie PFSense kommen mir sofort in den Sinn, aber ich würde wirklich gerne etwas auf Linux laufen lassen, da ich es viel besser kenne als ein BSD (außerdem sind die besten OS-Optionen für den espressobin Linux-basiert).

Die Linux-Firewall-Landschaft ist ziemlich breit gefächert: Obwohl wir mit ziemlicher Sicherheit etwas verwenden werden, das auf iptables basiert, gibt es viele übergeordnete Dienste, die auf iptables aufsetzen (ufw, firewalld, etc.).)Während Sie Ihren eigenen einfachen iptables-Regelsatz schreiben und damit arbeiten könnten, habe ich mich dafür entschieden, einen Firewall-Dienst zu verwenden, da wir damit ein nettes Stammeswissen erwerben, das die Linux-Gemeinschaft in den vielen Jahren, in denen sie iptables-Firewalls verwaltet hat, gefördert hat.

Im Allgemeinen sollte ein guter Firewall-Daemon:

• In das Profil „gesundes OSS-Projekt“ passen. Das bedeutet, dass er aktiv gepflegt werden sollte, schon eine Weile existiert und eine gute Akzeptanz hat.
• Vermeiden Sie Komplexität. Einfache Designs sind einfacher zu debuggen, zu erweitern und zu betreiben.
• Unterstützen Sie einige „nice-to-have“-Funktionen, wie z.B. Unterstützung für Traffic Shaping und einfache Portweiterleitungskonfiguration.

Nachdem ich mich eine Weile umgesehen hatte, entschied ich mich für Shorewall.

• Der Konfigurationsfluss ist „Kompilieren – dann anwenden“. Dadurch wird sichergestellt, dass unser Regelsatz vor der Anwendung in Ordnung ist, was auch bedeutet, dass es keinen residenten Daemon gibt, der die Ressourcen des Geräts verbraucht, was auf einem kleinen Einplatinencomputer wichtig ist.
• Es kommt mit vielen netten eingebauten historischen Kenntnissen, so dass die iptables Regeln, die ausgespuckt werden, viele Randfälle behandeln, an die man normalerweise nicht denken würde.
• Ich werde später mehr davon behandeln, aber Paketmarkierung und native Unterstützung für Traffic Shaping machen klassengerechte qdiscs einfach.

Teil Drei: The Basic Build

Dieser Beitrag soll kein umfassender Leitfaden sein, aber ich wollte die groben Aufzählungspunkte aufführen, damit klar wird, wie einfach es ist, dies zusammenzustellen.

OS-Installation

Dies ist einfach – folgen Sie einfach der Arch Linux Arm espressobin Seite.Es ist besonders wichtig, die zusätzlichen Flags auf dem mkfs.ext4 Befehl und die zusätzliche U-Boot-Konfiguration zu beachten.

OS Config

In der Regel sind Arch Linux Arm-Installationen von Anfang an ziemlich gut vorbereitet.

Natürlich möchten Sie einen Nicht-Root-Benutzer für die Administration einrichten, der nicht das Standardkonto ist, also denken Sie daran, den alarm-Benutzer zu deaktivieren, alle Passwörter zu ändern und das System zu aktualisieren.

Als Randbemerkung empfehle ich dringend, das pacmatic-Paket zu installieren und es anstelle des regulären pacman zu verwenden.Es erkennt automatisch Aktualisierungen von Konfigurationsdateien und hilft dabei, sie zusammenzuführen, sowie wichtige Nachrichten über Änderungen an Paketen einzubinden.

Zusätzlich würde ich vorschlagen, etckeeper einzurichten, um Ihre Firewall-Konfiguration zu verfolgen (das Arch-Wiki hat eine gute Einführung).Ich habe meine so eingerichtet, dass sie automatisch in ein privat gehostetes Gitolite-Repositorium pusht.Um ganz ehrlich zu sein, mag ich nicht jede Konfigurationsverwaltungslösung, die es gibt, und fast alle unsere Änderungen beschränken sich auf /etc, so dass dies zumindest für mich eine gute Backup-Lösung ist.

Bitte beachten Sie, dass die Standard-Netzwerkkonfiguration für den espressobin gut für den Router-Anwendungsfall funktioniert:

• Beide LAN-Schnittstellen, lan0 und lan1, sind mit der br0-Schnittstelle verbunden. Dadurch können wir Dinge, die für das private Netzwerk bestimmt sind, wie dnsmasq auf einer einzigen virtuellen Schnittstelle zentralisieren.
• Die öffentliche Schnittstelle ist wan. Sie holt sich ihre Adresse vom Upstream-ISP über DHCP.

Die einzigen Änderungen, die notwendig sind, um br0 und wan für unseren Router einzurichten, sind zwei Ergänzungen: erstens, der LAN-Schnittstelle eine statische IP zuzuweisen, da sie der Router sein wird, und IP-Weiterleitung und IP-Masquerading in /etc/systemd/network/br0.network zu aktivieren:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

Und bestätigen Sie, dass die WAN-Schnittstelle eine Adresse vom ISP anfordert in /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Ich stelle hier UseDNS=no ein, da ich es vorziehe, OpenNIC-Server anstelle meiner Upstream-ISP’s zu verwenden – ich werde später erwähnen, wo man diese einstellt.

Firewall

Die Arch Linux ARM aarch64 Repositories haben die neuste Version von Shorewall, die ich verwendet habe Meine Konfigurationen sind nicht besonders ausgefallen, und wenn Sie ernsthaft in Erwägung ziehen, Shorewall mit einer Verbindung zum wilden Internet einzusetzen, empfehle ich Ihnen dringend, die gesamte Einführung von Shorewall in eine Firewall mit zwei Schnittstellen zu lesen.Darin werden die Grundlagen der Einrichtung mit einer schönen Zusammenfassung von Routing und Firewalling im Allgemeinen behandelt.

Grundsätzlich werden Sie die Schnittstellen br0 und wan in die richtigen Zonen setzen und alle notwendigen Regeln in /etc/shorewall/rules festlegen.Vergessen Sie nicht, den Hosts in Ihrem LAN zu erlauben, Ihren DNS-Server zu benutzen:

DNS(ACCEPT) loc $FW

Sie bestätigen, dass DHCP auf der LAN-Schnittstelle in der Datei interfaces erlaubt ist.

An dieser Stelle möchte ich anmerken, dass ich bei meiner Firewall-Einrichtung auf einen Fehler in Shorewall gestoßen bin, der buchstäblich am Vortag gepatcht wurde – und Arch Linux ARM hatte das aktualisierte Paket bereits in den Upstream-Repositories.

DHCP

dnsmasq ist die perfekte Lösung für einen Heimrouter: Es bündelt einen DNS- und DHCP-Server in einem leichtgewichtigen Daemon, der alles erledigt, was man in einem kleinen Netzwerk braucht, und es ist ausgereift genug, dass es eine Menge Dokumentation gibt, die es für genau diesen Anwendungsfall verwendet.

Hinweis: Ich habe versucht, den in systemd eingebauten DHCP-Server zu verwenden, den man mit DHCPServer= in .network-Dateien einstellen kann, da es eine leichtgewichtige Möglichkeit zu sein schien, einen DHCP-Server ohne zusätzliche Software laufen zu lassen.Ohne zu ausführlich zu sein, lohnt es sich nicht, ein wesentlicher Grund ist, dass es keine Möglichkeit gibt, aktuelle Adress-Leases zu finden.

Es gibt viele Optionen, die hier gesetzt werden sollten, aber die wichtigsten sind:

# Listen for requests on this interfaceinterface=br0# Address range to draw fromdhcp-range=192.168.1.5,192.168.1.250,255.255.255.0,24h# Default route for clients (the address we used in /etc/systemd/network/br0.network)dhcp-option=option:router,192.168.1.1# Instead of doling out DNS servers from your upstream ISP who may do dumb# things for things like unresolvable names, you can rely on other DNS servers.# These are from OpenNIC.server=192.52.166.110server=66.70.211.246server=69.195.152.204server=158.69.239.167

Wenn Sie statische Zuweisungen oder Aliase benötigen, sind diese ebenfalls leicht hinzuzufügen.

Vierter Teil: Zwischenspiel

Mit dem espressobin, der DHCP- und DNS-Anfragen auf br0 bedient, der Firewall über Shorewall und dem Routing von Paketen zwischen LAN und WAN ist er ein funktionierender Router, der nur noch den WAN-Port mit dem ISP und die beiden lan0/lan1-Ports mit Geräten oder einem anderen Switch verbinden muss.

Allerdings ist das nur ein Anfang. Wenn wir dies wirklich als Router-Ersatz betrachten wollen, gibt es einige wirklich coole Dinge, die wir tun können, um seine Fähigkeiten weiter zu verbessern, damit es sich nicht wie ein Downgrade von etwas wie meinem alten Asus N66U anfühlt.

Teil Fünf: Upgrades

Ich habe meinen vanilla espressobin-Router mit den folgenden Funktionen ausgestattet, die ich der Reihe nach erläutern werde:

• Netflow-Überwachung
• Traffic Shaping

Netflow-Überwachung

Die Sichtbarkeit des Datenverkehrs ist etwas, das ich bei meiner Asus Merlin-Firmware sehr nützlich fand, um die Nutzung zu verfolgen.Netflow ist der De-facto-Standard für solche Dinge, und unter allen verfügbaren Optionen gefällt mir ipt-netflow sehr gut, weil es ein natives Kernelmodul ist, so dass es sehr wenig Overhead gibt und sehr aktiv gepflegt wird.

Es hat sich herausgestellt, dass ich wahrscheinlich die erste Person bin, die es auf der aarch64-Architektur verwendet, weil ich etwas Hilfe bekommen habe, um es auf dem aarch64-Chipsatz zu unterstützen.

Der Projektbetreuer war (und ist) sehr entgegenkommend bei der Fehlerbehebung, so dass ich keine Probleme hatte, sicherzustellen, dass das Modul auf den neuesten Kerneln, auf denen das Arch Linux ARM-Projekt läuft, unterstützt wird.

Es zu verwenden ist eine Sache der Installation des ipt-netflow-dkms-git-Pakets aus dem AUR.Es wird für deinen Kernel gebaut, weil dkms großartig ist, und ich habe das Folgende in /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Das wird es laden, und du konfigurierst es in /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Wobei $ip dein Netflow Ziel ist.Schließlich wird der Verkehr erfasst, indem er in ein spezielles iptables-Ziel fließt, was bequem direkt von shorewall aus erfolgen kann.In /etc/shorewall/start:

run_iptables -I INPUT -j NETFLOWrun_iptables -I FORWARD -j NETFLOWrun_iptables -I OUTPUT -j NETFLOWreturn 0

Dies leitet alle Pakete auf dem Router zuerst in das NETFLOW-Ziel, das die Pakete verarbeitet und sie zurückleitet, damit sie durch die normalen Regeln fließen, die Shorewall einrichtet.

Natürlich braucht ipt-netflow einen Ort, an den Netflow-Protokolle gesendet werden, aber das ist nicht Gegenstand dieses Beitrags.In meinem Fall habe ich eine Logstash-Instanz in meinem Netzwerk mit dem Modul netflow laufen, das die Ereignisse in einem Elasticsearch-Cluster aggregiert, was mir einige praktische Dashboards und die Möglichkeit bietet, eine Vielzahl von Informationen über mein Netzwerk zu visualisieren.Es gibt einige Standard-Dashboards:

Einschließlich einiger ziemlich cooler Dashboards, wie z.B. ein Geo-IP Dashboard:

Die wichtigste Kennzahl, die mich interessiert, ist jedoch meine gesamte Bandbreitennutzung, da ich einen altmodischen ISP habe, der sich um Datenobergrenzen kümmert.Das folgende Dashboard hat zwei Visualisierungen:

• Das Messgerät vergleicht die Summe über den fraglichen Zeitraum mit der Obergrenze, die mein ISP für mich festgelegt hat, so dass ich leicht sehen kann, wo meine aktuelle Nutzung im Vergleich zur Obergrenze liegt.
• Die Zeitreihe stellt die Bandbreite in Bytes über die Zeit dar, um zu sehen, wann ich diese Bandbreite nutze.

Besonders cool an diesem Setup ist, dass ich, da wir die Netflow-Metriken in Elasticsearch und nicht in einem anderen Datenspeicher oder einer Zeitreihendatenbank speichern, die Abfragen für diese Dashboards fokussieren kann, um Dinge wie die Summe der Gesamtbytes für bestimmte CIDR-Bereiche zu erreichen, da die zugrunde liegende Speicher-Engine (Lucene) IP-Adressen nativ versteht.Die folgende Abfrage in Kibana zum Beispiel:

NOT (netflow.dst_addr:"192.168.1.0/24" AND netflow.src_addr:"192.168.1.0/24")

Filtert effektiv potenziell große Mengen an Bandbreite heraus, die zwischen den Hosts in meinem LAN anfallen, wie z. B. Streaming zwischen meinem Kodi-Host und meinem NAS-Rechner.Cool.

Traffic Shaping

Das hat sich zu einem ziemlich großen Unterfangen entwickelt, das ein faszinierendes Kaninchenloch war.Einige handelsübliche und die meisten benutzerdefinierten Router-Firmwares bieten irgendeine Form von QoS oder Traffic Shaping, also hoffte ich, dass ich dasselbe auf meinem benutzerdefinierten Router tun könnte, um einen Teil meines Datenverkehrs (wie Overwatch) vor hohen Latenzen zu schützen.

Die Welt der QoS-Technologie ist ein faszinierender Ort.Während man sich auf einfache Schemata wie einen HTB-Filter (Hierarchical Token Bucket) verlassen kann, sind die Fortschritte in der Paketfilterung erstaunlich aktiv und es gibt viele interessante Ansätze.

Was ich schließlich beschlossen habe, war ein HFSC-Filter (Hierarchical Fair-Service Curve).Ich will ehrlich sein: Die Mathematik, die dahintersteckt, ist so außerhalb meiner Liga, dass ich mehrere Zusammenfassungen lesen musste, die versuchten, sie für normale Menschen aufzuschlüsseln, und die beste Erklärung, die für mich Sinn machte, war ein ausgezeichneter Gist, über den ich vom GitHub-Benutzer eqhmcow stolperte, der die Vorteile und den Einsatz von HFSC in der Praxis erklärt.

Die Kurzfassung ist folgende: Mit einer HFSC-Verkehrskontrollklasse kann man sehr effektiv den Verkehr priorisieren und ein gutes Gleichgewicht zwischen Streams, die eine hohe Bandbreite und niedrige Latenzen benötigen, erreichen.Es ist kein Allheilmittel – man muss immer noch markieren, welche Arten von Verkehr latenzempfindlich sind – aber es hat für mich ziemlich gut funktioniert.Ohne die Regeln wird ein Steam- oder Blizzard Launcher-Download die Ping-Zeiten zerstören, während aktive HFSC-Regeln diese schweren Teile des Datenverkehrs gnädig abschneiden, um sicherzustellen, dass interaktive Streams nicht beeinträchtigt werden.

Die oben erwähnte Gist beschreibt gut, wie man seine tc-Klassen von Grund auf einrichtet.Die folgenden Konfigurationsdateien basieren auf meinen gemessenen Bandbreitengeschwindigkeiten, die etwa 230 Down- und 10 Upstream-Geschwindigkeiten betragen.

Der erste Schritt besteht darin, die relevanten tc-Klassen für jedes Gerät in der tcdevices-Datei einzustellen:

# cat /etc/shorewall/tcdevices#INTERFACE 97%_down 90%_up options(set hfsc)wan 224mbit:200kb 9mbit hfscbr0 1000mbit:200kb 1000mbit hfsc

Hier bekommt die LAN-Schnittstelle br0 ein volles Gigabit, aber die WAN-Schnittstelle wan bekommt 97 % ihrer Downstream-Geschwindigkeit und 90 % der verfügbaren Upstream-Geschwindigkeit.Die Gründe für diese Zahlen werden im Gist erläutert – wir bilden diesen Regelsatz im Wesentlichen in Shorewall-Begriffen nach.

Als nächstes definieren wir, wie die Paketmarkierungen den tc Klassen in der tcclasses Datei zugeordnet werden:

# cat /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIO OPTIONSwan:10 1 full/2:10ms:1540 full 1 tcp-ackwan:11 3 full/2:10ms:1540 full/2 2 defaultbr0:20 2 full*9/10:10ms:1540 full*9/10 1 tcp-ackbr0:21 3 115mbit:10ms:1540 224mbit 2 default

Dadurch wird wichtiger/interaktiver Verkehr in Klassen mit höherer Priorität eingeteilt.Natürlich müssen wir auch die Pakete markieren, die diese höhere Priorität bekommen sollen, was in mangle gemacht wird:

# cat /etc/shorewall/mangle# ICMP pingMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-requestMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply# sshMARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp ssh# Overwatch, Hearthstone, Diablo. 3478-3497 are very general RTP ports.MARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp,udp bnetgame,blizwow,6113MARK(1-2) 0.0.0.0/0 0.0.0.0/0 udp 3478-3497,5060,5062,6120,6250,12000-64000# Local trafficMARK(1-2) 192.168.1.0/24 192.168.1.0/24

Dies setzt die Markierungen für die hohe Priorität (1 und 2), die von unserer tc Klasse behandelt werden.Das Beispiel beinhaltet ICMP Pings, ssh, einige Blizzard Spiele und lokalen Verkehr.

Das Ergebnis sollte Massenverkehr wie Downloads oder Streams zulassen, ohne die Latenzzeiten für interaktiven Verkehr wie ssh, Ping-Zeiten im Spiel usw. zu beeinträchtigen. Meine informellen Tests haben dies bestätigt – beachten Sie, dass Sie, wenn Sie sich entscheiden, dies selbst zu überprüfen, Latenzspitzen unmittelbar nach einem anfänglichen Ausbruch von Massenverkehr beobachten können, aber HFSC greift schnell ein, um Grenzen zu erzwingen, damit die Latenzen für interaktiven Verkehr niedrig bleiben.

Ich habe eine Reihe von Benchmarks, die HFSC in Aktion zeigen, aber hier ist ein kleines Beispiel: wie sich die Ping-Latenz auswirkt, wenn iperf im Hintergrund ausgeführt wird.

Wie man sehen kann, können ohne Regeln für die Datenverkehrskontrolle große Mengen an Datenverkehr ziemlich negative Auswirkungen auf den interaktiven Datenverkehr haben, der empfindlich auf hohe Latenzen reagiert.

Fazit

Ich benutze meinen selbstgebauten Router jetzt seit einigen Monaten und er scheint gut zu funktionieren.Ich habe keine mysteriösen Verbindungsabbrüche, Geschwindigkeitsprobleme oder Hardware-Probleme während des gesamten Zeitraums des Dauerbetriebs erlebt, also würde ich den Aufbau als Erfolg betrachten.Upgrades sind auch in Ordnung; nach einem normalen sudo pacmatic -Syu und Neustart kommt das System wieder online mit allen iptables-Regeln und anderen Diensten wie erwartet, so dass es einfach ist, mit den neuesten Kerneln und anderen Paketen auf dem Laufenden zu bleiben.

Zusammenfassend:

• Für eine betrieblich versierte oder technisch interessierte Person ist ein maßgeschneiderter Router-Build sehr machbar. ARM-Einplatinencomputer machen den Einstieg billig und bequem.
• OSS-Lösungen für Firewalling, Traffic Shaping und Netzwerküberwachung sind ausgereift und einfach zu bedienen. Vor allem ältere Lösungen wie Shorewall und dnsmasq sind sehr gut dokumentiert und haben viele Jahre Arbeit in ihre Dokumentation und ihren Funktionsumfang gesteckt.
• Während Routing + DNS + DHCP ein Volltreffer sind, kann OSS WiFi der Hit oder Miss sein. Ihre Erfahrungen können variieren, aber mein espressobin ist einfach kein guter Zugangspunkt.