OpenWrt im Dauerbetrieb: Wie baue ich ein sauberes, wartbares Heim- oder KMU-Routing mit Segmentierung und Updates auf?

Architektur im OpenWrt-Alltag: Schnittstellen, Bridges, VLANs und Firewall-Zonen sauber modellieren

Ein stabiler OpenWrt-Betrieb hängt weniger von einzelnen Paketen als von einer konsistenten Modellierung der Netzwerkarchitektur ab. Zentral sind dabei drei Ebenen, die sauber zueinander passen müssen: erstens die physische und logische Anbindung über Geräte und Bridges, zweitens die IP-seitige Schnittstellenlogik (UCI-network-Interfaces) und drittens die Sicherheitsdomänen in Form von Firewall-Zonen. Sobald diese Ebenen vermischt oder „abgekürzt“ werden, entstehen typische Alltagsschäden: aus Versehen geroutete Gäste, unkontrollierte IoT-Querverbindungen oder unklare Fehlerbilder bei VLAN-Umstellungen.

Geräte vs. Interfaces: Warum die Trennung in OpenWrt zählt

OpenWrt unterscheidet konzeptionell zwischen Netzwerkgeräten (z. B. eth0, VLAN-Subinterfaces, Bridges) und IP-Interfaces (z. B. lan, wan, iot). In LuCI wirkt das oft wie ein Detail, technisch ist es jedoch die Grundlage für reproduzierbare Konfigurationen: Ein Interface beschreibt IP-Adressierung, DHCP-Client/Server, DNS-Optionen und Routen, während ein Gerät beschreibt, wie Frames auf Layer 2 fließen.

In modernen OpenWrt-Versionen (DSA auf vielen Targets) wird die Switch-Konfiguration nicht mehr über klassische swconfig-Ports, sondern über Linux-Bridge und VLAN-Filtering abgebildet. Das ändert die Oberfläche, nicht aber das Ziel: VLANs gehören an die Bridge, IP-Interfaces hängen an VLAN-Subinterfaces der Bridge (z. B. br-lan.10) oder an dedizierte Geräte. Diese Trennung verhindert, dass IP-Settings beim Umbau der Layer-2-Topologie „mitwandern“ und unbemerkt falsche Netze bedienen.

Bridges und VLANs: Segmentierung auf Layer 2 präzise abbilden

Bridges bündeln mehrere Ethernet-Ports (und optional WLAN-SSIDs) zu einer gemeinsamen Broadcast-Domäne. VLANs schneiden diese Domäne in getrennte Segmente. In typischen Setups liegt eine Bridge wie br-lan über mehreren Switch-Ports, VLAN-Filtering teilt sie in logische Netze (z. B. Clients VLAN 10, Gäste VLAN 20, IoT VLAN 30). Trunk-Links zu einem Managed Switch transportieren mehrere VLANs getaggt; Access-Ports führen genau ein VLAN untagged.

Wichtig ist die Festlegung eines konsistenten „Native/Untagged“-VLAN-Konzepts. In heterogenen Umgebungen (Router + Switch + AP) entstehen Fehler besonders häufig, wenn untagged Frames auf unterschiedlichen Geräten unterschiedlichen VLANs zugeordnet werden. Praktikabel ist ein eindeutiges Management-/Client-VLAN als untagged auf Edge-Ports und ausschließlich getaggte VLANs auf Trunks; alternativ konsequent alles getaggt und untagged nur dort, wo Endgeräte es benötigen. Mischformen ohne Dokumentation führen im Betrieb zu schwer reproduzierbaren Ausfällen.

Firewall-Zonen als Sicherheitsdomänen: Minimalismus mit klaren Forwardings

Firewall-Zonen sollten nicht „LAN vs. WAN“ heißen, sondern reale Vertrauensgrenzen abbilden: Clients, Gäste, IoT, Management, Transit (WAN) und ggf. VPN. Jede Zone enthält die zugehörigen Interfaces; das ist die entscheidende Kopplung zwischen Netzwerkmodell und Policy. Der Default sollte restriktiv sein: interzonales Forwarding nur dort, wo ein begründeter Kommunikationsbedarf besteht. Alles andere bleibt per Default geblockt, statt über Ausnahmen wieder eingefangen zu werden.

Besonders relevant ist die Unterscheidung zwischen Eingangsverkehr zum Router (Input) und Transitverkehr durch den Router (Forward). Gäste sollen typischerweise DNS/DHCP zum Router erreichen, aber keine Verwaltungsdienste wie LuCI oder SSH. IoT-Geräte benötigen häufig nur Internetzugang und ggf. gezielte Freigaben zu einem lokalen Broker oder Controller. Diese Regeln werden robust, wenn Services bewusst an Zonen gebunden werden und „Allow all LAN“ nicht als Abkürzung dient.

• Zonen-Zuordnung prüfen: Interfaces sollten genau einer Zone zugeordnet sein; in UCI ist das nachvollziehbar über /etc/config/firewall (Option list network je Zone).
• Forwardings sparsam halten: Erlaubte Übergänge explizit definieren, z. B. config forwarding von guest nach wan, nicht pauschal nach lan.
• Router-Input segmentieren: Verwaltungszugriff nur aus einer Management-Zone; für Gäste/IoT Input auf nötigste Infrastruktur begrenzen, z. B. DHCPv4, DHCPv6, DNS.
• Interne Dienste nicht „global“ öffnen: Wenn ein Dienst lauschen muss, dann gezielt binden oder per Regel erlauben; relevante Identifikatoren sind u. a. uhttpd, dropbear, odhcpd, dnsmasq.

Modellierungsfehler erkennen: Symptome, Ursachen, typische Stolpersteine

Fehlkonfigurationen wirken im Alltag selten spektakulär, sondern äußern sich als „sporadisch kein Internet“, „Drucker nicht auffindbar“ oder „Gäste sehen plötzlich NAS“. Hinter solchen Symptomen stecken häufig inkonsistente Bindungen zwischen Bridge/VLAN/Interface und Zone. Ein Klassiker ist ein Interface, das nach einer VLAN-Umstellung weiter auf dem alten Device hängt und dadurch in der falschen Zone landet. Ebenso häufig: zwei DHCP-Server in derselben Broadcast-Domäne, weil eine SSID versehentlich in die Haupt-Bridge gebridged wurde.

Für die Diagnose ist die Trennung der Ebenen hilfreich: Zuerst Layer 2 (kommt das Gerät im richtigen VLAN an, passt Tagging?), dann Layer 3 (stimmt die Adresse, Gateway, Routen), dann Policy (blockiert die Firewall Input/Forward). In OpenWrt liefern die Statusansichten zu Devices/Bridges und Firewall-Zonen schnelle Indikatoren; in UCI zeigt eine konsistente Benennung (z. B. br-lan.10 ↔ clients ↔ Zone clients) deutlich schneller Abweichungen als generische Namen.

Ein weiterer Stolperstein ist das unbewusste „Aufblasen“ der LAN-Zone: Sobald Gäste- oder IoT-Interfaces der LAN-Zone zugeordnet werden, greifen deren großzügige Input- und Forward-Defaults. Das fällt oft erst auf, wenn laterale Angriffe möglich werden oder interne Dienste ungewollt exponiert sind. Umgekehrt führt eine zu enge Zone ohne DNS/DHCP-Freigaben zu scheinbar „toten“ Segmenten, obwohl VLAN und IP korrekt sind. Saubere Modellierung verhindert beide Extremfälle, weil sie die Regeln entlang echter Vertrauensgrenzen erzwingt.

Stabiles Basissetup in der Praxis: Segmentierung (Clients/Gast/IoT), DHCP/DNS-Design und nachvollziehbare Firewall-Regeln

Segmentierung als Grundannahme: Zonen statt „flaches LAN“

Ein produktiv betriebener OpenWrt-Router bleibt wartbar, wenn die Netzstruktur nicht aus einzelnen Ausnahmen besteht, sondern aus wenigen, klar getrennten Sicherheitsdomänen. Praxisnah hat sich eine Dreiteilung bewährt: ein vertrauenswürdiges Client-Netz für Arbeitsgeräte, ein Gastnetz ohne Zugriff auf interne Ressourcen und ein IoT-Netz für Geräte mit schwankender Update- und Sicherheitslage. Die Trennung sollte technisch über eigenständige Layer-3-Netze erfolgen; VLANs sind dafür die saubere Transporttechnik, die Policy entsteht jedoch in der Firewall.

Für ein Basissetup genügt es, je Segment ein eigenes Interface in OpenWrt zu definieren (typischerweise ein L3-Interface pro VLAN-Subinterface der Bridge) und dieses Interface genau einer Firewall-Zone zuzuordnen. Wichtig ist die disziplinierte Namensgebung, weil sie später in Regeln, Logs und Diagnosepfaden wiederkehrt. Zonen sollten wenige, konsistente Forwardings besitzen: Clients dürfen ins WAN, Gäste nur ins WAN, IoT je nach Bedarf ins WAN und optional gezielt zu einzelnen internen Diensten (z. B. DNS, NTP, Home-Automation-Controller) – aber nicht pauschal ins Client-Netz.

DHCP/DNS-Design: wenige zentrale Regeln, keine Überraschungen

Stabilität entsteht, wenn DNS und DHCP pro Segment vorhersehbar bleiben. OpenWrt setzt in der Standardinstallation auf dnsmasq als kombinierten DHCP- und DNS-Forwarder; diese Bündelung ist für kleine Netze sinnvoll, solange sie pro Interface sauber getrennt wird. Pro Segment sollte es genau einen DHCP-Server geben, konsistente Lease-Zeiten und definierte Options (Gateway, DNS, NTP). Mischbetrieb mit weiteren DHCP-Servern in derselben Broadcast-Domäne führt in der Praxis zu schwer reproduzierbaren Störungen und sollte vermieden werden.

Für DNS lohnt es sich, eine klare Entscheidung zu treffen: entweder OpenWrt als zentraler Resolver/Forwarder (ggf. mit lokalen Overrides und Rebind-Schutz), oder ein dedizierter Resolver im LAN, auf den OpenWrt per DHCP verweist. In beiden Fällen muss verhindert werden, dass Gäste- oder IoT-Segmente „irgendwie“ interne DNS-Suffixe auflösen, wenn das nicht gewünscht ist. Lokale Namen sollten segmentiert bleiben: Ein IoT-Gerät braucht typischerweise keine Sicht auf Hostnamen aus dem Client-Netz, um zu funktionieren.

Gerätegruppen mit fester Rolle profitieren von statischen Leases statt zufälliger Adressvergabe, insbesondere Controller, NAS, Drucker oder Management-APs. Entscheidend ist dabei die Quellwahrheit: Statische Leases werden zentral in OpenWrt gepflegt, nicht halb im Router und halb in Endgeräten. Gleichzeitig sollten in Segmenten mit höherem Risiko (Gäste/IoT) Lease-Zeiten und eine restriktive DNS-Policy so gewählt werden, dass Fehlkonfigurationen schneller auffallen und weniger „Altlast“ in Clients hängen bleibt.

• DHCP pro Interface eindeutig binden: In /etc/config/dhcp pro Abschnitt config dhcp das Zielinterface über option interface 'guest' bzw. option interface 'iot' festlegen, um versehentliche Cross-Segment-Leases zu verhindern.
• DNS-Zugriff nur zum Router oder definiertem Resolver: Firewall-Regeln so setzen, dass aus guest/iot nur tcp/53 und udp/53 zum vorgesehenen DNS-Ziel möglich sind; alle anderen DNS-Ziele blockieren, um Hardcoded-DNS und Datenabfluss zu begrenzen (Hinweis: Das kann DoH/DoT nicht vollständig verhindern, reduziert aber klassische DNS-Leaks).
• Statische Leases nachvollziehbar benennen: Für feste Zuordnungen Hostnamen konsistent verwenden und in /etc/config/dhcp in config host pflegen; Gerätetyp und Segment im Namen abbilden (z. B. iot-sensor-flur, lan-nas).
• IPv6 nicht „nebenbei“ laufen lassen: Falls IPv6 genutzt wird, pro Segment RA/DHCPv6 bewusst konfigurieren; falls nicht, IPv6 je Segment explizit deaktivieren, damit keine unbeabsichtigten globalen Erreichbarkeiten entstehen.

Firewall-Regeln: Default-Deny, dann nur benötigte Ausnahmen

Nachvollziehbarkeit entsteht in OpenWrt, wenn wenige Prinzipien konsequent umgesetzt werden: Zonen definieren die Default-Policy, Forwardings werden sparsam gesetzt, und Ausnahmen werden als einzelne, benannte Regeln dokumentiert. Für Gäste und IoT ist input typischerweise REJECT; erlaubt werden nur die zwingenden Router-Dienste wie DHCPv4 (udp/67), DHCPv6 (Server-Port typischerweise udp/547, je nach RA/DHCPv6-Design) und DNS. Administration (LuCI/SSH) bleibt auf das Client-Segment beschränkt, idealerweise zusätzlich über eine Management-IP oder ein dediziertes Management-VLAN.

Zwischen den internen Segmenten sollte nicht per pauschalem Forwarding geöffnet werden. Stattdessen wird pro benötigtem Datenfluss eine Regel formuliert, die Quelle, Ziel, Protokoll und Port festlegt. Das reduziert den Prüfaufwand bei späteren Änderungen erheblich: Wenn ein IoT-Gerät „plötzlich“ nach innen funkt, ist klar erkennbar, ob es eine passende Regel gibt oder ob die Kommunikation bereits an der Policy scheitert. Logging gehört selektiv dazu: Für Block-Regeln bei Gästen/IoT kann Rate-Limited-Logging sinnvoll sein, während im Client-Netz zu viel Logvolumen eher verdeckt als hilft.

Ein häufiger Stabilitätskiller ist eine implizite Öffnung über zu breit gesetzte Forwardings oder falsch platzierte NAT-Regeln. In OpenWrt sollte Masquerading/NAT in der Regel auf die WAN-Zone beschränkt bleiben; interne Zonen bekommen kein Masquerading, außer es existiert ein konkreter, nachvollziehbarer Grund (z. B. isoliertes Lab-Netz hinter einem Upstream ohne Routing). Ebenso kritisch sind fälschlich zur WAN-Zone zugeordnete Interfaces: Ein internes VLAN, das in der WAN-Zone landet, wird schlagartig wie „Internet“ behandelt und kann je nach Regelwerk zu offenen Eingängen oder zu Totalausfällen durch Anti-Spoofing/Reverse-Path-Filter führen.

• Zonen-Defaults festlegen: Für guest und iot input REJECT, output ACCEPT, forward REJECT; für lan je nach Betriebsmodell input ACCEPT und Forwardings strikt nur in Richtung wan.
• Forwardings minimal halten: Nur lan→wan, guest→wan, iot→wan als Zonen-Forwarding; inter-zone Verkehr ausschließlich über explizite Regeln.
• Ausnahmen als „Service-Regeln“ formulieren: Beispielhaft IoT zu Controller: Quelle iot, Ziel-IP 192.168.10.50, Zielport 1883/tcp (MQTT) oder 8123/tcp (Home Assistant), alles andere weiterhin blockieren.
• Managementflächen begrenzen: LuCI/SSH ausschließlich aus lan erlauben; zusätzliche Absicherung über Interface-Bindung (z. B. uhttpd/dropbear nur auf Management-IP/Interface) und Firewall-Regeln ohne Quellnetz „any“ vermeiden.

Praktische Prüfpunkte: Konsistenz, Sichtbarkeit, Fehlersuche ohne „Trial and Error“

Ein Basissetup gilt erst dann als stabil, wenn sich seine Wirkung verlässlich prüfen lässt. Dazu gehören einfache, wiederholbare Checks: In jedem Segment muss ein Client per DHCP eine Adresse, Gateway und DNS erhalten; DNS-Auflösung muss erwartbar sein (intern nur dort, wo vorgesehen); und Verbindungen zwischen Segmenten müssen an genau den beabsichtigten Stellen scheitern. Für die Firewall ist entscheidend, dass Regeln nicht nur „funktionieren“, sondern auch beim späteren Lesen eindeutig bleiben: sprechende Namen, kurze Regeltexte, und keine Sammlung von „temporären“ Allow-Regeln, die dauerhaft bleiben.

Für die Diagnose im Alltag lohnt es sich, an wenigen Stellen Sichtbarkeit zu schaffen: Status der Interfaces, DHCP-Leases, aktive Firewall-Regeln und ein begrenztes Log. Wenn ein Segment ausfällt, ist die häufigste Ursache nicht ein defektes Paket, sondern ein falsches Interface-Mapping (VLAN-Tagging, Bridge-Zuordnung) oder eine Zone, die unbeabsichtigt geändert wurde. Ein zweiter typischer Fehler ist ein DNS-Design, das „nach außen“ zwar funktioniert, intern aber durch Rebind-Schutz, Split-DNS oder unterschiedliche Resolver in Segmenten zu inkonsistenten Ergebnissen führt.

• Interface- und Adresslage prüfen: ip -br addr
ip route
• DHCP-Leases und dnsmasq-Status kontrollieren: logread -e dnsmasq
cat /tmp/dhcp.leases
• Firewall-Zuordnung und effektive Regeln verifizieren: uci show firewall
nft list ruleset
• Segmentierung praktisch testen: Von einem Gast-Client nur Internetzugriff verifizieren, interne Ziele wie 192.168.10.1 oder 192.168.10.50 müssen scheitern; im IoT-Segment nur die explizit freigegebenen Ziele/Ports erreichen.

Betrieb, Updates und Recovery: Upgrade-Strategien, Backups, Erweiterungen (VPN/Dienste) und typische Fehlkonfigurationen systematisch beheben

Upgrade-Strategien im Dauerbetrieb: planbar, reproduzierbar, verifizierbar

Im produktiven Betrieb entscheidet weniger die reine Update-Frequenz als die Methode: Ein Router-Update muss wiederholbar ablaufen, Ausfallzeiten begrenzen und nachweisbar die gewünschte Konfiguration behalten. Bei OpenWrt hängt das Vorgehen stark davon ab, ob das Gerät Dual-Boot-/A/B-Mechanismen unterstützt oder klassisch nur eine Firmware-Partition nutzt. In beiden Fällen bewährt sich ein fester Ablauf: Vorab Integritätsprüfung des Images, Sicherung der Konfiguration, kontrollierte Installation und ein kurzer Funktionstest (WAN, DNS, DHCP, zentrale Firewallpfade, VPN-Tunnel).

Technisch sauber bleibt ein Upgrade, wenn Pakete und Kernel zueinander passen. In der Praxis bedeutet das: Für große Versionssprünge (z. B. neue Hauptversion) ist ein „Sysupgrade“ mit bewusst gewählter Konfigurationsmitnahme oder ein Neuaufsetzen mit anschließendem Restore häufig verlässlicher als das Fortziehen historisch gewachsener Paketstände. Zusätzlich sollte vor jedem Update geprüft werden, ob installierte Zusatzpakete (VPN, Proxy, Adblock, DNS-Resolver) zur Zielversion verfügbar sind und welche Konfigurationsdateien davon betroffen sind.

• Release-Stand ermitteln: cat /etc/openwrt_release
ubus call system board
• Freien Flash-/Overlay-Speicher prüfen: df -h
opkg list-installed | wc -l
• Sysupgrade mit nachvollziehbarem Ablauf: sysupgrade -T /tmp/openwrt.bin
sysupgrade /tmp/openwrt.bin
• Konfigurationsmitnahme bewusst steuern: sysupgrade -n /tmp/openwrt.bin
sysupgrade -b /tmp/backup-$(date +%F).tar.gz
• Paketverwaltung nach dem Boot prüfen: opkg update
opkg list-installed

Backups: Konfiguration, Schlüsselmaterial und reproduzierbare Wiederherstellung

Ein OpenWrt-Backup ist nur dann betriebstauglich, wenn es mehr umfasst als die Standard-Archivierung der UCI-Konfiguration. In realen Setups liegen kritische Zustände oft in Schlüsselmaterial (VPN), Zertifikaten, benutzerdefinierten Skripten, zusätzlichen DNS-Listen oder lokalen Overrides. Ebenso wichtig ist die Trennung zwischen „Geräte-Identität“ (Hostkeys, WireGuard-Keys, Zertifikate) und „Netz-Design“ (Interfaces, Firewallregeln, DHCP-Scopes). Für Wiederherstellungstests empfiehlt sich eine zweite Instanz (Ersatzrouter oder VM), um das Backup ohne Zeitdruck zu entpacken und die relevanten Dateien zu verifizieren.

• Konfigurationsarchiv erzeugen: sysupgrade -b /tmp/openwrt-backup-$(date +%F).tar.gz
• Restore im Fehlerfall: sysupgrade -r /tmp/openwrt-backup.tar.gz
• Schlüsselmaterial lokalisieren (Beispiele): ls -la /etc/wireguard
ls -la /etc/dropbear
ls -la /etc/ssl
• Konfigurationsänderungen auditierbar halten: uci changes
uci show network
uci show firewall

Für Betriebsstabilität zählt außerdem, dass Backups nicht ausschließlich auf dem Router verbleiben. Ein externer Transfer (z. B. per SCP auf einen Admin-Host) und eine klare Benennung nach Datum, Gerät und Zielrelease verhindert Verwechslungen. Bei mehreren Geräten im Verbund sollten Backups pro Gerät getrennt abgelegt werden, weil MAC-Adressen, Interface-Namen oder Hardware-Offloads die Konfiguration beeinflussen können.

Sichere Erweiterungen: VPN, zusätzliche Dienste und die Folgen für Firewall und Ressourcen

Zusatzdienste erhöhen die Angriffsfläche und verschieben oft die „Single Point of Failure“-Grenze: Sobald DNS-Filter, Reverse-Proxy, VPN-Endpunkt oder Telemetrie auf dem Router laufen, hängt die gesamte Netzfunktion stärker von diesem System ab. Der sichere Ausbau folgt daher zwei Leitlinien: Erstens darf ein zusätzlicher Dienst keine implizite Öffnung der Firewall erzwingen. Zweitens müssen Ressourcen (RAM, Flash, CPU) ausreichend dimensioniert sein, damit Updates, Logs und Paketoperationen nicht am vollen Overlay scheitern.

Bei VPN ist die Zonenzuordnung entscheidend. Ein WireGuard-Interface sollte typischerweise einer dedizierten Firewall-Zone zugeordnet werden, mit expliziten Forwarding-Regeln in die Zielsegmente. Gleiches gilt für OpenVPN, insbesondere wenn ein „client-to-site“-Szenario Zugriff auf interne Netze erhält. Dienste, die auf dem Router lauschen (z. B. Web-UIs, Admin-APIs), sollten nur auf Management-Netzen oder per VPN erreichbar sein; ein Listen auf 0.0.0.0 in Kombination mit einer liberalen WAN-Zone ist ein wiederkehrender Fehler.

• Offene Ports und Listener prüfen: ss -lntup
netstat -lntup
• Firewall-Zuordnung kontrollieren: uci show firewall | grep -E "zone|forwarding|rule"
• VPN-Status schnell verifizieren: wg show
logread | grep -i wireguard
• Ressourcenengpässe früh erkennen: free -h
top
logread -e "No space left"

Typische Fehlkonfigurationen: Muster erkennen, Ursachen eingrenzen, sauber korrigieren

Viele Störungen im Alltag lassen sich auf wenige Muster zurückführen: falsche Interface-Bindings, zu breite Firewall-Zonen, widersprüchliche Routen, oder DNS/DHCP-Einstellungen, die Segmentgrenzen unabsichtlich durchlöchern. Besonders riskant sind Änderungen, die „still“ wirken: Ein Interface wird der falschen Zone zugeordnet und ist plötzlich aus einem Gastnetz erreichbar; eine VLAN-ID kollidiert mit dem Switch-Setup; ein DHCP-Server läuft in zwei Netzen parallel, was sporadische Adresskonflikte erzeugt.

Systematisch wird die Fehlerbehebung, wenn Änderungen zunächst im laufenden System nachvollzogen werden: Was hat sich an Interfaces und Zonen verändert, welche Regeln greifen tatsächlich, und welche Komponente liefert den DNS- und Default-Gateway? Für die Eingrenzung helfen Laufzeitdaten stärker als Konfigurationsausschnitte. Besonders nützlich sind die effektiven Regeln (nftables; iptables ggf. nur noch als Kompatibilitätsebene je nach Release) und Routingtabellen, weil sie Abweichungen zwischen geplanter und wirksamer Konfiguration sichtbar machen.

• Routing- und Interface-Realität prüfen: ip route
ip addr
• Firewall-Regeln zur Laufzeit inspizieren: nft list ruleset
iptables -S
• Logbasierte Eingrenzung: logread
logread -f
• Konfiguration gegen Laufzeit abgleichen: uci show network
uci show firewall
/etc/init.d/network restart

Recovery und Wiederanlauf: Failsafe, sichere Rückkehr zur Basis und kontrollierte Re-Integration

Recovery sollte als Betriebsprozess verstanden werden, nicht als Ausnahme. Ein Router, der „nur noch per WLAN“ erreichbar ist, deutet häufig auf eine LAN-Fehlkonfiguration oder eine Zone mit zu restriktiven Input-Regeln. Bei schweren Fehlzuständen (z. B. nach abgebrochenem Upgrade oder gesperrtem Managementzugang) ist der Failsafe-Modus das zentrale Werkzeug, um wieder Zugriff zu erhalten und die kritischen Dateien zu korrigieren. Danach folgt der kontrollierte Wiederanlauf: Basisnetz (LAN), WAN, DNS/DHCP, Firewall-Zonen, erst anschließend Dienste wie VPN oder Zusatz-DNS.

Für die Praxis bewährt sich ein minimaler „Rettungsplan“, der unabhängig von der GUI funktioniert: Zugriff über LAN, Notfall-IP, Backup-Datei lokal verfügbar, und ein klarer Punkt, an dem ein Clean-Install schneller und risikoärmer ist als langes Reparieren. Bei Geräten mit wenig Flash ist ein Rückbau installierter Pakete oft Teil der Wiederherstellung, weil ein volles Overlay weitere Operationen verhindert. Nach erfolgreichem Boot sollten Logs unmittelbar geprüft werden, um wiederkehrende Fehler (z. B. fehlschlagende Dienststarts) nicht zu übersehen.

• Konfigurationssicherung vor riskanten Eingriffen (sofern möglich): sysupgrade -b /tmp/pre-recovery-backup.tar.gz
• Netzwerk minimal neu starten nach Korrekturen: /etc/init.d/network restart
/etc/init.d/firewall restart
• Werkseinstellungen als letzter Schritt (gerät-/imageabhängig): firstboot -y
reboot
• Nach Recovery gezielt validieren: ping -c 3 1.1.1.1
nslookup openwrt.org 1.1.1.1
nft list ruleset