Lokalen Linux-Server aus dem Internet erreichbar machen

Hinweis und Vorwort

Wieso schreibe ich den Artikel?

Es gibt einige Methoden um Dienste, die im lokalen Netzwerk bereitgestellt werden, im Internet erreichbar zu machen. Damals ließ man sich von seinem Internet Service Provider eine statische IPv4-Adresse zuweisen. Mittlerweile ist diese Option, aufgrund der IPv4-Knappheit, nicht mehr ohne weiteres möglich oder exorbitant teuer. Daher entwickelten sich im Laufe der Zeit neue Möglichkeiten, wie DynDNS-Dienste, die leider Schwierigkeiten haben, wenn man hinter einem sogenannten "Carrier-grade NAT"-Anschluss sitzt. Auch im Bereich von IPv6 gibt es die Möglichkeit über Tunnelmechanismen an den lokalen Dienst ranzukommen. Allerdings ist noch nicht jeder via IPv6 ans Internet angeschlossen.

An dieser Stelle aber Schluss mit den Fachbegriffen. Ich schreibe diesen Artikel um eine Möglichkeit zu erläutern, wie es auf jeden Fall Möglich ist das oben genannte Ziel zu erreichen. Diese Methode hat für mich persönlich am schnellsten und einfachsten funktioniert. Das ganze läuft bei mir seit längerer Zeit sehr stabil.

Warnung!

Im folgenden werde ich erklären, wie ihr einen Linux-Server, der in eurem Heimnetzwerk läuft, im Internet erreichbar macht. Ich weise im Voraus darauf hin, dass diese Methode nicht Vergleichbar mit einem VPN ist. Jeder der die IP-Adresse oder den DNS-Namen des Servers kennt, kann auf eure Serverinstanzen zugreifen. Achtet also bitte darauf, dass alle Server ausreichend durch Passwortschutz und Verschlüsselung gesichert sind.

Wenn ihr nicht genau einschätzen könnt, ob diese Methode für euch persönlich Sicher genug ist, dann lasst lieber die Finger davon.

An wen richtet sich der Artikel

Der Artikel richtet sich an alle, die Probleme haben die lokalen Dienste im Internet verfügbar zu machen. Vor allem zeige ich hier eine Alternative zu den Methoden, die häufig im Internet erklärt werden, aber nicht bei jedem Benutzer zwingen funktionieren können / müssen.

Ich werde zwar versuchen, dass alles so verständlich wie Möglich ist, dennoch ist es von Vorteil, wenn die Materie der Netzwerktechnik nicht ganz fremd ist. Im Folgenden werde ich oft das SSH-Protokoll im Einsatz haben. Außerdem ist es von großem Vorteil zu wissen, was IP-Adressen und Ports sind. Ebenfalls Nennenswert ist die grobe Funktionsweise von Public Key Verfahren.

Vorbereitung

Erläuterung zum Vorhaben

Um unsere Dienste im lokalen Netzwerk erreichbar zu machen, nutzen wir das SSH-Protokoll. In den meisten Fällen wird SSH genutzt um eine verschlüsselte Verbindung zu einem entfernten Server aufzubauen, um z.B die Kommandozeile zu nutzen. SSH ist allerdings ein gewaltiges Tool und bietet noch viel mehr Möglichkeiten, wie zum Beispiel den Aufbau eines Tunnels zwischen zwei Systemen.

Ein Tunnel beschreibt die Funktion, dass alle Anfragen von System A an System B weitergeleitet werden. Das erste System stellt die Dienste bereit. Das ist in unserem Fall ein Linux-Server im lokalen Netzwerk (z.B eine Nextcloud). Das andere System leitet die Anfragen lediglich weiter. Was wir machen werden ist folgendes:

Wir mieten einen Server im Internet. Dieser Server ist über eine IP-Adresse im Internet erreichbar. Der lokale Server und der Server im Internet bauen einen SSH-Tunnel auf. Alle Anfragen, die der Server im Internet erhält, werden über den Tunnel an den Server in eurem lokalen Netzwerk weitergeleitet.

Wieso wir das auf diesem Weg machen ist recht simpel. Wie bereits erwähnt, ist es nicht mehr so einfach einen Dienst im lokalen Netzwerk über eine IP-Adresse anzusprechen , die im Internet erreichbar ist. Deshalb gehen wir den Umweg über einen Server im Internet, der eine ansprechbare (routbare) IP-Adresse hat und die Anfragen 1:1 an den lokalen Server umleitet.

Beispiel:

Auf einem Raspberry Pi läuft ein Nextcloud-Server unter Port 80. Von diesem Raspberry Pi aus, wird ein Tunnel zu dem Server im Internet aufgebaut. Der Raspberry Pi ist nicht direkt ansprechbar, weil er keine IP-Adresse hat, die im Internet bekannt ist. Aber da alle Anfragen die an den Server im Internet gehen, an den Raspberry Pi weiterleitet werden, erscheint meine Nextcloud-Instanz, wenn ich den Internet-Server auf Port 80 anspreche.

Kosten

Sicher habt ihr euch schon gedacht, dass das ganze leider nicht ohne monatliche Kosten funktioniert, da ihr einen Server im Internet mieten müsst.

Die kosten sind aber nicht extrem hoch. Ich habe einen virtuellen Server gemietet. Dieser vServer kosten 1-5 Euro im Monat je nachdem wie viel Leistung ihr benötigt.
Da ihr aber für diesen Zweck nur einen SSH-Dienst laufen habt, reicht ein ganz kleiner vServer.

Daten der Beispiel Server

Im Folgenden werde ich mit Hostnamen arbeiten und nicht mit IP-Adressen.

vServer:

Name: makesmart.net

Nutzer: root und vServer_user

lokaler Server:

Name: nextcloud

Nutzer: root und nextcloud_user

Durchführung

Konfiguration und Vorbereitung

Wir werden während der Einrichtung des Tunnels das ein oder andere mal zwischen den Servern hin und her wechseln müssen. Achtet also genau darauf, um welchen Server es sich gerade im Artikel handelt.

Als erstes müssen wir uns auf dem vServer aufschalten und einige Konfigurationen an dem SSH-Service vornehmen. Standardmäßig ist nicht erlaubt, dass Remote-Hosts, also quasi Benutzer außerhalb das lokalen Servers, den Tunnel bzw. die freigegebenen Ports, nutzen dürfen. Da wir aber jederzeit, von jeder Stelle aus über das Internet auf den Tunnel zugreifen wollen, müssen wir diese Option erst aktivieren. Außerdem wird 60 Sekunden nachdem der Server keine Informationen mehr vom Client erhalten hat, ein Paket an den Client gesendet, um die Verbindung am Leben zu erhalten. Wenn nach dem zweiten Versuch keine Antwort vom Client kommt, dann wird der Tunnel abgebaut und die Verbindung getrennt.

Öffnet dazu die Konfigurationsdatei: sudo nano /etc/ssh/sshd_config
Und tragt folgendes am Ende der Datei ein (oder kommentiert die vorhandenen Default-Werte aus und ändert den Wert) :

Speichert die Konfigurationsdatei ab und startet den SSH-Dienst neu: sudo systemctl restart ssh.service

Nun kümmern wir uns um einige Dinge auf dem lokalen Server. Damit wir nicht bei jedem Tunnelaufbau ein Passwort eingeben müssen, werden wir ein Schlüsselpaar generieren. Durch die Generierung eines Schlüsselpaares ist es möglich eine SSH-Verbindung aufzubauen, ohne ein Passwort eingeben zu müssen.

Dazu generieren wir auf dem lokalen Server erst einmal ein solches Schlüsselpaar: ssh-keygen -t rsa -b 4096

Der private Schlüssel des lokalen Servers bleibt immer geheim und sollte niemals gezeigt oder weitergegeben werden.
Der öffentliche Schlüssel, wird dem vServer im Internet jedoch bei einem Login-Versuch präsentiert. Wenn der vServer den öffentlichen Schlüssel des lokalen Servers kennt, dann darf dieser sich am System anmelden. Damit ein Abgleich möglich ist und der Server auch weiß, welche Schlüssel vertrauenswürdig sind, muss der eben generierte öffentliche Schlüssel in einer Datei auf dem vServer eingetragen werden.

Lasst euch daher also erst Mal den gerade generierten Schlüssel auf dem lokalen Server anzeigen: cat ~/.ssh/id_rsa.pub

Öffnet dann auf dem vServer folgende Datei: sudo nano /root/.ssh/authorized_keys
Tragt den langen Schlüssel, der euch auf dem lokalen Server angezeigt wird, in die Datei auf dem vServer ein, speichert die Datei und startet den SSH-Dienst neu.

Jetzt könnt ihr versuchen euch vom lokalen Server aus ohne Passwort, mit den vServer zu verbinden.
Benutzt dazu folgenden Befehl: ssh vServer_user@makesmart.net

Wenn der SSH-Dienst über einen anderen Port erreichbar ist, dann setzt ein -p [port] hinter den Befehl.

Wichtiger Hinweise:

Der SSH-Befehl auf dem lokalen Server muss als der Benutzer ausgeführt werden, der auch das SSH-Schlüsselpaar generiert hat. Wenn ihr euch den generierten Schlüssel genau anseht, dann seht ihr am Ende, dass der Hostname und der Benutzername des Quellsystems enthalten ist. Der Benutzer der in diesem Schlüssel steht muss die SSH-Verbindung aufbauen, da sonst wieder ein Passwort abgefragt wird. Wenn ich also stattdessen den Befehl mit sudo ssh vServer_user@makesmart.net als root-Benutzer ausführe, wird ein Passwort abgefragt, da der root-Benutzer keinen öffentlichen Schlüssel generiert hat, den der vServer kennt.

Wenn die Verbindung geklappt hat, dann können wir unseren ersten Tunnel aufbauen. Im folgenden wird viel über Ports gesprochen. Jedem sollte klar sein, dass ein Dienst, der in einem Netzwerk bereitgestellt wird, meistens einen Port zugewiesen bekommt.

Beispiele zum Tunnelaufbau

Auf unserem lokalen Server läuft also eine Nextcloud-Instanz unter Port 80. Diese Instanz soll ebenfalls unter dem Port 80 aus dem Internet erreichbar sein:

ssh -p 22 -N -R 80:localhost:80 root@makesmart.net

Die Option -N des Commands bedeutet, dass kein Befehl auf dem vServer ausgeführt werden soll. Die Option -R baut den eigentlichen Tunnel auf.

Nun möchte ich meine Nextcloud-Instanz zwar über das Internet erreichen, aber nicht über den Port 80, sondern über den Port 1234:

ssh -p 22 -N -R 1234:localhost:80 root@makesmart.net
Die Linke Port-Angabe ist der Port, der auf dem vServer zur Weiterleitung bereitgestellt wird. Der rechte Port ist der Port, an dem auf dem lokalen Server weitergeleitet werden soll.

Um nachzuschauen, ob der Tunnel richtig aufgebaut wurde, könnt ihr auf dem vServer den Befehl watch -n 0.5 "netstat -tulpn" eingeben. Jetzt seht ihr alle geöffneten Ports, die aus dem Internet erreichbar sind.

Tipps

Ihr könnt den Prozess des Tunnelaufbaus noch ein bisschen vereinfachen indem ihr autossh auf eurem Sytem instaliert:

sudo apt install autossh

Autossh ist eine Software, die sehr viele Prozesse in Verbindung mit dem SSH-Service automatisieren, vereinfachen und kontrollieren kann.

autossh -M 0 -f -o ConnectTimeout=10 -o ServerAliveInterval=60 -o ServerAliveCountMax=2 -p 22 -N -R 80:localhost:80 vServer_user@makesmart.net

Ich werde die Optionen nur grob erläutern, da diese teilweise sehr ins Detail gehen.

"-M 0" , bedeutet, dass der sogenannte Monitoring-Port abgeschaltet wird.

"- f" schickt den Befehl in den Hintergrund, so das ihr weiterhin im Terminal arbeiten könnt, ohne die Verbindung abzubrechen.

"- o" weist auf eine Option hin, die im normalen SSH-Service integriert ist (also Befehle die nicht unbedingt autossh spezifisch sind)
"ConnectTimeOut" sorgt dafür, dass der normale TCP-Timeout in dieser Verbindung ignoriert wird.
"ServerAliveInterval=60" und "ServerAliveCountMax" sind die Gegenstücke der beiden Optionen die wir auf den vServer konfiguriert haben.

Wenn ihr die Verbindung automatisch beim Start des Systems aufbauen wollt, dann öffnet die crontab und schreibt folgendes hinein:
@reboot autossh -M 0 -f -o ConnectTimeout=10 -o ServerAliveInterval=60 -o ServerAliveCountMax=2 -p 22 -N -R 80:localhost:80 vServer_user@makesmart.net

Achtung: Auch hier müsst ihr darauf achten, dass ihr die crontab mit dem Benutzer ausführt, der auch das Schlüsselpaar generiert hat. Also auch hier kein sudo crontab -e