GL.iNet AR750 Slate

Ich war schon eine geraume Zeit auf der Suche nach einem „Plaste-Router“ für einen sehr spezjellen UseCase: einen ReiseRouter.

Da ich mit Familie reise und die Anzahl an WiFi Devices mittlerweile, die der mitreisenden Personen übersteigt, stellt sich am Zielort immer wieder die gleiche Prozedur ein: alle Devices ins Urlaubs-WLan bringen. Wenn es ganz Übel wird, gibt es dort nicht mal solches. Mit einem gesteigerten Privacy/Security Anspruch, will man zudem ungern direkt in einem fremden Netzwerk hängen. Ein VPN muss her. Nun unterstützt nicht jedes Consumer Endgerät VPNs (Switch, EBook Reader usw)…

Lange Rede – Kurzer Sinn: Es werden folgende Features benötigt:

  • Ein eigenes WLAN bereitstellen (2.4GHz besser 5 GHz)
  • OpenVPN Tunnel
  • Uplink über jede mögliche Verbindungsart herstellen (vorhandenes WLAN/LAN, Tethering)

All das kann man mit diversen OpenWRT/LEDE geflashten Routern irgendwie hinbekommen. Aber meistens war da Gefrickel notwendig. Besonders, wenn man sich in ein WLAN einwählen wollte und gleichzeitig selber ein anderes WLAN als AP zur Verfügung stellen wollte. (Auf dem gleichen Band wohlgemerkt)

Mein kurzer Abstecher in die „alte ConsumerWelt“ via einer Netgear AirCard war echt abschreckend. Für mehr als ein LTE Modem taugt der Kram nicht (dafür aber, dank externer großer Antenne, gut). OS Updates – wozu? „Shippen and Forget“ ist hier die Devise.

Vor meinem letzten Urlaub habe ich mir „zum Testen“ den AR750 Slate von GL.iNet zugelegt. Das Gerät gibt es im Handel aktuell für um die 100€. Das ist erstmal eine Ansage. Damit spielt das Gerät preislich in der „Oberliga“ der Plasterouter Marke „eierlegende Wollmichsau“.

Die erste Überraschung gibt es beim Auspacken des Gerätes. Das Ding ist kleiner als ein RasperryPy und dennoch bietet es zwei schwenkbare Antennen, 3 RJ45 Ports (Gigabit Ethernet) und einen USB2 Port. Ein RJ45 Port dient fest als WAN Port, über die anderen Beiden kann man kabel-gebundene Geräte anschließen. Der USB Port kann wahlweise für eine Modem oder Tethering-Verbindung genutzt werden oder es kann ein USB Massenspeicher angeschlossen werden. Der interne Speicher (128MB) kann via MicroSD Karte erweitert werden. Die Stromversorgung läuft über ein USB Mini und kann von einem beliebigen USB Netzteil oder PC erfolgen.

Die zweite Überraschung erfolgt bei der Inbetriebnahme des Gerätes. Man wird von der vorgeschaltet UI gezwungen (!!!!!) eine „sicheres“ Passwort zu vergeben. Das ist man bei PlasteRoutern nicht unbedingt gewohnt. Man landet sofort in einer Übersicht wo man aus 4 Optionen wählen kann, wie man die Verbindung zum Internet herstellen möchte. Einen Klick (wirklich nur einen Klick) später hat man Internet (Wenn die Konfiguration am Zielort mitspielt, dazu gleich mehr).

Beim VPN hat man die Wahl zwischen OpenVPN und WireGuard. Unsichere und „sollte man nicht verwenden“ Protokolle und werden gar nicht erst angeboten. Beim VPN Setup hat man immer die Wahl zwischen Client und Server Mode. Die notwendige Config lädt man einfach hoch. Die meisten VPN Provider bieten die passenden personalisierten Configs an, bei privaten VPNs muss man sich Selbige schnell zusammenbasteln. Liegt die Config vor braucht es 5 Klicks bis das VPN steht. Zwei weitere Klicks und der Router blockiert jedweden Traffic, wenn kein VPN verbunden ist. Kurz: wenn alles gut läuft ist man in unter zwei Minuten mit dem Setup durch und muss sich den Rest des Urlaubs nicht mehr um den kleinen Kasten kümmern.

Ich hatte natürlich gleich beim ersten Einsatz den „SuperGau“. Mein HotelWLan nutzte die gleiche IP Range wie mein Heimnetz. Solche Fälle kann weder über die GL.iNet noch die LuCI-GUI abfangen. Hier war direkter SSH Zugang und „Policy Based Routing“ Gefrickel notwendig. 20 Minuten und einige Flüche später war aber auch das Problem umschifft. Das Gerät hat über die Dauer des Urlaubs keine Auffälligkeit gezeigt und einfach lautlos (und störungsfrei) seinen Dienst verrichtet.

Wenn man Meckern will, dann nur auf sehr hohen Niveau. Hier sind ein paar Punkte:

  • Für die WLans werden keine getrennten physikalischen Kanäle verwendet. Wählt man sich in ein WLAN ein, wird das eigene WLAN auch auf dessen Kanal bereitgestellt. Das ist dem Durchsatz nicht zuträglich.
  • Wird ein WLAN sowohl auf 2.4 GHz als auch auf 5 GHz angeboten, kann man von der GUI aus nicht das 5 GHz Band erzwingen. Dazu muss man in die LuCI oder gar via SSH nachhelfen.
  • Der Router wird als MediaCenter beworben. Ich formuliere es mal diplomatisch. Das ist nicht die Stärke des Gerätes. Via Micro SD Card kann man wohl nur 128 MB nachrüsten (nicht ausprobiert), da geht nicht viel „Media“ und über den USB2 Port geht nicht viel Durchsatz. RAW Bilder von der Kamera will man darüber nicht Sharen (und das habe ich ausprobiert!).
  • IPSec VPN muss man manuell installieren und konfigurieren. Eine direkte Verbindung zu einer FritzBox benötigt Handarbeit.
  • Die Firmware ist ein speziell gepatchtes OpenWRT und basiert auf der letzten „stable“ Version, ist also schon etwas älter und „gut abgehangen“. Will man ein „untouched“ oder gar „latest“ OpenWRT muss man sich die Kiste Patchen. Das geht ohne Probleme. Die 128MB Flash Speicher sollten für OpenWRT Builds eine Weile reichen und genügen Platz für Experimente bieten.

Fazit

So viel „Euphorie“ hatte ich bei Netzwerkgeräten schon lange nicht mehr. Eigentlich löst das nur Ubiquity bei mir aus. Anschließen, einrichten und „geht“. Man sucht noch Gründe rum zu basteln aber eigentlich tut alles. Der Router ist perfekt auf seinen Einsatzzweck ausgerichtet. Urlaubs-Resort betreten, WLAN Zugang einrichten, VPN verbinden und dann das Gerät vergessen und Urlaub machen. Wenn es mal doch einen Grund gibt zu basteln, hat man aber auch die komplette Bandbreite der Tools zur Verfügung.

Wenn zwei unterschiedliche Netzwerke die gleiche IP Range haben…

Vorweg: mit IPv6 wäre das nicht notwendig. IPv6 ist aber immer noch nicht flächendeckend ausgerollt (und wird es wohl zu meiner Lebenzeit auch nicht)

Wenn man sich via VPN aus einem beliebigen Netz in sein eigenes Netzwerk verbindet funktioniert das nur, wenn das Lokale Netz (aus dem man sich verbinden will) eine andere Netzmaske hat, als das Zielnetz, in das man sich verbinden will.

In meinem Fall Hotel-WLan-Gateway die gleiche Adresse wie eine meiner Server (auf dessen Service ich gerade zugreifen wollte).

Ich halte ja mittlerweile zwei unterschiedliche VPN Netzwerk Konfigurationen bereit, für den Fall, dass mein Gastnetzwerk den gleichen Addressraum nutzt, denn auch mein VPN hat. Für die Zieladressen konnte ich diesen Weg aber nicht gehen.

Das Problem kann man mit einem Router und „Policy Based Routing“ lösen.

Der Router wird mit dem zur Verfügung gestellten Gast Netz verbunden (IP Range A) und stellt selber ein Netzwerk (IP Range B) zur Verfügung. Der Router wählt sich nun in das VPN-Netzwerk ein (IP Range C). Das interne Netzwerk, dass durch das VPN erreicht werden soll, hat auch IP Range A.

Das Problem: wenn ein Client aus IP Range B versucht auf interne Ressourcen mit der IP Range A zuzugreifen, geht der Router nicht über das VPN, sondern auf den direkten Link, also ins GastNetz.

Die Lösung: man legt sich eine neue Routing Table an, die zwei Einträge hat:

Den Lokalen Link für das eigene Netzwerk (IP Range B)
eine Default Route über das VPN (IP Range C)

Das kann dann so aussehen

ip route add IP-RANGE-B dev LOCAL-DEV proto kernel scope link src LOCAL-IP table 200 
ip route add default via VPN-GW-IP dev VPN-DEV table 200

Anschließend muss man dem Router nur noch dazu Bringen, alles aus dem eigenen Netzwerk (IP Range B) über diese Tabelle zu routen. Das geht wie folgt:

ip rule add from IP-RANGE-B lookup 200

Wenn nun etwas aus dem eigenen Netzwerk (IP Range B) bearbeitet wird, kennt der Router das GastNetz (IP Range A) nicht.

Das ganze kann man auch ohne Router erreichen, also mit einem Client direkt im GastNetz (IP Range A) und einer OpenVPN Instanz am laufen. Dann werden die „ip rule“ Statements nur viel komplizierter.

Die Ansatz hier ist: Sämtlichen Traffic, der nicht von dem VPN erzeugt wird, über eine gesonderte RoutingTable zu bearbeiten und nur den VPN Traffic an das Default GW zu bekommen. Der Kniff ist „Sämtlichen Traffic, der nicht von dem VPN erzeugt wird“ korrekt zu erkennen. Möglichkeiten hier sind:

  • Alles was nicht an den Default GW gesendet wird
  • Alles was nicht von einem bestimmten User erzeugt wurde

Alles in allem hat man einfach ein bisschen mehr Aufwand.

Oder man sorgt mittels IPv6 einfach dafür, dass man keine zwei Netze mit gleicher IP Range hat…