Hinweis: Dieses Lab für OpenWrt Policy Based Routing beschreibt eine anonymisierte Referenzarchitektur für Network Design, Troubleshooting und sichere Changes. Es enthält keine Namen realer Online-Dienste, Domains, Endpoints, Zugangsdaten oder provider-spezifischen Einstellungen. Es ist keine Anleitung zur Umgehung regionaler Verfügbarkeit, Lizenzierung, Zahlungsregeln oder Sicherheitsmechanismen von Online-Diensten.
Ein kleines Heimnetz wird überraschend schnell komplex. Lokales DNS, mehrere mögliche Egress Paths, WireGuard, Policy Routing, Monitoring und Backups reichen aus, damit aus einem „kleinen Router“ ein System wird, bei dem eine schlecht abgegrenzte Ausnahme plötzlich sehr viel mehr Traffic beeinflusst als geplant.
Die wichtigste Lektion eines solchen Labs ist deshalb nicht, Pakete irgendwie über einen anderen Weg zu schicken. Viel wichtiger ist ein Design, bei dem jede Ausnahme eng begrenzt, beobachtbar, vorhersehbar und reversibel bleibt.
Was soll das Design erreichen?
Die Grundidee ist einfach: Der überwiegende Teil des Traffics nutzt weiterhin den normalen Internet-Uplink. Nur eine klar definierte Gruppe von Verbindungen darf anhand von DNS klassifiziert und über eine separate Routing-Policy geführt werden.
Normaler Traffic
→ normaler Upstream
DNS-Query passt zu einer freigegebenen Domain-Gruppe
→ dedizierter Resolver Path
Von dieser Query zurückgegebene IP-Adresse
→ Dynamic Destination Set
→ Policy Routing
→ Primary
→ Secondary
→ normaler Upstream
Das unterscheidet sich deutlich von der einfachen Regel „dieses komplette Device über VPN routen“. Die Ausnahme gehört zur Klassifikation, nicht zum Smartphone, Fernseher oder Laptop als Ganzes.
Hardware: Für das Lab ist kein großer Server nötig
Für diese Architektur ist keine leistungsstarke x86-Plattform erforderlich. Ein kleiner Single-Board Computer reicht aus, sofern das Gerät zuverlässig unterstützt wird, genügend Arbeitsspeicher besitzt und die Netzwerkanbindung zum Design passt.
Eine sinnvolle Basis kann bestehen aus:
- einem Raspberry Pi, Orange Pi oder einem vergleichbaren SBC mit Support für das gewählte Betriebssystem;
- einem zuverlässigen Netzteil und ausreichender Kühlung;
- einer High-Endurance-microSD oder einem langlebigeren Storage-Medium, sofern die Plattform dies unterstützt;
- mindestens einem Ethernet-Interface;
- optional einem USB-Ethernet-Adapter für physisch getrennte Interfaces;
- einem bestehenden Router oder Gateway für den normalen Internetzugang;
- optional einem Managed Switch für VLANs;
- einem sicheren Off-Device-Backup-Ziel;
- optional einem Monitoring-Server.
Vor dem Kauf sollte man vor allem den aktuellen Support-Status, verfügbare System-Images, Interfaces, Storage-Zuverlässigkeit und die Qualität der Stromversorgung prüfen. Der Preis des Boards ist weniger wichtig als die Frage, ob sich das Gerät nach einem Ausfall reproduzierbar wiederherstellen lässt.
Beispielhafte Einkaufsliste für das Lab
Affiliate-Hinweis: Die folgenden Amazon-Links sind Partnerlinks. Wenn du über einen solchen Link kaufst, kann ich eine Provision erhalten, ohne dass für dich zusätzliche Kosten entstehen. Die Produkte sind Beispiele für das beschriebene Lab und nicht automatisch als von mir persönlich getestet zu verstehen. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.
- Orange Pi Zero3 1 GB — beispielhafter SBC als Edge Node;
- passives Aluminiumgehäuse für Orange Pi Zero3 — passive Kühlung und mechanischer Schutz;
- USB-C-Netzteil 5 V / 3 A (15 W) — 5 V / 3 A Stromversorgung über USB-C;
- SanDisk High Endurance microSD 64 GB — für häufige Schreibvorgänge ausgelegte Speicherkarte für einen 24/7-Edge-Node;
- TP-Link TL-SG105E — optionaler Managed Switch für ein VLAN-basiertes Lab;
- UGREEN SD-/microSD-Kartenleser — hilfreich für Installation, Imaging und Recovery der microSD-Karte.
Nicht alle Komponenten sind zwingend erforderlich. Für die einfachste Variante reichen SBC, passendes Gehäuse, korrektes Netzteil, microSD und ein bestehendes Ethernet-Netz. Switch und Kartenleser sind optionale Erweiterungen.
OpenWrt Policy Based Routing: klare Rollen im Software Stack
Eine praktische Umsetzung kann OpenWrt als Routing- und Firewall-Plattform verwenden. Entscheidend ist jedoch nicht der Produktname, sondern eine eindeutige Zuständigkeit:
- OpenWrt — Interfaces, VLANs, Routing, Firewall und Service Management;
- dnsdist — kontrollierter DNS Entry Point und Dispatcher;
- SmartDNS — Helper Resolver für ausgewählte Domain-Gruppen und Aktualisierung dynamischer Address Sets;
- mwan3 — Policy Routing und geordneter Failover;
- WireGuard — optionale Tunnels als Primary- und Secondary-Path;
- Zabbix oder ein vergleichbares System — Monitoring von Systemzustand, Services und Backup.
Seit OpenWrt 25.12 wird apk als Paketmanager verwendet; das frühere opkg wurde abgelöst. Das ist besonders für Recovery-Dokumentation und automatisierte Installationsskripte relevant.
Eine Funktion — ein Owner
Auf kleinen Routern passiert es schnell, dass mehrere Komponenten ähnliche Aufgaben übernehmen. dnsmasq, dnsdist und SmartDNS können beispielsweise alle DNS-Funktionen abdecken. Wenn zwei Prozesse gleichzeitig „der DNS-Server“ sein wollen, wird das Troubleshooting unnötig kompliziert.
Das klarere Modell lautet:
- ein Prozess besitzt den DNS-Port für die Clients;
- Helper Resolver laufen nur auf Loopback oder bewusst begrenzten Listenern;
- nur ein System besitzt die aktive Policy-Routing-Logik;
- andere Komponenten verändern dieselben Routing-Entscheidungen nicht parallel.
Diese Trennung ist oft wichtiger als die Auswahl eines bestimmten Tools. Ist der Owner einer Entscheidung klar, lässt sich ein Fehler gezielt DNS, Health Checks, Destination Set, Firewall oder Routing zuordnen.
Warum nicht ein komplettes Device routen?
Eine einfache PBR-Regel lautet oft: „Wenn die Source dieses Smartphone ist, route alles über einen anderen Path.“ Das ist bequem, vergrößert aber den Blast Radius erheblich.
Browser, OS-Updates, Messenger, Cloud Sync und völlig unabhängige Anwendungen übernehmen dann dieselben Latenzen und dasselbe Failover-Verhalten. Die Ausnahme ist nicht mehr eng begrenzt.
Ein selektiveres Design lässt normalen Traffic unverändert und nimmt nur Destinations in die Sonder-Policy auf, die aus einer kontrollierten DNS-Klassifikation stammen.
Stage 1: ein kontrollierter DNS Entry Point
Wenn DNS Teil der Klassifikation ist, müssen die Clients diesen Resolver tatsächlich verwenden. Der Edge Node sollte daher der sichtbare DNS Entry Point sein. Regeln für die ausgewählte Domain-Gruppe sollten vor allgemeineren Resolver-Regeln ausgewertet werden.
- Passt der Name zu einer kleinen, freigegebenen Suffix-Liste?
- Wenn ja, geht die Query an einen dedizierten Resolver Pool.
- Wenn nein, wird der normale Resolver oder die normale DNS-Policy verwendet.
- Die Antwort geht über denselben kontrollierten Entry Point an den Client zurück.
dnsdist eignet sich für diese Rolle, weil Queries anhand von Domain-Suffixen gematcht und bestimmten Pools zugewiesen werden können. Für die Auswahl der Backends kann ein Pool wiederum eine Policy wie firstAvailable verwenden.
Stage 2: Domains eng klassifizieren
Große Anwendungen verwenden häufig gemeinsame CDN- und Cloud-Infrastruktur. Daraus entsteht ein gefährlicher Shortcut: Wenn eine Antwort über einen großen CDN-Provider kommt, wird gleich die gesamte Infrastruktur in die Sonderregel aufgenommen.
Das sollte vermieden werden.
Dieselben Plattformen liefern möglicherweise Websites, System-Updates, Videos und völlig andere Anwendungen aus. Ein breiter Match kann daher erheblich mehr Traffic erfassen als ursprünglich geplant.
Eine gute Domain-Liste ist:
- kurz;
- durch Beobachtungen begründet;
- einer konkreten Application Family zuzuordnen;
- regelmäßig überprüft;
- frei von breiten, generischen Infrastruktur-Domains, sofern es keinen belastbaren Grund dafür gibt.
OpenWrt Policy Based Routing mit Dynamic Destination Set
Ein Router trifft seine Forwarding-Entscheidung nicht anhand eines DNS-Namens, sondern anhand der Zieladresse. Zwischen DNS-Klassifikation und Routing wird deshalb eine Brücke benötigt.
Diese Rolle kann ein dynamisches Destination Set übernehmen — beispielsweise ein ipset oder nftset, abhängig vom verwendeten Stack.
Freigegebene DNS-Antwort
→ zurückgegebene Adresse extrahieren
→ temporär in das Destination Set aufnehmen
→ Policy Routing matcht die Destination gegen dieses Set
SmartDNS unterstützt Domain Rules, deren Ergebnisse in ipset oder nftset übernommen werden können. Dadurch müssen Zieladressen nicht statisch gepflegt werden, und die Policy kann auf aktuelle DNS-Antworten reagieren.
Dieses Set ist jedoch nicht einfach nur ein Cache. Es ist aktiver Classification State. Ein unnötiger Flush entfernt die aktuelle Zuordnung zwischen den beobachteten DNS-Antworten und der Routing-Policy.
OpenWrt Policy Based Routing mit geordnetem Failover
Für Redundanz bieten sich mehrere unabhängige Paths an. Das muss aber kein Load Balancing bedeuten.
Vorhersehbarer ist:
Primary
→ Secondary
→ normaler Upstream
mwan3 unterstützt Policies mit mehreren Members. Bei unterschiedlichen Metrics hat der Member mit der niedrigeren Metric Vorrang; gleiche Metrics können zu Load Balancing führen. Unterschiedliche Metrics passen daher gut zu deterministischem Failover.
DNS sollte zum selben State Model passen. Solange Primary gesund ist, gehen die dedizierten Queries über Primary. Fällt dieser Path aus, übernimmt Secondary. Sind beide geschützten Paths down, muss bewusst festgelegt sein, ob der normale Internet-Uplink als letzter Fallback erlaubt ist oder ob ein sichtbarer Fehler gewünscht ist.
Ein versteckter Fallback, der schon im gesunden Zustand parallel öffentliche Resolver abfragt, erschwert dagegen jede Validierung.
Fehlerbilder, die erst im echten Test sichtbar werden
1. Ein Client kann die gesamte Klassifikation durch einen anderen DNS umgehen
Erhält ein Client per DHCP einen anderen Resolver, sieht der Edge Node seine DNS-Queries nicht. Die Anwendung bekommt möglicherweise eine funktionierende IP-Adresse, aber das Dynamic Destination Set wird nicht aktualisiert. Das sieht wie ein Routing-Problem aus, obwohl die Ursache in der DNS-Verteilung zum Client liegt.
2. Eine fehlende Domain sollte nicht durch einen kompletten CDN-Match „repariert“ werden
Eine breite CDN-Klassifikation kann einen einzelnen Test reparieren und gleichzeitig viel unabhängigen Traffic in die Sonder-Policy ziehen.
3. Primary/Secondary muss wirklich Active/Passive sein
Ein Backup Resolver sollte im Normalzustand nicht unbemerkt parallel arbeiten. Erst ein negativer Health Check sollte den Wechsel auslösen.
4. Zwei aktive Policy-Routing-Systeme gleichzeitig sind ein Troubleshooting-Problem
Wenn zwei unabhängige Komponenten Packets markieren und eigene Routing Tables verwalten, ist später kaum noch klar, welche Regel eine Verbindung tatsächlich beeinflusst hat.
5. Nicht nach jeder kleinen Änderung alles restarten
Eine Domain-List-Änderung sollte keinen Firewall Restart oder kompletten Reboot erzwingen. Nur der betroffene Service wird neu geladen oder neu gestartet. Dadurch bleibt die Ursache eines Fehlers nachvollziehbar.
Monitoring: State prüfen, nicht nur Logs sammeln
Lokale Logs sind hilfreich, auf kleinen Embedded-Systemen aber häufig kurzlebig. Monitoring sollte deshalb die relevanten Zustände direkt abfragen:
- Load, RAM, freier Storage und Uptime;
- Status der DNS-, Routing- und Firewall-Prozesse;
- Erreichbarkeit der vorgesehenen DNS Listener;
- Health von Primary, Secondary und Normal Uplink;
- Existenz und Entry Count des Dynamic Destination Set;
- Vorhandensein der richtigen PBR-Regel;
- Alter des neuesten lokalen Backups;
- Alter eines Markers, der nur nach erfolgreichem Off-Device Backup aktualisiert wird.
Bei Zabbix sind Active Checks für einen Edge Node ein praktisches Modell: Der Agent verbindet sich selbst zum Server oder Proxy, sodass für einfache Messwerte kein zusätzlicher passiver Listener exponiert werden muss.
Backup und Change Discipline
Backups gehören zur Architektur. Die Sicherung sollte sowohl eine partielle Wiederherstellung einzelner Komponenten als auch einen vollständigen Neuaufbau nach einem Storage-Ausfall ermöglichen.
Inspect
→ Backup mit Timestamp
→ genau eine Änderung
→ Syntax validieren
→ nur den betroffenen Service restarten
→ Ergebnis verifizieren
→ Rollback bereit halten
Mindestens eine Kopie gehört außerhalb des Edge Nodes. Enthält das Archiv VPN-Keys, SSH-Keys oder andere Secrets, darf es nur in vertrauenswürdigem, ausreichend geschütztem Storage liegen.
Wie lässt sich das Gesamtdesign verifizieren?
- Der Client verwendet tatsächlich den vorgesehenen DNS.
- Die Query ist am kontrollierten DNS Entry Point sichtbar.
- Eine passende Domain landet im richtigen Resolver Pool.
- Die Antwort aktualisiert das Dynamic Destination Set.
- Traffic zur zurückgegebenen Adresse matcht die richtige PBR-Regel.
- Im Normalzustand wird Primary verwendet.
- Nach einer kontrollierten Primary-Störung übernimmt Secondary.
- Nach Ausfall beider Paths entspricht das Verhalten dem definierten Fallback.
- Normaler, nicht klassifizierter Traffic bleibt während aller Tests auf dem normalen Uplink.
Erst dieser End-to-End-Test beweist, dass die Architektur als System funktioniert.
Weitere verwandte Labs und technische Beiträge findest du unter weitere Netzwerk-Projekte.
Fazit
Der wichtigste Teil dieses Home-Edge Labs ist weder ein bestimmter Tunnel noch ein bestimmter DNS-Resolver oder SBC. Entscheidend ist die Disziplin der Grenzen:
- normaler Traffic behält seinen normalen Path;
- Ausnahmen bleiben eng und nachvollziehbar;
- DNS und Routing repräsentieren denselben State;
- das Dynamic Destination Set wird als aktiver Systemzustand behandelt;
- Failover besitzt eine eindeutige Reihenfolge;
- jede Funktion hat einen klaren Owner;
- Monitoring prüft State statt nur Logs zu sammeln;
- Backup und Rollback gehören zum normalen Workflow.
So bleibt auch ein relativ komplexes Home Lab Monate später noch verständlich, lässt sich sicher verändern und kann genauso kontrolliert wieder entfernt werden.