Reverse Proxy mit NGINX – lokale Webdienste von überall nutzen

Jeder kennt das Problem – man möchte von unterwegs mal schnell auf einen der heimischen Netzdienste zugreifen, z.B. den ioBroker um schnell eine Einstellung zu ändern, oder das Proxmox-Interface um mal schnell einen Server neu zu starten. Anwendungsmöglichkeiten gibt es tausende.

Die erste Idee, die die meisten dann haben: Eine VPN-Verbindung aufbauen – gute Idee, aber einfach nicht immer möglich (z.B. vom Computer im Büro, weil dort kein VPN konfiguriert werden kann) oder zu aufwändig (weil man nur mal schnell vom PC eines Bekannten drauf zugreifen möchte).

Die Lösung hier ist: Der Zugriff einfach über einen Reverse Proxy, welcher zu Hause im eigenen Netz läuft! In meinem Beispiel werde ich dies anhand einer virtuellen Maschine unter Proxmox erklären, es spricht jedoch auch nichts dagegen, dies z.B. mit einem Respberry Pi umzusetzen. Kurz gesagt: es geht jeder Linux-Rechner!

Voraussetzungen, welche erfüllt sein müssen:

• Ihr braucht einen Domain-Anbieter, welcher Euch die Weiterleitung einer (Sub-)Domain auf Euer eigenes Netzwerk zu Hause erlaubt. Ich habe hier beste Erfahrungen mit ALL-INKL☆ gemacht, die bieten das (ab dem Paket PrivatPlus) und sind super preiswert für einen Webhoster mit persönlichem, schnellen und fachkundigen Support!
• In Eurem Router müssen die Ports 80 sowie 443 auf unseren neu aufgesetzten NGINX-Server weitergeleitet werden.

Ich werde die Installation wie bereits geschrieben auf einem Proxmox-Container durchführen, diesen also erst mal anlegen. Als Parameter empfehle ich hierzu wie folgt:

• Template: ich habe hier debian-10.0-standard_10.0-1_amd64.tar.gz genutzt, es sollte aber annähernd jedes andere Linux genauso gut gehen (kann nur sein, dann man da vllt. das ein oder andere Paket nachinstallieren muss)
• Root-Disk-Größe: 4 GB
• CPU: 1 Core
• Speicher: 512 MB
• Netzwerk: Einstellungen je nach eigenem Wunsch – wir brauchen eine feste IP, diese kann hier statisch eingestellt werden (außerhalb Eures DHCP-Bereiches!) oder einfach im DHCP-Server des Routers dauerhaft zugewiesen werden

Wer auf einem Raspberry Pi oder einem anderen Gerät installiert, wählt einfach ein entsprechendes Image aus (z.B. Raspberry Pi OS Lite, früher bekannt als Raspbian).

Nach erfolgter Anlage der VM / Installation loggen wir uns als Root auf der Konsole ein. Hier spielen wir erst mal alle aktuell verfügbaren Updates ein:

apt-get update

apt-get upgrade -y

Nun müssen der NGINX-Server sowie der Bot für die Zertifikate installiert werden:

apt-get install nginx certbot -y

Als nächstes wechseln wir in den Ordner der Konfigurations-Dateien für NGINX

cd /etc/nginx/sites-available/

Hier legen wir mit dem Editor Nano eine neue Datei an. Als Namen wähle ich hier immer meine entsprechende Subdomain (im Beispiel iobroker.bloggerbu.de):

nano iobroker.bloggerbu.de.conf

Nun kopieren wir den Inhalt des nächsten Blocks in den Editor und passen die farbigen Teile an unsere Bedürfnisse an (Hinweise dazu nach dem Block):

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  server_name iobroker.bloggerbu.de;
  return 301 https://$host$request_uri;
}

# SSL configuration
server {
  listen 443 ssl;
  server_name iobroker.bloggerbu.de;
  ssl_certificate      /etc/letsencrypt/live/iobroker.bloggerbu.de/fullchain.pem;
  ssl_certificate_key  /etc/letsencrypt/live/iobroker.bloggerbu.de/privkey.pem;

  # Improve HTTPS performance with session resumption
  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 5m;

  # Enable server-side protection against BEAST attacks
  ssl_prefer_server_ciphers on;
  ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;

  # Disable SSLv3
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  # Diffie-Hellman parameter for DHE ciphersuites
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  # Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security)
  add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";

  # Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox)
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/iobroker.bloggerbu.de/fullchain.pem;
  resolver 8.8.8.8 8.8.4.4 valid=300s;
  resolver_timeout 5s;

  location / {
    proxy_pass http://192.168.178.32:8081;
    proxy_set_header Host $host;
    proxy_redirect http:// https://;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
  }
}

• Bei den roten Bereichen geben wir unsere gewählte Subdomain an
• im grünen Bereich geben wir das Ziel in unserem Netzwerk an, wohin der ReverseProxy umleiten soll (also mit http/https vorne und Angabe des Ports nach der IP).

Nun verlassen wir den Editor wieder (Strg + X), dann mit Y das speichern bestätigen und mit Enter den Dateinamen bestätigen.

Wenn Ihr mehrere Dienste von außen zugänglich machen wollt, erstellt Ihr einfach noch weitere Dateien mit den entsprechenden Namen und Konfigurationen.

Da die Verbindung natürlich über SSL verschlüsselt werden soll, müssen wir nun die entsprechenden Schlüssel hierfür erzeugen:

openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096

Nicht wundern, je nach CPU kann dieser Vorgang eine ganze Weile dauern… Jetzt wo der Schlüssel vorhanden ist, können wir unsere Zertifikate erstellen lassen. Da hierfür kurzzeitig ein eigener Webserver-Dienst aktiviert wird, müssen wir unseren NGINX-Server vorübergehend beenden:

systemctl stop nginx

Das Zertifikat fordern wir dann über folgenden Befehl an:

certbot certonly -d iobroker.bloggerbu.de

Die Domain hierzu muss natürlich entsprechend angepasst werden. Während der Erstellung bekommen wir einige Fragen gestellt (rot die dazu passenden Antworten):

• How would you like to authenticate with the ACME CA? –> 1
• E-Mail-Adresse? –> muss richtig sein!
• Terms of Service –> a(gree)

Nun sollte Euch gratuliert werden, dass Ihr diesen Schritt erfolgreich abgeschlossen habt 😉

Wenn Ihr mehrere (Sub-)Domains angelegt habt, wiederholt Ihr diesen Schritt jetzt für alle.

Im nächsten Schritt aktivieren wir nun noch unsere neue Seite im NGINX-Server, hierzu müssen wir einen Symlink setzen (wieder in rot die entsprechend anzupassenden Daten):

ln -s /etc/nginx/sites-available/iobroker.bloggerbu.de.conf /etc/nginx/sites-enabled/

Auch hier gilt natürlich wieder: Bei mehreren angelegten (Sub-)Domains, den Schritt entsprechend für alle wiederholen!

Die Einstellungen sind nun fertig abgeschlossen, wir können diese nun auf Richtigkeit prüfen:

nginx -t

Hier sollte nun keine Fehlermeldung kommen. Wenn doch, bitte nochmal alle obigen Einstellungen überprüfen! Sollte alles passen, wird der Serverdienst gestartet:

systemctl start nginx

ACHTUNG WICHTIG: Bitte bei allen aus dem Internet erreichbaren Diensten dran denken, eine Login-Funktion zu aktivieren und ein nicht all zu leichtes Passwort zu verwenden! Es macht keinen Sinn, verschlüsselte Verbindungen zu verwenden, wenn Euer Passwort „1234“ lautet oder gar keines vorhanden ist!

HINWEIS: Ich weiss nicht wieso, aber ich habe eine meiner Subdomains storage.domain.tld genannt, diese hat den NGINX dazu gebracht, nicht mehr starten zu können. Wieso das so ist: Keine Ahnung…

Als Inspiration für die Verwendung, hier mal meine Dienste (die in Wirklichkeit natürlich anders heißen), damit man sehen kann, was damit alles machbar ist:

• 3ddrucker.bloggerbu.de
• bitwarden.bloggerbu.de
• dateiserver.bloggerbu.de
• deconz.bloggerbu.de
• homematic.bloggerbu.de
• iobroker.bloggerbu.de
• nextcloud.bloggerbu.de
• proxmox.bloggerbu.de