Zu Tuningzwecken muss ab und zu auf /sys/block/dm-X zugreifen. Dazu muss man allerdings (bei mehreren DM- Block Devices) wissen, was hinter den einzelnen DM-Devices steckt.
Das kann man mittels folgenden Befehl rausbekommen.
dmsetup info /dev/dm-*
Zu Tuningzwecken muss ab und zu auf /sys/block/dm-X zugreifen. Dazu muss man allerdings (bei mehreren DM- Block Devices) wissen, was hinter den einzelnen DM-Devices steckt.
Das kann man mittels folgenden Befehl rausbekommen.
dmsetup info /dev/dm-*
Zuerst das Logische Volumen vergrößern
lvextend -l +100%FREE /dev/mapper/<logical-device>
Wenn cryptsetup/LUKS zum Einsatz kommt, muss man einmal das Device Unmounten und den Container schließen und wieder aufmachen.
Anschließend das Volume vergrößern. Bei XFS geht das nur online.
xfs_growfs <mountpunkt>
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:
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:
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.
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 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…