Die Router-Firmware LEDE (Nachfolger von OpenWrt) lässt sich nicht nur durch Aufspielen eines neuen Firmwareimages aktualisieren, sondern bietet mit dem Packagemanager opkg auch eine Paketverwaltung zum Installieren, Deinstallieren, sowie eben auch zum Aktualisieren von Softwarepaketen an. Wer die Kommandozeile nicht scheut, kann so die Software seines Routers mit wenigen Befehlen aktuell halten.

Zunächst muss das lokale Softwareverzeichnis aktualisiert werden. Der folgende Befehl lädt die aktuellen Softwarelisten aus dem Internet:

Danach kann man sich die verfügbaren Updates mit dem nachstehenden Befehl als Liste anzeigen lassen:

Um den Zugriff per SSH auf einen Router mit OpenWrt abzusichern, können Sie bis auf einen kleinen aber feinen Unterschied wie auf jedem anderen Linux-System vorgehen.

Erstellen Sie auf dem Host von dem aus Sie gerne den Zugriff absichern bzw. vereinfachen möchten mit dem folgenden Befehl einen privaten und den für die Autorisierung notwendigen öffentlichen Schlüssel.

Danach kopieren Sie die generierte Datei id_rsa.pub per scp auf den Router.

Im Unterschied zu Linux-Systemen liegt die Datei authorized_keys, die die öffentlichen Schlüssel der berechtigten Rechner enthält, nicht im Nutzerverzeichnis, sondern im allgemeinen Pfad /etc/dropbear/authorized_keys. Fügen Sie mit dem folgenden Befehl den öffentlichen Schlüssel hinzu. Danach sollte die Authentifizierung per Public Key sofort funktionieren.

Seit dem Umstieg auf die neuste Version von OpenWrt - Chaos Calmer 15.05.1 - habe ich das Problem, dass mein 2,4GHz-WLAN und das zusätzlich als virtuelles Netzwerk darauf eingerichtete Gast-WLAN von Zeit zu Zeit verschwindet, also von Clients nicht mehr gefunden werden kann. Abhilfe schaffte bisher nur ein Neustart des gesamten Netzwerkstacks oder Routers, der dieses dann zwischen wenigen Stunden und ein paar Tagen wieder zum Vorschein brachte.

Eine kurze Recherche hat mich darauf gebracht, dass die Einstellung Auto für den Channel dafür verantwortlich sein könnte und auch erklären würde, warum nur mein 2,4GHz-WLAN nicht aber das 5GHz-WLAN, das auf einen festen Channel eingestellt ist, Probleme macht.

Wer mit einer dynamischen IP-Adresse einen Serverdienst nach außen anbieten will, ist auf einen dynamischen DNS-Hosting-Anbieter angewiesen. Die Anzahl der kostenfreien Dienste ist mittlerweile überschaubar und daher setze auf den aktuell kostenfrei nutzbaren Anbieter FreeDNS (freedns.afraid.org).

Das Update der IP-Adresse soll mein OpenWRT-Router erledigen, der die Änderung wohl als Erster direkt nach dem Modem mitbekommt und ich nutze dazu die Pakete luci-app-ddns und ddns-scripts um die Einstellungen komfortabel über die LuCI-Weboberfläche des Routers durchführen zu können.

Auch wenn es nicht empfehlenswert ist, ist es gerade im kleinen Firmennetzwerk oder Heimnetzwerk oft nicht anderes möglich, als auch den VPN-Server hinter einer Firewall mit NAT zu betreiben. Einige kleine Kniffe und Portforwardings erledigen unter OpenWrt diese Aufgabe ganz souverän.

PPTP

Um einen PPTP-Server hinter einer NAT-Firewall zu betreiben, installieren Sie zunächst das Paket kmod-nf-nathelper-extra am Router.

Fügen Sie nun zur Firewall ein Port-Forwarding für den Port 1723 (TCP) auf Ihren VPN-Server (im Beispiel mit der IP 192.168.1.1) hinzu und ergänzen Sie die folgenden Firewall-Regeln im Skript firewall.users:

Webfilter auf Basis von DNS-Sperrlisten (z.B. über OpenDNS) funktionieren für die Regulierung von Zugriffen auf Inhalte im Internet perfekt. Greift ein Nutzer jedoch aus dem eigenen Netzwerk über Tor bzw. den einfach zu installierenden Tor Browser zu, greifen diese Sperrlisten nicht mehr. Das Tor-Netzwerk nutzt eigene DNS-Dienste bzw. leitet den gesamten Netzwerkverkehr verschleiert nach außen.

Um den Zugriff auf das Internet via Tor im eigenen Netzwerk zu sperren, bedarf es daher dem Blockieren des Zugriffs auf die Tor-Zugriffspunkte anhand von IP-Adressen. Für den regulären Zugriff auf das Tor-Netzwerk funktioniert das über öffentlich zugängliche Listen der Entry- und Exit-Nodes sehr gut. Für den Zugriff über die Tor-Bridges habe ich eine rudimentäre Liste an bereits im Browser-Bundle hinterlegten IP-Adressen zusammengefasst. Hier ist manuelle Nacharbeit und vor allem eine regelmäßige Aktualisierung notwendig, um den Zugriff dauerhaft und konsequent zu unterbinden.

Nach dem Aufspielen von OpenWrt in der letzten verfügbaren Version 15.0.1 auf meinen neuen Linksys WRT1200AC Router wurde in den Einstellungen (LuCI Webinterface) der Punkt Network -> Switch zur Konfiguration der benötigten VLANs nicht angezeigt. Der im Router verbaute Switch ist VLAN-tauglich und dementsprechend kann mit etwas Handarbeit und dem manuellen Editieren der Datei /etc/config/network die Unterstützung für VLANs aktiviert werden. Danach wird auch im Webinterface der entsprechende Eintrag angezeigt.

Belegung und Hardwareaufbau der Ports

OpenWRT nutzt für die einzelnen Ports die folgenden internen Bezeichnungen:

• WAN
  • eth1
  • Switch Port 4
  • CPU Port 6
• LAN
  • eth 0

Ich betreibe den Router Linksys WRT1200AC mit der letzten Version von OpenWrt 15.05.1 (Chaos Calmer) und musste leider feststellen, dass die WLAN-Implementierung fehlerhaft und damit eigentlich nicht nutzbar ist.

Bei meiner WLAN-Verbindung treten die folgenden Probleme reproduzierbar auf:

• Zufällige Verbindungsabbrüche, nach denen sich der Client auch nicht erneut verbinden kann.
• Clients können sich nicht zuverlässig mit dem WLAN verbinden.
• Dateizugriffe über WLAN auf im Netzwerk befindliche Server sind extrem langsam (Videos ruckeln durchgehend), während die Geschwindigkeit über den WAN-Port Richtung Internet fehlerfrei funktioniert.

Die oben genannten Probleme sind nach einem Neustart für einige Minuten verschwunden, treten dann aber erneut wieder auf.

Wenn das vom Internetservice-Provider bereitgestellte Modem keinen Bridge-Modus unterstützt, lässt sich ein eigener Router nur im DMZ betreiben. Dabei erfolgt allerdings bereits ein NAT und der dahinterliegende Router bekommt keine öffentliche IP-Adresse mehr zugewiesen. Damit NAT Reflection im internen Netzwerk funktioniert, d.h. die externe IP-Adresse des eigenen WAN-Anschlusses auch aus dem eigenen Netzwerk erreichbar ist, muss der interne Router die öffentliche IP kennen, um entsprechende Port-Forwarding-Regeln anlegen zu können.

Lösung 1

OpenWrt erstellt zu allen angelegten Portforwarding-Regeln für jedes WAN-Interface automatisch die notwendigen Firewall-Regeln für NAT Reflection. Eine Lösung NAT Reflection für die öffentliche IP-Adresse bei einer doppelten NAT-Konfiguration zu ermöglichen ist daher am zweiten Router ein virtuelles Interface anzulegen, dem die öffentliche IP-Adresse zugewiesen wird.

Mein Server läuft und läuft, außer ich bin gerade nicht zu Hause, dann hängt er sich aus unerklärlichen Gründen ab und zu auf. Zuverlässiger im Dauerbetrieb ist da schon mein OpenWrt-Router. Darum nutze ich diesen, um dort ein zusätzliches Webinterface für das Absetzen eines IPMI-Befehls zum Neustart des Servers (siehe: Server über IPMI mithilfe von ipmitool fernsteuern), laufen zu lassen. Dazu habe ich unter OpenWrt PHP installiert und einen zusätzlichen Host inkl. Passwortschutz im Webserver eingerichtet, sowie ein kleines PHP-Skript erstellt.

uhttpd konfigurieren

Umstellen des Zugriffs auf HTTPS

Zunächst habe ich uhttpd um die Fähigkeit von SSL-gesicherten Verbindungen mittels HTTPS erweitert und dabei auch gleich den Zugriff auf das Konfigurationsinterface (Luci) auf HTTPS umgestellt.