Neuzugang im Wireless LAN

Unsere bestehende WLAN-Infrastruktur zu Hause ist mittlerweile ein wenig in die Jahre gekommen – Zeit, um ein wenig nach rechts und links zu schauen, ob ich da nicht für ein wenig frischen Wind sorgen kann.

Das Problem: über das Haus verteilt befinden sich mehrere Access Points (APs), die einerseits WPA2-Enterprise unterstützen und unsere WLAN-Clients zertifikatbasiert gegen einen RADIUS-Server authentifizieren. Andrerseits sind diese dann mit derzeit vier Erhernet-Ports als Switch ausgestattet und versorgen vor Ort einige drahtgebundene Geräte mit Internet bzw. lokalem Netzwerk. Da gestaltet sich die Suche nach einem passenden Neugerät schon etwas schwieriger…

Ein Gerät mit diesen Merkmalen im professionellen Umfeld zu finden ist nicht unproblematisch, aber machbar. Nachteilig ist hier meist der recht hohe Kaufpreis. Im Consumer-Bereich sind mir diese Geräte meist nur in Form von kombinierten DSL-Routern / Switch / AccessPoint-Kombinationen untergekommen, die ich als reinen Access Point dann auch nicht unbedingt einsetzen wollte. Durch Zufall ist mir allerdings der Asus RP-AC68U aufgefallen und ich habe mal ein Gerät als potentiellen Ersatz für den betagten WLAN-AP in unserem Dachgeschoss angeschafft.

Bisher arbeitete dort – wie in einigen anderen Etage auch – ein D-Link DAP-1522 mit vier Gigabit Ethernet-Ports und der Unterstützung für WLAN gemäß IEEE 802.11b, 802.11g und 802.11n im 2,4GHz-Frequenzbereich. Umgeben von den anderen Funkzellen meiner Nachbarn und der damit permanent verfügbaren Auswahl aus mindestens zehn weiteren Netzwerken, ist es in diesem Frequenzbereich mit freien Kanälen schon recht eng. Vor einiger Zeit habe ich daher bereits versucht, einige APs im Haus in den 5GHz-Bereich zu verlegen. Da aber nicht alle unsere WLAN-Endgeräte diese Frequenz unterstützen und es bei den DAP-1522 nur eine entweder / oder-Einstellung in der Auswahl zwischen 2,4GHz und 5GHz gibt, bin ich wieder auf den 2,4GHz-Bereich zurückgefallen. Die Authentifizierung nehmen die APs als RADIUS-Clients gegen den zentralen RADIUS-Server mit Hilfe von WPA2 (AES) zertifikatsbasiert vor. Die Zertifikate stammen dabei aus unserer hauseigenen Stammzertifizierungsstelle.

Kurzerhand habe ich im Dachgeschoss den existierenden AP abgeklemmt und den Asus AP an die gleich Position gestellt. Dabei ist dies für den RP-AC68U die einzige Aufstellvariante – der DAP-1522 konnte ebenfalls gestellt bzw. ‚gelegt‘, aber auch an der Wand befestigt werden.

Da stand er dann also und leuchtete:

AsusAP1
Asus RP-AC68U bei Inbetriebnahme

Die Rückseite bietet fünf Gigabit Ethernet-Ports für kabelgebundene Netzwerkgeräte und einen USB 3.0-Anschluss als Festplatten-Anschluss zum Aufbau eines Network Attached Storage (NAS). Daneben existieren noch Anzeigen für die WLAN-Empfangsstärke, eine WPS-Taste und ein Ein/Aus-Schalter:

AsusAP2
RP-AC68U – Anschlüsse

Nach der Inbetriebnahme zeichnete sich jedoch bereits ein erstes kleines Problem ab: der RP-AC68U ist von Hause aus als WLAN-Repeater konzeptioniert und die Anleitung zeigt deutlich, wie dieser zur Erweiterung einer bestehenden WLAN-Infrastruktur mit Wi-Fi Protected Setup (WPS) eingesetzt werden kann. Dabei dienen die Ethernet-Ports nicht WLAN-fähigen Geräte zum Anschluss an das drahtlose Netzwerk und nicht als Uplink. Leider war der Anleitung nicht zu entnehmen, wie die Einrichtung des RP-AC68U als Access Points vorgenommen werden kann. Drahtgebunden gab es keine Möglichkeit das Gerät zu erreichen und über die Asus-Website steht dabei auch kein Tool zur Verfügung.

Das Problem konnte jedoch recht unbürokratisch gelöst werden, indem ich von einem drahtlosen Client aus zunächst nach verfügbaren Netzwerken gesucht habe und mich anschließend mit dem ungesicherten Netzwerk ‚Asus‘ verbunden habe. Direkt gab es vom Access Point eine IP-Adresse via DHCP und ich konnte per Webbrowser eine Verbindung zur AP-Verwaltungswebsite herstellen. Ein Begrüßungsbildschirm präsentierte dabei auch direkt eine Auswahl in welchem Modus ich den RP-AC68U in Zukunft betreiben wollte – als Repeater, als Access Point oder als Media Bridge, für den Aufbau einer drahtlosen Brücke für drahtgebundene Geräte. Hier galt es nun den Modus ‚Access Point‘ auszuwählen und einen Neustart abzuwarten.

Nach dem Neustart hatte sich der RP-AC68U direkt eine IP-Adresse via DHCP in unserem Netzwerk besorgt und funkte als Access Point im 2,4GHz- und 5GHz-Frequenzbereich. Nach den obligatorischen Grundeinstellungen (Administrationskennwort, statische IP-Adresse, NTP-Server) ging es dann an die eigentliche WLAN-Konfiguration. Da im Gegensatz zum bisherigen D-Link-Modell die Dual-Band-Konfiguration möglich ist, habe ich zwei WLAN-SSID mit der entsprechenden Frequenzkennzeichnung konfiguriert. Dabei werden die Standards 802.11a, 802.11b, 802.11g, 802.11n und 802.11ac unterstützt. Unter Verwendung von drei internen Sende- und vier Empfangsantennen soll der RP-AC68U dabei im 5GHz-Bereich eine Bandbreite bis zu 1.300Mbit/s (802.11ac) und im 2,4GHz-Bereich bis zu 600Mbit/s (802.11n) bieten.

Die Konfiguration von WPA2-Enterprise in diesem Zusammenhang verlief völlig unproblematisch und nach Eingabe der IP-Adresse des RADIUS-Server und der Authentifizierungsinformationen unter Verwendung des Standardports klappte die Authentifizierung auf anhieb.

Abends zeigte sich dann jedoch die helle Seite des RP-AC68U – er ersetzt auch gerne mal die kleine Zimmerbeleuchtung:

AsusAP3
Asus RP-AC68U – Licht von überall

Abhilfe konnte ich nach kurzer Internetrecherche schaffen – leider derzeit undokumentiert kann einfach auf den Asus-Schriftzug auf der Vorderseite gestupst werden und die Beleuchtung wird wahlweise aus- oder eingeschaltet.

Ich werde in den kommenden Tagen mal ein paar Leistungsdaten sammeln und diese weiterreichen…

[Nachtrag – 17.09.2016] Eigene SSL-Zertifikate verwenden

Nachdem ich die Grundkonfiguration des RP-AC68U soweit abgeschlossen hatte und sich das Gerät in seinem neuen Zuhause ein wenig akklimatisieren konnte, wollte ich nun die Systemkonfiguration ein wenig optimieren. Dabei viel mir auf, dass die Weboberfläche in der Ursprungskonfiguration über HTTP läuft, wahlweise aber auf HTTPS oder kombiniert HTTP / HTTPS umgeschaltet werden kann. Also flugs die Konfiguration auf HTTPS geändert und schon konnte es SSL-gesichert weiter gehen.

Allerdings kommt dazu, wie so häufig, ein selbst signiertes Zertifikat zum Einsatz, dem meine hausinternen Systeme reihum allerdings nicht vertrauen. In der grafischen Oberfläche gibt es jedoch keine Möglichkeit ein alternatives SSL-Zertifikat einzubinden. Eine kurze Internetrecherche und ein wenig ausprobieren brachte dann jedoch die Lösung…

Die Konfiguration eines eigenen SSL-Zertifikats erfolgt über die Befehlszeile via Telnet oder SSH – im Falle des RP-AC68U steht hier allerdings an der Weboberfläche unter Administration | System nur Telnet zur Verfügung. Diese Funktion galt es zu aktivieren:

asusapconfig1
Aktivierung der Telnet-Funktion

Im gleichen Bereich findet sich ebenfalls die HTTP / HTTPS-Konfiguration – hier wird systemseitig bei Verwendung von HTTPS der Port 8443 statt des Standard-Ports 443 vorgeschlagen. Dagegen hatte ich allerdings nichts.

Anschließend konnte ich unter Verwendung von Putty via Telnet auf den Router zugreifen:

asusapconfig2
Telnet-Zugriff auf den RP-AC68U

Die bei mir erfolgreiche Methode des Zertifikatsaustauschs fing zunächst mit der Bereinigung potentiell noch vorhandener früherer Zertifikatsbereitstellungen an. Dieser Vorgang muss erneut ausgeführt werden, sollte das in diesem Zusammenhang neu erstellte Zertifikat in der Zukunft ebenfalls ausgetauscht werden.

Die Befehlsfolge dazu:

nvram set https_crt_save=0
nvram unset https_crt_file
service restart_httpd
nvram get https_crt_file
reboot

Der Befel ’nvram get https_crt_file‘ dient dabei der Kontrolle und sollte dann kein Ergebnis zurückliefern. Nach dem Neustart kann nun erneut eine Verbindung über Telnet aufgebaut werden.

Im nächsten Schritt konnte ich nun das neue Zertifikat auf den Router aufspielen. Das Problem dabei: Ich hatte von meiner hausinternen Zertifizierungsstelle ein Zertifikat mit privatem Schlüssel, welches ich in eine Datei – wahlweise mit oder ohne privaten Schlüssel – exportieren konnte. Ich habe an dieser Stelle direkt das Zertifikat mit privatem Schlüssel und ohne Zertifikatskette exportiert. Durch den Export des privaten Schlüssels musste ich ein Kennwort während des Exports eingeben. Hier das Ergebnis:

asusapconfig3
Extrahiertes Zertifikat samt privatem Schlüssel

Dann jedoch das Problem: Der RP-AC68U verlangt zum Import des Zertifikats eine Datei ‚cert.pem‘ mit dem Rohtext des Zertifikats als Inhalt und eine Datei ‚key.pem‘ in der sich der private Schlüssel befindet. Mit Bordmitteln von Windows ließ sich das meiner Kenntnis nach nicht bewerkstelligen. Dazu kam hier das Befehlszeilentool OpenSSL zum Einsatz (diverse Versionen sind über die einschlägigen Suchmaschinen zu finden), welches ich lokal in das Verzeichnis ‚C:\OpenSSL‘ extrahiert habe. Dort habe ich dann die folgende Befehlsfolge verwendet:

pkcs12 -in AP4.pfx -clcerts -nokeys -out cert.pem
pkcs12 -in AP4.pfx -nocerts -out key.pem
rsa -in key.pem -out server.key

In der ersten Zeile wird zunächst das Zertifikat in der Datei ‚AP4.pfx‘ ohne den privaten Schlüssel in die Datei ‚cert.pem‘ extrahiert. Da ich eine Zertifikatsdatei mit privatem Schlüssel öffne, muss ich dazu das beim Export angegebene Kennwort eingeben. Anschließend extrahiere ich in der zweiten Zeile den privaten Schlüssel aus der gleichen Quelldatei in die Datei ‚key.pem‘. Da diese Datei erneut geschützt vorliegen soll, muss an dieser Stelle sowohl das Kennwort zum Öffnen der Datei ‚AP4.pfx‘, als auch ein neues Kennwort zum Schutz der Datei ‚key.pem‘ eingegeben werden. Um diesen Schutz abschließend zu entfernen, kommt die dritte Zeile zum Einsatz, wobei der Inhalt der geschützten Datei ‚key.pem‘ ungeschützt in die Datei ’server.key‘ übertragen wird, wobei erneut das Kennwort zum Öffnen der Datei ‚key.pem‘ angefordert wird. Der genaue Ablauf zeigt sicht hier:

asusapconfig4
Verwendung von OpenSSL zur Konvertierung einer PFX-Datei

Nachdem ich diese Dateien erzeugt hatte, konnte ich mich wieder der Telnet-Sitzung zum Asus-AP zuwenden. Hier habe ich nun in der Befehlsfolge den Inhalt der Dateien ‚cert.pem‘ und ’server.key‘ übertragen. Dazu habe ich die beiden Dateien im Windows Notepad / Editior geöffnet (keinen Zeilenumbruch aktiviert!) und jeweils in die Zwischenablage kopiert. Bei der Datei ’server.pem‘ hatte ich dabei keine Probleme, mit der Datei ‚cert.pem‘ schon. Hier war es wichtig nur den Teil ab ‚—–BEGIN CERTIFICATE—–‚ bis zum Ende zu markieren. Die Übernahme des gesamten Inhalts hat bei mir zunächst nicht funktioniert. Eine gute Übersicht wie sich die Dateien ‚key.pem‘ und ‚cert.pem‘ zusammensetzen habe ich bei DigiCert hier gefunden (Stand: September 2016).

In der ersten Zeile aktiviere ich die Ablage der Dateien ‚key.pem‘ und ‚cert.pem‘ auf dem AP, anschließend überprüfe ich mit dem folgenden Befehl, ob dieser Wert erfolgreich gesetzt wurde. Nun verwende ich den Befehl ‚cat‘ um Inhalt an die Datei ‚/etc/key.pem‘, bzw. ‚/etc/cert.pem‘ anzufügen. Mit ‚STRG+D‘ wird die jeweilige Bearbeitung beendet und die Datei gespeichert.

Der erste Befehl ’nvram get https_crt_file‘ sollte anschließend noch kein Ergebnis zurückliefern, durch den anschließenden Neustart des Webservers (’service restart_httpd‘) werden die Dateien ‚key.pem‘ und ‚cert.pem‘ jedoch ausgelesen und in der Zertifikatsdatei unter zusammengeführt. Daher sollte die zweite Ausführung von ’nvram get https_crt_file‘ ein Ergebnis zurückliefern. Ist das der Fall, kann der AP neu gestartet werden (‚reboot‘).

nvram set https_crt_save=1
nvram get https_crt_save 
cat >/etc/key.pem
-----BEGIN RSA PRIVATE KEY-----
<Inhalt 'server.key' via Notepad kopiert>
-----END RSA PRIVATE KEY-----

# STRG+D zum Speichern der Datei

cat >/etc/cert.pem
-----BEGIN CERTIFICATE-----
<Inhalt 'cert.pem' via Notepad kopiert>
-----END CERTIFICATE-----

# STRG+D zum Speichern der Datei

nvram get https_crt_file
service restart_httpd
nvram get https_crt_file
reboot
Nach besagtem Neustart konnte ich nun wieder auf meinen AP via ‚https://ap4.tigges.local‘ zugreifen und hatte dank des neuen Zertifikats keine Fehlermeldung mehr:
asusapconfig5
WebGUI des RP-AC68U ohne Zertifikatsfehler
 Last not least: ich habe den Zugriff via Telnet abschließend wieder deaktiviert und ausschließlich den HTTPS-Zugang behalten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.