Externe Domainnamen im internen Netz verwenden

Dieser Blog-Eintrag beschreibt ein paar kleine Problem, die man haben kann, wenn man mit dem Handy oder Tablet auf die Inhalte eines Servers im lokalen Netzwerk zugreifen und dabei den externen Hostnamen verwenden will.

Wenn man ein Webserver zu hause hat, dann hat man für diesen in der Regel auch einen externen Hostnamen, damit dieser aus dem Internet über diesen Hostnamen erreichbar ist (z.B. meinserver.example.com). So kann man dann von unterwegs zum Beispiel auf OwnCloud, NextCloud, E-Mails oder was auch immer zugreifen. Dafür gibt es ja diverse Möglichkeiten, z.B. über DynDNS Service oder für Besitzer einer FritzBox über MyFritz. Wenn man zu hause ist (also im eignen LAN/WLAN) sollte dieser Zugriff natürlich auch einwandfrei funktionieren. Damit meine ich, dass man den Server auch intern über seinen Hostnamen erreicht und diese Verbindung ausschließlich über das interne Netz erfolgt. Das hat dann diverse Vorteile:

  • SSL-Zertifikate für verschlüsselte Verbindungen (z.B. von Let’s Encrypt), können auch im eigenen Netz verwendet werden. Diese Zertifikate sind für den externen Hostname ausgestellt, also z.B. meinserver.example.com. Würde man intern über einen anderen Hostnamen oder die lokale IP-Adresse zugreifen, würde der Browser eine Fehlermeldung wegen dem ungültigen Hostnamen anzeigen (Firefox: SSL_ERROR_BAD_CERT_DOMAIN).
  • Man braucht am Mobilgeräte keine zwei Konfigurationen für interne und externe Zugriffe, z.B. für Datei-Synchronisation oder automatische Backups.
  • Man kann Dienste nutzen, die nur im lokalen Netz zur Verfügung gestellt werden und die extern nicht erreichbar sein sollen (z.B. die Smart-Home-Steuerung).
  • Lokale Zugriffe sind deutlich schneller, dazu gleich mehr.

Mir sind dabei ein paar Probleme aufgefallen, deren Lösung ich hier kurz beschreiben möchte.

Das erste Problem ist mir bei OwnCloud aufgefallen. Über die App „FolderSync“ wollte ich von meinem Handy Backups auf OwnCoud sichern (über WebDav). Das war allerdings unglaublich langsam. Bei NextCloud war es das gleiche Problem. Auch andere Sync-Apps hatten das Problem. Wenn ich von meinem PC über WebDav Dateien auf OwnCloud oder NextCloud kopiert habe, war es schnell. Es musste also etwas mit der Verbindung von Handy zum Server zu tun haben. Die Logfiles vom Webserver haben mich dann auf die Ursache gebracht: Die Android-Geräte haben sich mit einer externen IP-Adresse zum Server verbunden. Wie kommt es dazu?

  1. Das Mobilgerät erhält seine IP-Adresse, Gateway und DNS-Server über DHCP vom Router (in meinem Fall eine Fritzbox). DNS-Server ist der Router.
  2. Beim Verbindungsaufbau zu meinserver.example.com fragt das Mobilgerät seinen DNS-Server (den Router) nach der IP-Adresse.
  3. Der Router kennt nur den internen Namen des Servers und fragt daher bei einem externen DNS-Servern nach.
  4. Dieser liefert die externe IP-Adresse zurück, die man momentan hat.
  5. Das Mobilgerät macht den Verbindungaufbau über die externe IP-Adresse. Damit verlässt sämtlicher Netzwerktraffic erst das lokale Netz, geht zum ersten Router des Providers und geht dann wieder zurück über den eigenen Router ins lokale Netz.

Ich musste also den Mobilgeräten irgendwie beibringen, dass der externe Hostname über die interne IP-Adresse viel schneller erreichbar ist als über die externe IP. Die einfachste Möglichkeit wäre eigentlich, wenn man den Hostname des Servers direkt am Router einstellen könnte. Dann könnte der die Frage nach der IP direkt beantworten. Zumindest die FritzBox kann das aber nicht, weil im Hostname keine Punkte erlaubt sind. Die Lösung war für mich DNSMASQ, ein kleiner DNS-Server, der am Server installiert wird und der die Frage nach seinem Hostname direkt mit seiner lokalen IP beantwortet (Testen unter Linux z.B. mit dig @meinserver meinserver.example.com, die Antwort sollte die lokale IP-Adresse sein, z.B. 192.168.0.2). Über die FritzBox kann man festlegen, dass alle Geräte, die ihre Netzwerkeinstellungen per DHCP erhalten, einen bestimmten DNS-Server nutzen sollen. Dort einfach die lokale IP-Adresse des Servers eintragen, auf dem DNSMASQ läuft (zweiter DNS-Server wird die FritzBox selbst).

Das zweite Problem hatte ich nach der Umstellung auf VDSL: Mit der neuen FritzBox 7560 hat das alles nicht mehr funktioniert, obwohl es noch so konfiguriert war, wie zuvor. Zumindest dachte ich das. Sämtliche Android-Mobilgeräte nutzten wieder die externe IP-Adresse. Mit den Apps „Ping & DNS“ und „DNS Debugger“ hab ich dann auch den Grund dafür gefunden: Über die neue FritzBox haben die Mobilgeräte IPv6-Netzwerkadressen erhalten und damit auch den eignen DNS-Server ignoriert. Die Lösung war in diesem Fall ganz einfach: IPv6 in der FritzBox abschalten und schon funktioniert es wieder wie zuvor.

Android: HTML-Datei von SD-Karte mit Chrome öffnen

Wenn man unter Android HTML-Dateien auf der SD-Karte hat, kann man diese über den Datei-Explorer nur in der HTML-Anzeige öffnen. Damit kann man aber nicht viel machen, z.B. keine anderen lokal verlinkten Dateien öffnen. Es gibt leider keine Möglichkeit, eine HTML-Datei direkt aus dem Explorer in Chrome zu öffnen, ohne eine App dafür zu installieren. Die App „Open in Browser“ kann das angeblich, ich hab das aber nicht getestet.

Es gibt aber eine einfache Möglichkeit, eine HTML-Datei in Chrome zu öffnen. Man muss nur die lokale URI wissen und einmal eingeben. Das kann man sich für später dann einfach als Lesezeichen speichern. Hier ein Beispiel: Wenn die Datei index.html auf der SD-Karte im Unter-Verzeichnis my_documents/test liegt (komplette URI: /storage/emulated/sdcard/my_documents/test/index.html), dann muss man folgendes in die Adresszeile von Chrome eingeben:

file:///sdcard/my_documents/test/index.html

Wichtig sind die drei „/“ hinter file:, wenn man hier (wie normalerweise üblich) nur zwei Slashes angibt, bekommt man die Meldung „Der Zugriff auf die Datei wurde verweigert“ (ERR_ACCESS_DENIED).

Ich nutze das für einige HTML-Dateien, die untereinander verlinkt sind und die regelmäßig mit FolderSync auf mein Mobiltelefon kopiert werden. Somit hab ich die Daten auch offline verfügbar. Und die Links von einer HTML-Datei zur nächsten funktionieren auch.

Getestet unter Android 7.1.1, vermutlich geht das mit früheren Versionen genauso.

Ubuntu 16.10: Größe der Icons am Desktop ändern

Mit dem Update von Ubuntu 16.04 auf 16.10 kommt auch eine neue Version des Dateimanagers Nautilus. Bei mir hatte das unter anderem die Folge, dass die Symbole am Desktop („Ubuntu Schreibtisch“) sehr groß dargestellt wurden. Direkt in den Einstellungen vom Nautilus habe ich nichts gefunden wie man die Icons wieder verkleinern kann. Die Icon-Größe in Nautilus konnte ich einstellen, aber das hatte keine Auswirkungen auf den Desktop.

Die Lösung war das kleine Hilfsprogramm dconf-editor (über Unity Dash oder einfach im Terminal starten). Auf der linken Seite öffnet man folgenden Pfad: org / gnome / nautilus / icon-view und dort stellt man den "default-zoom-level" auf "small". Wie der Name schon sagt, hat das auch Auswirkungen auf die Icon-Größe in der Symbolansicht von Nautilus. Mich stört das nicht, da ich fast ausschließlich die Listen-Ansicht verwende. Und außerdem bevorzuge ich den Dateimanager Nemo (so ähnlich wie Nautilus, nur besser), auf den hat diese Einstellung keine Auswirkung.

Screenshot dconf-editor
Screenshot dconf-editor

Dampflok 52 8195-1 auf der Brücke bei Mariaort

Am 9. Juli 2016 war ein Sonderzug der Fränkischen Museums-Eisenbahn in Regensburg. Vormittags hab ich die Lok zu spät gehört, da war sie schon wieder weg zum Wasser auffüllen. Aber die Rückfahrt nach Nürnberg am Abend hat ganz gut zu meiner geplanten Radtour gepasst. So hab ich die Lok dieses Mal in Fahrtrichtung Nürnberg auf der Eisenbahnbrücke bei Mariaort fotografieren können. Dabei hab ich auch noch den Youtube-Eisenbahnfilmer ICE 91 Prinz Eugen getroffen, der das in seinen Monatsrückblick eingebaut hat (Viele Grüße zurück!).

Full filesystem without content?

Since a few days I had a problem on my Ubuntu machine that I use at home: After logging in, the system showed a warning, that /tmp was nearly full. Checking it with df -h showed that over 95% of 10 gigabyte were used. But sudo du -hs /tmp/ showed that only 5 megabyte were used by files. /tmp has it’s own partition and uses the XFS filesystem. On askubuntu.com and serverfault.com I found some promising problem descriptions and possible solutions, but none of them fit for me. Finally xfs_repair solved the problem. For this you need to unmount /tmp, so I did this:

  • Edit /etc/fstab so that the tmp-partition will not be mounted on next boot (put „#“ at the beginning of the line that mounts /tmp)
  • Reboot, /tmp is now part of the root filesystem /.
  • Call sudo xfs_repair /dev/sdxY (replace sdxY by whatever your tmp-partition is).
  • Mount the partition somewhere temporarily (for example /mnt/tmp) and check with df -h if this solved the problem.
  • Edit /etc/fstab again to reactivate the tmp-partition. Then reboot and check again.

Schnellzugdampflok 18 201 in Regensburg

Heute war die schnellste, betriebsfähige Dampflok der Welt in Regensburg: Die Lok mit der Nummer 18 201 war bei einer Sonderfahrt im Rahmen der Hof-Plauener Dampftage morgens in Hof gestartet, Ziel war Regensburg. Ich hab nur zufällig das Pfeifen der Lok gehört, als ich gerade zum Bäcker radeln wollte. Also kein Frühstück, Kamera gepackt und ab zum Bahnhof. Hier ein paar Bilder.

Isole Eolie: Stromboli, Lipari und Vulcano

2011 hat es mir auf den Äolischen Inseln so gut gefallen, dass ich im Juni 2012 gleich nochmal hin geflogen bin. Dieses Mal zusammen mit meinem Vater, der schon seit Jahren mal auf die Vulkaninseln wollte. Die Reise-Route war etwas anders als 2010, wir haben gleich mit Stromboli angefangen: Der Flug ging von München nach Catania, per Shuttle-Service sind wir nach Milazzo und per Schiff direkt auf die Insel Stromboli. Dort waren wir für drei volle Tage, danach noch zwei Tage Lipari und ein Tag Vulcano. Das Wetter war wunderbar, auf Stromboli waren wir meistens tagsüber am Strand und ab dem späten Nachmittag am Vulkan: Einmal mit einer Tour zum Gipfel und sonst an verschiedenen Aussichtspunkten an der Sciara del Fuoco. Es geht doch nichts über ein italienisches Picknick mit Blick auf einen aktiven Vulkan. Und am nächsten Tag zum Frühstück die hervorragende Zitronenmarmelade in der Albergo Brasile. Isole Eolie: Stromboli, Lipari und Vulcano weiterlesen

Funksteckdosen von REV Ritter über 433MHz schalten

Heute habe ich versucht eine paar Funksteckdosen von REV Ritter mit einem 433MHz Sendermodul (FS1000A) und einem Banana Pi zu schalten. Mit einem Raspberry Pi sollte es genauso funktionieren. Die Steckdosen mit der Artikelnummer 00834514 gibt es für ca. 15 Euro in Baumärkten oder bei Amazon (3 Steckdosen und eine Fernbedienung). Im Gegensatz zu meinen anderen Funksteckdosen von Mumbi (m-AFS102) kann man bei den REV-Steckdosen die Funk-Kennung nicht selbst einstellen. Man muss also zuerst mal ermitteln, welche Daten die Fernbedienung sendet. Dazu habe ich das Empfängermodul (XY-MK-5V) angeschlossen (VCC auf Pin 1, GND auf Pin 6, DATA auf Pin 12), die Software pilight nach dieser Anleitung installiert und den Service mit service pilight start gestartet. Dann einfach pilight-receive aufrufen, auf eine Taste der Fernbedienung drücken und die Ausgaben prüfen. Bei mir sah das ungefähr so aus:


{
"message": {
"id": 12345678,
"unit": 15,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch",
"uuid": "0000-01-23-45-1234ab",
"repeats": 2
}

Der gleiche Message-Block wurde mehrmals wiederholt, abwechselnd mit den Protokollen arctech_switch und arctech_contact. Zum Senden hab ich das Empfänger-Modul entfernt und das Sender-Modul angeschlossen (VCC auf Pin 1, GND auf Pin 6, DATA auf Pin 11). Jetzt musste ich nur noch das passende Protokoll finden, denn pilight-send hat kein offensichtlich passendes Protokoll angeboten. Funktioniert hat es dann mit dem Protokoll kaku_screen. Mit folgendem Befehl konnte ich dann die Steckdosen schalten:


# An
pilight-send -p kaku_screen -u 15 -i 12345678 -t
# Aus
pilight-send -p kaku_screen -u 15 -i 12345678 -f