Ich habe einen Raspberry Pi mit Kodi vor Ort und ein entferntes NAS, von dem ich Multimedia Daten auf den Kodi streamen wollte. Jetzt wollte ich keine Löcher in die Firewall des entfernten NAS schießen und auch keinen Wireguard VPN Server darauf installieren. Ich habe aus Sicherheitsgründen lediglich die SSH bzw. SFTP Möglichkeit zur Verfügung, um mit dem NAS zu kommunizieren. Aus Sicherheitsgründen ist aber die Verbindung mit Passwort auf dem NAS nicht erlaubt (stattdessen nur SSH Keys) und damit kann ich mit Kodi nicht über die “Remote Shares” der Kodi GUI auf das NAS zugreifen. Die gehen nämlich nur mit Passwort.

Ich habe versucht über einen Local SSH Tunnel auf das NAS zu kommen, um darüber eine Datenverbindung aufzubauen. Da mein Versuch am Ende erfolgreich war, möchte ich die Lösung hier teilen:

Erst mal muss man sich für die Konfiguration mit root@<hostname> auf dem Kodi im lokalen Netzwerk anmelden. Dann findet man unter /storage/.config/autostart.sh eine Datei, in der man Befehle eintragen kann, die Kodi beim Start ausführt. Also der perfekte Ort um eine SSH Verbindung zum NAS beim Start des Kodi aufzubauen. Das mache ich mit dem Befehl ssh <user>@<adresse> -i <IdentityFile> (anlegen, wenn nicht vorhanden) -p <port> -f (background) -T (kein Terminalemulator) -L 5005:localhost:5005 sleep 14d

sleep 14d hält die Remote Verbindung für 14 Tage offen. Ohne dieses Kommando würde sich die SSH Verbindung sofort wieder schließen.

Mit diesem Befehl baue ich eine Verbindung zum WebDAV Dienst auf dem NAS auf, ohne SSL Verschlüsselung, weil alles lokal.

Um schließlich auf die Daten auf dem NAS mit Kodi zugreifen zu können, muss ich in Kodi noch ein neues Network-Share hinzufügen. Als Dienst gebe ich natürlich WebDAV an und nutze meine normalen Zugangsdaten. Allerdings mit der Adresse localhost bzw. 127.0.0.1 und Port 5005.

Die Daten fließen nun durch den verschlüsselten Tunnel zum Kodi.

Ports blockiert, wie umgehen

Ich war neulich auf Reisen und bekam eine LTE Verbindung mit Volumenbegrenzung von 10GB spendiert. Problem war, dass ich von einer Flatrate ausgegangen war. Nun hatte ich darauf verzichtet vorher alle für die Arbeit benötigten Daten auf lokale Speichermedien zu kopieren, da ich dachte, dass ich ja auch später noch alles was fehlt nachträglich über das Netz laden kann. Doch wenn man sich seine 10GB doch einteilen muss, sucht man nach anderen Internet-Quellen. Die nächste Flatratequelle war in diesem Fall ein kostenloses Gastnetzwerk in der Nähe. Auf diesem Gastnetzwerk waren nicht viele Ports offen: 80, 443, 25, 143, 993, 995, 8080, um den Großteil zu nennen. Alle Ports die ich für eine Downloadverbindung zum Server brauchte, waren verschlossen und da meine OpenVPN Verbindung auf UDP 1194 eingestellt war, kam ich damit auch nicht weiter.

SSH Port Weiterleitung am Router

Welche Ports blockiert werden, kann man ganz einfach mit curl portquiz.net:993 herausfinden. Wobei 993 der Port ist, den man testen will. Die Seite portquiz.net bietet auch noch andere Testvarianten.

Zum Hauptproblem fand ich mehrere Lösungswege. Der erste schien mir am schnellsten. Wollte ich doch zu erst meine SSH Verbindung wieder nutzen, ohne den Port vom SSH Client zu ändern. Ich hatte zwar schon eine Portweiterleitung eingerichtet, aber die benutzte einen Port, der ebenfalls blockiert wurde.
Die Portweiterleitung ändere ich eigentlich am einfachsten mit dem Webinterface meines entfernten Routers, der die Zugänge zu meinem Server hinter dem Router regelt. Dort leite ich einfach einen im Gastnetzwerk freien Port (bspw. 993) auf meinen SSH Client um.
Das funktionierte leider nicht sofort und ich habe erst später gemerkt, woran es lag. Ich hatte in meiner Portweiterleitung mehrere Weiterleitungen angelegt, die alle auf den gleichen Port zeigten. Doch es fand weiterhin nur eine Weiterleitung über meinen alten Port statt, nie über die neu angelegten. Und der alte war nach wie vor im Gastnetzwerk gesperrt. Nach langem Rumprobieren kam ich drauf, dass ich die Portweiterleitungen, die ich für den Zielport 22 angelegt hatte, ein mal alle komplett abschalten musste, abspeichern und dann auf dem neuen Port wieder aktivieren musste. Dann übernimmt er die neue Weiterleitung. Doch darauf war ich erst ganz am Schluss gekommen. Denn vorher habe ich meine OpenVPN Verbindung auf TCP 443 eingestellt.

Open VPN auf https-Standardport 443 einstellen

Mit dem Umstellen von UDP Port 1194 auf TCP 443 habe ich eine sichere Fallback Lösung für alle Fälle, denn 443 müsste immer und überall offen sein und mit der VPN Lösung sollte ich immer alles über das Netzwerk bekommen, was ich brauche. Was ist eigentlich besser: OpenVPN via UDP oder TCP? (engl)

SSH Tunnel mit lokaler Portweiterleitung

Die dritte und und interessanteste Lösung war der SSH Tunnel, den ich ausprobieren musste, um ihn wirklich zu verstehen.
Angenommen ich erreiche meinen SSH Client neuerdings über Port 25, gebe ich im Terminal folgendes ein
sudo ssh -p 25 user@sshclient.de -L 8080:meinserver.de:5006 -N
macOS wollte sudo, weil Privileged ports can only be forwarded by root.
Ich verbinde mich also zuerst mit -p Port 25 auf meinen SSH Client.
Warum noch mal 25? Ist beispielhaft für einen Port im Gastnetzwerk, der nicht gesperrt ist, so dass nun der angerufene Router den Verkehr von 25 auf 22 weiterleiten kann.
Jetzt steht schon mal eine SSH Verbindung im blockierten Gastnetzwerk.
Wenn ich jetzt mit dem Browser auf das unerreichbare Webinterface meines Servers kommen möchte brauche ich noch -L offenerPort:angerufenerServer:geblockterPort.
Mit -L leite ich alle „local“ Anfragen, auf den im Gastnetzwerk freien Port 8080, über die etablierte SSH Verbindung. Mein verbundener SSH Client erzeugt einen Tunnel auf dem offenen Port 8080 und holt darüber die Pakete von dem im Gastnetzwerk unerreichbaren Port 5006 aus meinem Server.
Das -N weist SSH an, keine Befehle zu erwarten, das heißt, SSH stellt keine Eingabeaufforderung her, sondern ist im Horch-Modus.

Um die Adresse, die ich normalerweise mit https://meinserver.de:5006 aufrufen würde, zu erreichen, gebe ich jetzt im Browser https://localhost:8080 ein. Dann kann ich über den Port 8080 in den Tunnel meiner SSH Verbindung steigen und komme am anderen Ende auf meinem Server mit dem Port 5006 raus.

Mit diesen drei Lösungsmöglichkeiten ist man wirklich gut ausgestattet, um seine Daten in blockierten Umgebungen zu erreichen.

Ein Problem gibt es aber noch, nämlich wenn man im Browser über einen Nicht-Standard-Port in den Tunnel möchte. Wenn man, wie ich, über Port 993 seine getunnelte Seite ansurfen will, gibt es bei allen Browsern eine Fehlermeldung, bspw. Firefox Fehler: Port aus Sicherheitsgründen blockiert.

Um den Fehler zu beheben gibt man in die Firefox Adresszeile about:config ein und sucht oder erstellt den Eintrag network.security.ports.banned.override. Als Wert wird der Port eingetragen bspw. 993.

• Testet blockierte Ports
• SSH Port Weiterleitung (engl)
• SSH Weiterleitung einfach (engl)
• Umfangreiche Liste aller Ports
• In Firefox über Nicht-Standard-Ports surfen