blog.bartlweb - a technologist's external brain

Thema: Netzwerk

SSH-Zugriff auf OpenWrt per Public Key Authentifizierung absichern

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.

ssh-keygen -t rsa -b 4096

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

scp /home/<user>/.ssh/id_rsa.pub remoteuser@remotehost:/tmp

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.

cat /tmp/id_rsa.pub >> /etc/dropbear/authorized_keys

2,4GHz WLAN unter OpenWrt verschwindet in unregelmäßigen Zeitabständen

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.

FreeDNS-IP-Update per HTTPS-Update-URL hängt unter OpenWrt

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.

VPN-Server mit NAT hinter einem OpenWrt-Router betreiben

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.

opkg install kmod-nf-nathelper-extra

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:

Zugriff auf das Tor-Netzwerk mittels OpenWrt-Router blockieren

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.

VLAN auf Linksys WRT1200AC mit OpenWrt 15.0.1 konfigurieren

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

Erfahrungsbericht: Stationäres Internet über Mobilfunk mit dem 3HuiGate und 3HuiTube

Alle großen Mobilfunkprovider bieten seit dem Ausbau auf LTE auch Tarife für stationäres Internet via Mobilfunk als Alternative zur DSL-Leitung bzw. Internet über Kabel an. Drei ist hier insbesondere interessant, da einerseits Verträge mit unlimitierten Datenmengen angeboten werden, die versprochenen Geschwindigkeiten (gerade auch in Bezug auf die Uploadgeschwindigkeit) sehr hoch sind und auch fixe IP-Adressen für den Betrieb eines Servers erhältlich sind.

Ich habe mich privat um eine Alternative zu meinem 16Mbit-Telkom-ADSL-Anschluss umgesehen und bin bei Drei Hui Flat 150 gelandet. Dabei hatte ich die Gelegenheit das Topgerät 3HuiGate und den schließlich auch seit dem Testbetrieb behaltenen 3HuiTube zu auszuprobieren.

WLAN-Verbindungsprobleme am Linksys WRT1200AC mit OpenWRT 15.05.1

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.

NAT Reflection in einer Double-NAT Konfiguration mit OpenWrt

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.

Probleme mit zwei Netzwerkkarten beim Betrieb im selben Netzwerk unter Windows

Ein Serversystem, das gleichzeitig sowohl Dienste als auch Netzwerkfreigaben bereitstellt, kommt bei hohen Zugriffszahlen schnell einmal in einen Engpass bei der Anbindung ans lokale Netzwerk. Es würde sich doch anbieten eine Netzwerkkarte für Zugriffe auf Dateifreigaben und eine Netzwerkkarte für Zugriffe auf Serverdienste in den Rechner einzubauen und die Dienste an die entsprechenden Karten bzw. IP-Adressen der Karten zu binden.

Die Idee scheint schlüssig, nur verhält sich Windows ohne weitere Konfiguration mit zwei Netzwerkkarten nicht wie gedacht. Auch wenn nur eine Netzwerkkarte ein eingetragenes Gateway hat, kann es vorkommen, dass Windows Zugriffe auf den Server zwar über die Netzwerkkarte, welche die angesprochen IP-Adresse zugewiesen hat, entgegennimmt (Downstream) die Antwortpakete (Upstream) aber trotzdem über die andere Karte ins Netzwerk schickt.