Nachdem wir uns kürzlich damit beschäftigt haben, wie man die eigene (also die vom Internetprovider zugeteilte) IP-Adresse mit einem festen Hostnamen verbindet, soll es nun darum gehen, Dienste aus dem eigenen Netz über diesen Hostnamen erreichbar zu machen.

Hierfür gibt es (mindestens) zwei Möglichkeiten:

  1. Man kann für jeden Dienst eine Portweiterleitung in der Firewall definieren. So hört dann beispielsweise Nextcloud auf Port 8080, BitWarden auf Port 8081 und so weiter.
  2. Man setzt einen Reverse Proxy ein.

Variante 1 hat den Vorteil, dass sie schnell umgesetzt ist – in der Firewall wird eine Portweiterleitung definiert (z.B. „Anfrage auf Port 8080 weiterleiten auf den Internen Host 10.11.12.13 an Port 80“). Das war’s aber auch mit den Vorteilen. Die Nachteile überwiegen in meinen Augen:

  • Für jeden Dienst, den man anbieten will, muss ein eigener Port geöffnet werden – im schlimmsten Fall macht dann irgendwann eine Firewall keinen Sinn mehr, weil mehr Ports offen sind als geschlossen…
  • Heutzutage ist es en vogue, Dienste im Internet verschlüsselt anzubieten. Bei Variante 1 muss jeder Dienst sich selbst darum kümmern, ein gültiges Zertifikat bereitzustellen und einzubinden

Da kommt Variante 2 ins Spiel: Ein Reverse Proxy. Das ist ein Stück Software, das Anfragen auswertet und nach entsprechend definierten Regeln an interne Hosts weiterleitet (z.B. „wenn eine Anfrage nach bitwarden.jan-eggert.com eintrifft, leite sie weiter an den internen Host 10.11.12.13“). Zusätzlich dazu kann so ein Reverse Proxy auch noch für Load Balancing sorgen, also eine Lastverteilung durchführen. Das ist sicherlich für eine kleine Webseite wie meine nicht nötig (für die paar Klicks braucht es keinen Cluster, der die Millionen von Aufrufen unter seinen Nodes aufteilt); ein multinationaler Konzern, dessen Webseite tausendfach in pro Sekunde angeklickt wird, kann davon aber sicherlich profitieren.

Außerdem bieten die meisten Reverse Proxys die Möglichkeit, Zertifikate von Let’s Encrypt einzubinden. Um beim obigen Beispiel zu bleiben, könnte das dann so aussehen: „Wenn eine Anfrage nach bitwarden.jan-eggert.com eintrifft, leite sie weiter an den internen Host 10.11.12.13; stelle das passende Zertifikat bereit und lenke den Verkehr auf HTTPS um“. Damit zickt dann auch der Browser nicht mehr rum, dass die Verbindung unsicher ist.

Es gibt viele Reverse Proxys – die Webserver Apache und nginx bringen diese Funktionalität mit. Gerade im Zusammenspiel mit Docker hat Træfik besondere Stärken (da genügt es, einem neuen Container bestimmte Labels mitzugeben, um ihn beim Træfik „bekannt“ zu machen). Außerdem gibt es noch HAProxy. Für den gibt es ein opnSense-Plugin. Das hat den Vorteil, dass der Reverse Proxy direkt auf der Firewall läuft und nicht auf einem Rechner im internen Netz.

Diese Miniserie wird sich daher damit beschäftigen, HAProxy einzurichten. In Teil 2 werden wir eine einfache Weiterleitung erstellen – so einfach ist das gar nicht, wie ich feststellen durfte…

Teil 3 wird sich dann damit befassen, wie wir das Ganze mit Let’s Encrypt absichern.