Schlagwort-Archive: Router

Empfehlung: externe RP-SMA-Antennen

Ich habe mit den mitgelieferten Antennen bei Access Points mit verschiedenen Herstellern sehr unterschiedliche (und oft schlechte) Erfahrungen gemacht.

RP-SMA Buchse

Da zum Glück die meisten Hersteller RP-SMA-Anschlüsse verbauen, habe ich mir folgende Antennen in größerer Stückzahl zugelegt und tausche sie nun regelmäßig gegen die ursprünglich mitgelieferten. Auch im Outdoor-Bereich habe ich damit seit zwei Wintern keine Probleme gehabt, obwohl die Antennen nur für indoor designed sind:

2,4 GHz und 5 GHz 8 dbi RP SMA Antenne

Die Modellbezeichnung ist bei Amazon Huacom HCM82. Eigentlich habe ich die Antenne ursprünglich auf Aliexpress gefunden und getestet. Sie ist quasi baugleich mit dem Modell, das auf Amazon angeboten wird, mittlerweile ist sie auf Aliexpress sogar teurer.

Die Antenne ist für 2,4 GHz und 5 GHz WLAN geeignet und verfügt über ein Gelenk, über das sie 45° oder 90° „geknickt“ werden kann.

Der Antennengewinn ist mit 8 dbi angegeben. Damit ist auch guter Empfang von weiter entfernten Stationen möglich.

Blick ins Innere: Antennendraht beim Gelenk

Übrigens: in Österreich (ich glaube überall in der EU) ist die maximal zulässige Leistung als e.i.r.p. definiert. EIRP bedeutet, dass die Leistung des Geräts zum Antennengewinn addiert werden muss und dann einen gewissen Wert nicht überschreiten darf. Wenn man jetzt eine stärkere Antenne montiert, sollte man darüber nachdenken, die Leistungsstufe des Geräts zu reduzieren um im gesetzlichen Rahmen zu bleiben.

speedtest.py für Ubiquiti EdgeRouter

Vor kurzem habe ich einen Beitrag über speedtest-cli verfasst, weil man damit Speedtests auf der Kommandozeile von Ubiquiti EdgeRoutern oder EdgePoints automatisieren kann.

Hinweis: im ursprünglichen Beitrag zu diesem Tool sind die Möglichkeiten genauer beschrieben. Ich empfehle, auch einen Blick dorthin zu riskieren.

Ich erstelle beispielsweise jeden Tag in der Früh einen Report über die Geschwindigkeiten auf meinen Funkfeuer-Standorten. Den Report erhalte ich per Email und kann daran die Performance der weit entfernten Standorte erkennen.

Seit kurzem ist speedtest-cli allerdings durch speedtest.py abgelöst worden. Das Tool speedtest.py wurde vom gleichen Developer entwickelt. Es erscheint beim Aufruf von speedtest-cli folgende Meldung:

The file speedtest_cli.py has been deprecated in favor of speedtest.py

Details zu speedtest.py sind weiterhin hier zu finden: https://github.com/sivel/speedtest-cli

Es kann über folgende Kommandos installiert werden (analog zur bisherigen Anleitung, aber natürlich von anderer Quelle):

curl -o /config/user-data/speedtest.py https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod u+x /config/user-data/speedtest.py

gestartet wird ein Test entsprechend über folgenden Aufruf:

/config/user-data/speedtest.py

Es gibt einige praktische Kommandozeilenoptionen, die haben sich durch das Update nicht verändert und habe ich im ursprünglichen Blogbeitrag ausführlicher vorgestellt.

Speedtest über Ubiquiti Edgerouter CLI

Ich betreibe mehrere Standorte, die im Wiener Funkfeuer-Netz verteilt sind. Mich interessiert die Performance (vor allem die Bandbreite vom bzw. zum Internet), die ja abhängig von Tages- oder Jahreszeit schwanken kann.

Update Dezember 2016: das Tool speedtest-cli ist durch speedtest.py, das vom gleichen Entwickler geschrieben wurde und die gleichen Möglichkeiten bietet, abgelöst worden. Die Installation ist daher abweichend. Ich habe die neue Vorgehensweise in einem neuen Beitrag erklärt. Die hier beschriebenen Optionen und Möglichkeit haben jedoch weiterhin Gültigkeit.

Bisherwar ich recht erfolgreich mit Bandbreite iPerf. Dazu benötige ich aber zwei Geräte, zwischen denen dann die Bandbreite gemessen wird – das ist die richtige Methode, wenn man zB. eine Funk-Verbindung zwischen zwei Geräten messen möchte. Aber wenn ich die Internet-Performance messen möchte, muss ich zwei Geräte bedienen.  Die Ergebnisse sind dafür belastbar, sind nachvollziehbar/plausibel und spiegeln die erlebte Performance wider.

Wenn ich vor Ort bin, nutze ich die Speedtest-App (hier der Link für iOS/iPhone/iPad) von Ookla Speedtest.net oder den RTR Netztest (auch für iOS/iPhone/iPad). Diese App gefällt mir in letzter Zeit sogar besser, weil auch viele andere Werte geprüft werden.

Für die Ubiquiti EdgeRouter oder Ubiquiti EdgePoints, die wir in letzter Zeit gerne einsetzen, gibt es da eine einfache Möglichkeit:

Installation: Speedtest für CLI

Heute haben mir Freunde ein Messergebnis geschickt, das eindeutig über die CLI gemessen wurde. Dabei ist mir die Idee gekommen, auch meine EdgeRouter (und EdgePoints, also die Outdoor-Variante) damit auszurüsten und in Zukunft selbst gemütlich über die CLI testen zu können. Also hab‘ ich mir das gleich angesehen:

Auf Github findet man das Python Script speedtest-cli: https://github.com/sivel/speedtest-cli

Man benötigt nur das .py-Script, das recht einfach am EdgeRouter heruntergeladen werden kann. Damit es auch nach einem Update des Routers verfügbar bleibt, speichere ich es in /config/user-data:

curl -o /config/user-data/speedtest_cli.py https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest_cli.py

(Weil wget im Standard-Image nicht installiert ist, verwende ich curl -o. Weil unzip nicht verfügbar ist, lade ich das .py-Script vom letzten master-Branch raw von github).

Danach markiere ich das Script als ausführbar:

chmod u+x /config/user-data/speedtest_cli.py

Und schon kann’s losgehen, ich starte einen Speedtest mittels:

/config/user-data/speedtest_cli.py

Das Ergebnis überzeugt mich:

speedtest_cli1

Optionen

Es gibt noch ein paar erwähnenswerte Optionen zu dem Tool. Vor allem –simple könnte zB. für Scripts interessant sein:

–simple zeigt nur den Output an: Ping/RTT, Download- & Uploadraten.

/config/user-data/speedtest_cli.py --simple

ergibt:

Ping: 26.968 ms
Download: 38.36 Mbit/s
Upload: 27.19 Mbit/s

speedtest_cli2–share liefert eine URL zurück, bei der das Ergebnis grafisch dargestellt wird:

–server SERVER-ID nutzt den Zielserver mit der entsprechenden ID. Diese kann man in der Liste aller verfügbaren Server finden, welche  mittels –list abgerufen wird

–secure nutzt https statt http für die Test

–version liefert die Versionsnummer zurück

Wieso wird mein/e … gehackt?

Ich werde das sehr oft gefragt, daher ist es mir einen Beitrag wert:
„Wieso wurde mein/e … gehackt? Was hat der/die Hacker/in davon? Es ist ja nur ein kleines Gerät im Internet!“

Vor allem aufgrund eines Vorfalls mit Antennen von Uniquiti, die Mitte Mai massenhaft gehackt wurden und mich dazu bewegt haben, einen Blogbeitag zu verfassen, der mittlerweile zu den Meistgelesenen auf dieser Webseite gehört, wurde ich das gefragt.

Die Antwort ist eigentlich ganz einfach, aber schwierig kurz und prägnant zu erklären.

Viele dieser „kleinen“ Geräte, die da gehackt werden – egal ob Antenne, Router, Smartphones oder andere – besitzen ein mächtiges Betriebssystem, und das kann dem Zweck des Hackers nutzen. Es geht also nicht darum, das Gerät vom Netz zu trennen oder die Funktion einzuschränken: es geht darum, Zugrif auf das Gerät zu erlangen und dieses künftig für eigene Zwecke (mit) zu nutzen.

Oft wird die ursprüngliche Funktion des Geräts gar nicht beeinträchtigt – sonst würden die Besitzer ja merken, dass sie gehackt wurden und danach streben, die schadhafte Software zu entfernen. Ist doch praktischer, wenn’s keiner merkt…

Die Geräte werden oft so umprogrammiert (bzw. wird zusätzlich Software installiert), sodass sie auf Arbeitsaufträge („Kommandos“) aus dem Internet horchen und diese dann ausführen. Sie sind dann an sogenannte „Command and Control“-Systeme/-Server angebunden.

Das klingt jetzt noch nicht mächtig, aber wenn man berücksichtigt, dass hunderttausende solcher Geräte, über die Welt verteilt, an so einem System teilhaben, wird klarer, welches Potenzial dadurch entsteht.

Dieses Thema wird sich meiner Einschätzung nach im Zukunft noch zuspitzen: es werden immer mehr Geräte werden ans Internet angebunden und diese werden auch immer leistungsfähiger. Dadurch eignen sie sich immer mehr für solche Aktionen… Man nennt das auch die Ära des Internet of Things (IoT), auf die wir uns rasant zubewegen.

Was kann man dagegen tun? Ein wesentlicher Tipp ist bestimmt, möglichst aktuelle Updates einzuspielen, die häufig Sicherheitslücken beheben, mit denen Angreifer überhaupt die Möglichkeiten bekommen, Zugang zum Gerät zu erlangen und Schadsoftware aufzuspielen. Ansonsten rate ich weiterhin dazu, bewusster zu überlegen, ob wirklich alle Geräte ans Internet angebunden sein müssen bzw. Zugriff darauf haben müssen. Reicht es nicht, wenn zB. Elemente einer Hausautomatisierung mit der Zentrale kommunizieren können? Muss denn jedes Gerät uneingeschränkt mit dem Internet Daten austauschen können?

Mich hat ein aktuelles Ereignis (auch hier sehr gut beschrieben) zu diesem Beitrag inspiriert, außerdem wird dieses Thema nun auch von den Medien verstärkt aufgegriffen und verstanden. In diesem Fall haben hunderttausende Geräte die Kapazität ihrer Internetanbindung genutzt, um die Anbindungen und Bandbreiten großer Webportale lahmzulegen. Das nennt man eine Distributed Denial of Service-Attacke.

OLSRd (RFC3626) EdgeRouter Installation

olsrd-pinguinDamit man Ubiquiti EdgeRouter und Ubiquiti EdgePoint-Geräte im Netz von Funkfeuer Wien als Router betreiben kann, ist es notwendig, einen dynamischen Routing Daemon zu installieren. Bei Funkfeuer Wien ist das aktuell OLSRd (Open Link State Routing Daemon in Version 1). Dieser erkennt über zB. Funkstrecken die Router an den Gegenstellen und tauscht IP-Adressdaten aus, damit man selbst erreichbar ist und auch das Internet oder andere Standorte erreichen kann. Dieser Routing Daemon funktioniert sowohl für IPv4 als auch IPv6. Nähere Informationen zur Funktionsweise von dynamischem bzw. adaptivem Routing findet man bei Wikipedia.

Installation

Um die Installation möglichst einfach zu gestalten, hat Christoph Lösch, ein engagierter Kollege von Funkfeuer Wien, einen Wizard erstellt. Dieser Wizard kann über das Webinterface der EdgeRouters installiert und konfiguriert werden und stellt alle benötigten Funktionen und Optionen zur Verfügung.

Zum Download steht der Wizard auf github bereit. Die jeweils aktuellste Version findet ihr hier:
https://github.com/vchrizz/ER-wizard-OLSRd_V1/releases/latest

Installiert wird der Wizard, indem man am EdgeRouter auf den Tab „Wizards“ klickt und danach das „+“ bei „Feature Wizards“ klickt. Dort kann man die Version hochladen, die man bei Github gefunden hat und als Namen zB. „OLSRd_V1“ vergeben. Unter diesem Namen scheint der Wizard dann auch auf.

Seit Version 1.3 (Update 3, u3 vom Oktober 2016) enthält der Wizard auch die olsrd-Pakete. Davor musste man diese separat hochladen, oder den Router online bringen, damit der Wizard die Pakete selbst vom Internet nachlädt.

olsrd-wizardNach der Installation sieht man beim „Package Status“ hoffentlich zwei „Success“-Meldungen: eine für den Routing Daemon selbst (olsrd) und eine für die Plugins (olsrd-plugins). Mit den Plugins ist es möglich, Informationen über das Routingprotokoll zB. per http abzurufen.

Sofern alles geklappt hat, kann man nun folgende Optionen anhaken:

  • Setup Script,
  • Enable OLSR daemon,
  • Run OLSR daemon (on boot, if enabled)
  • und das bzw. die Interface(s) wählen, bei denen OLSRd aktiv sein soll. Das sind in der Regel die Interfaces mit den öffentlichen IP-Adressen.
    Bitte aktiviert OLSRd nicht auf den privaten IPs, da diese sonst auch im Netz geroutet werden.

Die gleichen Optionen wählt man (bei Bedarf) auch für IPv6.

Danach klickt man auf „Restart OLSR daemon(s) on ‚Apply'“, damit die Änderungen auch vom Routingprozess übernommen werden und wählt „Apply“. Kurze Zeit später sollte der Router online sein.

olsrd-pluginÜberprüfen kann man das über die OLSRd Plugins, zB. httpinfo (wenn aktiviert) über die IP des Routers und Port 8080 für IPv4 oder Port 8081 für IPv6. Falls dort nichts antwortet, prüft bei den Einstellungen des Wizards, ob die entsprechenden Plugins auch aktiviert sind.

Setup Script

Im Zuge der Installation haben wir die Option „Setup Script“ aktiviert. Ich empfehle, das dauerhaft aktiviert zu lassen. Dadurch prüft der Wizard bei jedem Reboot, ob die olsrd-Pakete ordentlich installiert sind bzw. würde sie ggf. neu installieren. Das ist zum Beispiel bei einem Upgrade des Images des EdgeRouters nötig – der Wizard bleibt nach einem Upgrade erhalten, aber die olsrd-Pakete sind nicht mehr installiert; das erledigt das Setup-Script beim ersten Bootvorgang mit der neuen EdgeOS-Version.

Wizard updaten

Da Christoph und die Community fleißig neue Funktionen integrieren und ggf. auch neue Versionen von olsrd mit Bugfixes oder sicherheitsrelevante Updates erscheinen, könnte es sinnvoll sein, den Wizard zu aktualisieren und damit die Umgebung up-to-date zu halten.

Der Vorgang dafür ist sehr einfach: den Wizard mittels des Buttons „Delete From List“ ganz unten in den Wizard-Optionen entfernen und gleich darauf die neue Version installieren.

Modelle

Getestet habe ich den Wizard mit folgenden EdgeRoutern:

Der Wizard soll auch auf anderen EdgeRouter-Modellen funktionieren, da er die Plattform (mips vs. mipsel) selbstständig erkennt und korrekt installiert.

Mehr zu dem Thema

gibt es hier:

Lösungsvorschläge für den Ubiquiti AirOS AiRMAX Hack vom Mai 2016 im Netz von Funkfeuer Wien

airoslogin-motherAm 13. +14. Mai 2016 wurde eine Sicherheitslücke (vmtl. im Webserver) der Ubiquiti Airmax Antennen mit AirOS Software ausgenutzt. Die Gesamtzahl der Standorte ist von etwa 230 aktiven Knoten auf knapp mehr als 150 Nodes zurückgegangen, die  unmittelbar nach der Attacke noch online waren. Mittlerweile geht die Zahl zum Glück wieder nach oben.

Aus jetziger Sicht platziert der Hack einige Dateien unter /etc/persistent. Außerdem werden die Login-Daten überschrieben und SSH-Keys installiert, mit denen ein Hacker von außen weiterhin auf die Antenne zugreifen kann.

Sollten Spuren des Hacks auf einer Antenne auftauchen, ist es jedenfalls empfehlenswert, per TFTP ein Image neu zu laden und die Antenne neu zu konfigurieren. Die Vorschläge weiter unten in diesem Text sind eher als Sofortmaßnahme gedacht, um die Antennen rasch wieder online zu bekommen.

Auswirkungen / Festellen des Hacks

Ich habe zwei Auswirkungen des Problems auf meinen Antennen festgestellt:

  • Großteils sind die Antennen auf Werkseinstellungen zurückgesetzt und daher über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ erreichbar. Eine Veränderung an den Antennen konnte ich nicht feststellen, wodurch das Einspielen eines Backups bzw. eine Neukonfiguration das Problem rasch löst. Idealerweise flasht man die Antenne per TFTP neu. Leider muss man diese Schritte vmtl. vor Ort durchführen, also hinfahren…
  • ubnt-hackManche Antennen sind noch online, aber ich kann mich nicht mehr mit dem bekannten Passwort anmelden. Wenn die Antenne „erfolgreich“ gehackt ist, wurden Username + Passwort auf „mother“ und „fucker“ geändert. Mein „ubnt“-User hat nicht mehr funktioniert, obwohl er in der /etc/passwd noch enthalten ist. Seit dem Entfernen des Hacks funktioniert mein ubnt-User wieder normal. Das Passwort ändert man zur Sicherheit trotzdem.
    Im Verzeichnis /etc/persistent/ findet man außerdem mehrere Files als Hinweis auf den Hack. Diese Antenne ist somit vom Virus befallen und muss gesäubert werden!

Details zum Hack

Details findet ihr im Forum von Ubiquiti Networks. Aktuell beginnen auch erste Händler entsprechende Hinweise zu posten:

Lösungsstrategien

Zuerst muss man feststellen, ob sich die Antenne im Werkszustand befindet oder nicht. Wenn sie über 192.168.1.20 mit Username „ubnt“ und Passwort „ubnt“ per Webbrowser erreichbar ist, kann man wie gewohnt die Konfiguration durchführen bzw. ein Backup einspielen. Besser ist es, zur Sicherheit per TFTP neu zu flashen. Dann kann man wirklich davon ausgehen, dass kein Schadcode erhalten bleibt.

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http und https nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Entfernen des Virus

Falls die Antenne erreichbar ist, gehört unbedingt geprüft, ob der bisherige Login noch funktioniert. Wenn die Antenne gehackt wurde, muss man ab sofort mit den Daten des Hackers, Username „mother“ und Passwort „fucker“, einloggen.

Es gibt ein Removal Tool, das auf Java basiert, von Ubiquiti zum dem Problem: https://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/m-p/1563869

Alternativ gibt es auf Github ein Script, das aber auch den Standard-Port des Webserver auf 81 setzt: https://github.com/diegocanton/remove_ubnt_mf/

Update 16.5.2016: angeblich verbleiben ein paar ipks installiert, es ist somit ein Reset auf Werkseinstellungen (noch besser: per TFTP neu flashen) dem Entfernen/desinfect-Script zu bevorzugen, siehe auch: https://lists.funkfeuer.at/pipermail/wien/2016-May/012228.html

Update 17.5.2016: Ubiquiti stellt eine Android App – ein Virus Removal Tool – zur Verfügung: https://play.google.com/store/apps/details?id=virusfixer.ubnt.com.ubntvirusremoval

Ich habe mir erlaubt, das desinfect.sh-Script (Ausgangspunkt ist commit #c841d87) von Github zu übernehmen und einige Funktionen anzupassen, damit es für meine Zwecke passt.

Funktionsübersicht:

  • das Script wird lokal auf der Antenne über SSH ausgeführt.
  • das Script überprüft, ob die Antenne infiziert ist.
  • die infizierten/veränderten Files werden gelöscht
  • die Accounts für „mcad“, „mcuser“ und „mother“ in /etc/inittab und /etc/passwd werden gelöscht
  • die Änderungen werden persistent gespeichert
  • Prozesse des Hacks werden gekillt
  • wichtig: danach muss die Firewall (siehe unten) konfiguriert und rebootet werden!

Das angepasste Script findet ihr unten und zum Download hier:

#!/bin/sh
# This script removes the Ubiquiti AirOS hack
# Script is based on this work:
# https://github.com/diegocanton/remove_ubnt_mf
# Colaboration: Alexandre Jeronimo Correa - Onda Internet, PVi1 (Git user)
# modified 2016/05/16 by Stefan Schultheis
FILE=/etc/persistent/mf.tar

# Check virus
if [ -e "$FILE" ] ; then
    echo "Infected :("
    #Access folder
    cd /etc/persistent
    #Remove the virus
    rm mf.tar
    rm -Rf .mf
    rm -Rf mcuser
    rm rc.poststart
    rm rc.prestart
    #Remove mcuser in passwd - by Alexandre
    sed -ir '/mcad/ c ' /etc/inittab
    sed -ir '/mcuser/ c ' /etc/passwd
    sed -ir '/mother/ c ' /etc/passwd
    #Write new config
    cfgmtd -w -p /etc/
    #Kill process - by Alexandre
    kill -HUP `/bin/pidof init`
    kill -9 `/bin/pidof mcad`
    kill -9 `/bin/pidof init`
    kill -9 `/bin/pidof search`
    kill -9 `/bin/pidof mother`
    kill -9 `/bin/pidof sleep`
    echo "Clear Completed :)"
else
    echo "Clear :) No actions"
    exit
fi

Wichtig: zum Abschluss muss die Firewall konfiguriert werden, sodass Zugriffe über http, https und ssh nur von vertrauenswürdigen IP-Adressen möglich sind. Siehe dazu „Konfiguration der Firewall“.

Achtung bei Upgrade zu AirOS 5.6.5

Ubiquiti scheint ein Upgrade zu AirOS 5.6.5 zu empfehlen. Hier ist zu beachten, dass es

  1. keine Unterstützung für den Routing-Daemon OLSRd dort gibt,
  2. keine Custom Scripts (/etc/persistent/rc.*) mehr gibt! Dadurch kann die bestehende Funktion eingeschränkt sein!

Konfiguration der Firewall

Ich schalte mir nur einzelne IP-Adressen für den Zugriff auf die Webinterfaces frei, das mache ich mit folgenden iptables-Regeln. Hier werden künftig nur mehr Zugriffe aus 78.41.113.x und 78.41.113.y zugelassen (bitte eigene IPs einsetzen).

touch /etc/persistent/rc.poststart
echo "iptables -F" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.x -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -s 78.41.113.y -j ACCEPT" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 80 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
echo "iptables -A INPUT -p tcp -i lo --dport 443 -j DROP 2>/dev/null" >> /etc/persistent/rc.poststart
cfgmtd -w -p /etc/

Ich empfehle darüber nachzudenken, ob man nicht die Erreichbarkeit von SSH ebenfalls auf ein paar weniger IPs beschränken möchte.

Nach einem Reboot ist die Antenne nur mehr von den oben eingetragenen IPs erreichbar.

Aktivieren von radvd am Ubiquiti Edgerouter für IPv6 Prefix Delegation

Ich nutze immer noch gerne und erfolgreich den Ubiquiti Edgerouter X SFP als Router in meinem LAN.

Da ich über Funkfeuer ja auch IPv6 nutzen kann, möchte ich das nun in meinem LAN einrichten und offizielle IPv6-Adressen (ohne NAT) den Endgeräten zuweisen.

Die IPv6-Adressen an den Interfaces lassen sich ja problemlos über das Webinterface konfigurieren. Aber es gibt im Webinterface keine Möglichkeit zu stateless oder stateful IPv6-Adressvergabe (zB. über DHCPv6 oder radvd). Dazu muss man kurz über SSH einloggen und die Kommandos textbasiert eingeben.

Routing ist ja praktischerweise aufgedreht. Dass alles funktioniert, habe ich getestet, indem ich meinem PC eine IPv6-Adresse aus meinem LAN-Bereich statisch vergeben habe. Zugriff auf Webseiten über IPv6 hat sofort klaglos funktioniert.

Also habe ich mit diesen zwei Zeilen rasch radvd auf dem LAN-Interface (bei mir eth1) aktiviert:

configure
set interfaces ethernet eth1 ipv6 router-advert prefix ::/64
set interfaces ethernet eth1 ipv6 router-advert radvd-options "RDNSS 2001:4860:4860::8888 {};"
commit
save

…und schon bekommen Geräte (teilw. sogar ohne neu verbinden zu müssen) IPv6-Adressen vergeben und nutzen IPv6!

Testen kann man das schnell über einen Aufruf auf http://ip6.me – dort wird die IPv6-Adresse angezeigt, falls man über IPv6 hinsurft. Falls eine IPv4-Adresse aufscheint, funktioniert etwas mit dem IPv6 noch nicht und das Endgerät ist selbstständig zu IPv4 zurückgekehrt.

Mit dem Thema IPv6 Firewall sollte man sich noch auseinander setzen, falls man nicht möchte, dass intern plötzlich alles über öffentliche IPv6-Adressen erreichbar ist…
Einen Vorschlag dazu gibt es zB. hier: https://community.ubnt.com/t5/EdgeMAX/1-6-DHCPv6-PD-with-RDNSS-on-Telenet-in-Belgium/td-p/1100485 Dieses Beispiel hat bei mir einwandfrei funktioniert, um eingehende Verbindungen abzulehnen:

configure
set firewall ipv6-name WANv6_IN default-action drop
set firewall ipv6-name WANv6_IN description 'WAN inbound traffic forwarded to LAN'
set firewall ipv6-name WANv6_IN enable-default-log
set firewall ipv6-name WANv6_IN rule 10 action accept
set firewall ipv6-name WANv6_IN rule 10 description 'Allow established/related sessions'
set firewall ipv6-name WANv6_IN rule 10 state established enable
set firewall ipv6-name WANv6_IN rule 10 state related enable
set firewall ipv6-name WANv6_IN rule 20 action drop
set firewall ipv6-name WANv6_IN rule 20 description 'Drop invalid state'
set firewall ipv6-name WANv6_IN rule 20 state invalid enable
set firewall ipv6-name WANv6_IN rule 30 action accept
set firewall ipv6-name WANv6_IN rule 30 description 'Allow IPv6 icmp'
set firewall ipv6-name WANv6_IN rule 30 protocol ipv6-icmp

set firewall ipv6-name WANv6_LOCAL default-action drop
set firewall ipv6-name WANv6_LOCAL description 'WAN inbound traffic to the router'
set firewall ipv6-name WANv6_LOCAL enable-default-log
set firewall ipv6-name WANv6_LOCAL rule 10 action accept
set firewall ipv6-name WANv6_LOCAL rule 10 description 'Allow established/related sessions'
set firewall ipv6-name WANv6_LOCAL rule 10 state established enable
set firewall ipv6-name WANv6_LOCAL rule 10 state related enable
set firewall ipv6-name WANv6_LOCAL rule 20 action drop
set firewall ipv6-name WANv6_LOCAL rule 20 description 'Drop invalid state'
set firewall ipv6-name WANv6_LOCAL rule 20 state invalid enable
set firewall ipv6-name WANv6_LOCAL rule 30 action accept
set firewall ipv6-name WANv6_LOCAL rule 30 description 'Allow IPv6 icmp'
set firewall ipv6-name WANv6_LOCAL rule 30 protocol ipv6-icmp
set firewall ipv6-name WANv6_LOCAL rule 40 action accept
set firewall ipv6-name WANv6_LOCAL rule 40 description 'allow dhcpv6'
set firewall ipv6-name WANv6_LOCAL rule 40 destination port 546
set firewall ipv6-name WANv6_LOCAL rule 40 protocol udp
set firewall ipv6-name WANv6_LOCAL rule 40 source port 547
commit
save

Danach gehören die Einstellungen noch auf die Interfaces gebunden:

configure
set interfaces ethernet eth0 firewall in ipv6-name WANv6_IN
set interfaces ethernet eth0 firewall local ipv6-name WANv6_LOCAL
commit
save

Ein Test aus dem Internet (zB. Portscan vor dem Setzen der Regeln in Vergleich zu nachher) hat ergeben, dass die Ports nun von außen nicht angesprochen werden können.

Ubiquiti EdgeRouter X mit PPTP Server und lokaler Authentifizierung

Der Ubiquiti EdgeRouter X SFP sieht nach dem perfekten Gateway für meinen Funkfeuer-Zugang zu Hause aus!

Aufgrund der mipsel-Architektur und den debian-Images als Basis der EdgeRouter-Serie besteht die Möglichkeit, die mipsel-Pakete für olsrd und olsrd-plugins manuell nachzuinstallieren und somit das Routingprotokoll für Funkfeuer direkt mitlaufen zu lassen. Dies funktioniert wunderbar für IPv4 und IPv6!

Außerdem ist das Gerät als softwarebasierter 6-Port-Router (5 + 1 SFP) mit PoE-Unterstützung auf 5 Ports ideal für zu Hause und ich kann einzelne Antennen auch direkt mit Strom versorgen.

PPTP Server

Aber nun zu PPTP. Vorab: PPTP ist wohl das unsicherste VPN-Protokoll, das man wählen kann. Es ist aber auch das am einfachsten zu konfigurierende und bei Windows direkt konfigurierbar (= ohne etwas installieren zu müssen).

Bei den folgenden Schritten habe ich mich stark an diesem Youtube-Video orientiert: https://www.youtube.com/watch?v=XqFcPv2lfDI

Die Konfiguration erfolgt über die Kommandozeile, also per SSH oder indem man in der Weboberfläche (GUI) auf „CLI“ klickt.

configure
set vpn pptp remote-access authentication mode local
set vpn pptp remove-access authentication local-users username meinbenutzer passwort meinpasswort

Die letzte Zeile wiederholt man für alle Benutzer, denen man Zugang gewähren möchte.

set vpn pptp remote-access client-ip-pool start 192.168.1.81
set vpn pptp remote-access client-ip-pool stop 192.168.1.89
set vpn pptp remote-access outside-address 78.41.113.xxx
set vpn pptp remote-access dns-servers server-1 192.168.1.1
set vpn pptp remote-access dns-servers server-2 208.67.222.222

Einige Firewall-Regeln gehören noch gesetzt:

set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 description allow_PPTP
set firewall name WAN_LOCAL rule 30 destination port 1723
set firewall name WAN_LOCAL rule 30 log disable
set firewall name WAN_LOCAL rule 30 protocol tcp
set firewall name WAN_LOCAL rule 40 action accept
set firewall name WAN_LOCAL rule 40 description allow_PPTP_GRE
set firewall name WAN_LOCAL rule 40 log disable
set firewall name WAN_LOCAL rule 40 protocol GRE

Mit den folgenden Kommandos wird die Änderung aktiviert und gespeichert. Mein erster Test war danach sofort erfolgreich!

commit
save

Test mit Windows 7

Auf meinem Windows7-PC habe ich sofort ein VPN hinzugefügt:

  1. Systemsteuerung -> Netzwerk und Freigabecenter
  2. Neue Verbindung oder neues Netzwerk einrichten
  3. Verbindung mit dem Arbeitsplatz herstellen
  4. Die Internetverbindung (VPN) verwenden
  5. Internetadresse: meine externe IP bzw. Hostname des EdgeRouters
  6. Zielname: frei wählbar, zB. „PPTP EdgeRouter“
  7. Benutzername & Kennwort eingeben, so wie die Authentifizierungsinfo am EdgeRouter programmiert wurde; es muss keine Domäne angegeben werden.
  8. auf „Verbinden“ klicken. Fertig!

Ich war sofort verbunden. Als IP-Adresse habe ich eine IP aus dem konfigurierten Pool erhalten! Internetsurfen war möglich! Ich habe meine IP über http://ip4.me überprüft und dort scheint die externe IP des EdgeRouter auf. Ich bin also über das PPTP-VPN und den EdgeRouter im Internet!