Reverse-Proxy (Gateway-Server)

Einen internen Webserver kann man schnell aufsetzen und intern sinnvoll nutzen. Schnell kommt der Wunsch auf, den Webserver auch von daheim nutzen zu können. Hier wird eine Lösung dafür vorgestellt. Im Folgenden erhalten Sie den (aus meiner Sicht) kompletten Überblick.

Siehe auch: Exemplarisch zeige ich, wie ich für Schüler eine Shell per Web bereitgestellt habe (damit sie in ihrem Home-Office sqlite-Übungen durchführen können). Hier noch mit einer Linuxfirewall, Stand Feb. 2020.

Siehe auch: Ausführlich erkläre ich die Konfiguration von OPNsense als Reverse-Proxy mit fast allen unten beschriebenen Features unter „Reverse-Proxy auf Basis von OPNsense“ mit Links, Fehlersuche usw., Stand April 2020.

Problem: Wie kommt man von außen verantwortungsvoll auf interne Webserver?

Probleme/Fragestellungen:

Mehrere Server über einen Zugang?

Zugriff auf IP-Ebene?

IPv6 und/oder IPv4?

DNS-Auflösung?

HTTPS-Verschlüsselung?

Mit Portforwarding im Router klappt dies direkt wenn der Server in einer DMZ steht. Das würde bedeuten, dass der Server bereits HTTPS verstehen muss und eine geeignete DNS-Auflösung zu ihm zeigen muss. Damit ist er in dem Sinn aber kein interner Server mehr. Außerdem kann man unter IPv4 so nur einen Server an einem typischen Internetanschluss betreiben.

Eigentlich will man den internen Server aber auf einer privaten IPv4-Adresse laufen lassen, ihn intern per SSH erreichen und ansonsten auf Port 80 Webseiten liefern lassen. Und am Besten wäre die Möglichkeit mehrere Dienste/Server (z.B. Vertretungsplan, Cloudlösung, Medienreservierung, Informatikprojekte) erreichen zu können.

Idee: Ein Gateway-Server zum Internet

Ein geeigneter Gateway-Server ist als Webserver aus dem Internet per IP erreichbar.

Der Gateway-Server kann nun eigene statische Seiten (z.B. zur Begrüßung, Inhaltsverzeichnis usw.) haben und ausliefern. Wichtiger ist aber, dass er weitere Seiten von einem oder mehreren anderen Webservern holen kann. Dazu muss er diese per IP (IPv4 genügt) erreichen. Bei welcher URL der Gateway-Server nun welchen internen Webserver fragt, wird über eine Liste von Proxypass-Einstellungen (bei Apache) gemacht. Dabei können ganze virtuelle Hosts, Unterverzeichnisse oder auch nur Dateien konfiguriert werden.

Der Browser des Clients weiß nicht, welche Seiten der Gateway-Server von welchen Server holt. Alles wird aus seiner Sicht vom Gateway-Server geliefert!

Mögliche Features:

⇒ HTTPS

Heutzutage wird man den Gateway-Server hauptsächlich HTTPS ausliefern lassen. Dazu bietet sich ein Letsencrypt-Zertifikat an. Sobald sensible Daten, wie z.B. ein Login, übertragen werden, wäre im Internet HTTP mehr als fahrlässig. Dieses nutzt man nur noch um Clients auf HTTPS umzuleiten. Diese Umleitung bietet der Certbot von Letsencrypt automatisch an. Ein weiterer Vorteil dieses Aufbaus ist, dass der Gateway-Server den Rechen- und Kommunikationsaufwand der HTTPS-Verschlüsselung betreibt, während der interne Webserver sich nur um seine Seiteninhalte kümmern muss. So muss auch nur ein Server für Letsencrypt konfiguriert werden.

⇒ IPv6

Der interne Webserver muss nur vom Gateway-Server erreichbar sein, i.d.R. über eine private IPv4 Adresse. Da der Gateway-Server auf Applikationsebene arbeitet („er versteht die Requests“) kann er wiederum über IPv4 und IPv6 erreichbar sein und stellt dann einen eigenen Request an den iternen Webserver, so wie er ihn ansprechen kann.

⇒ dynamisches DNS

Da die meisten Schulen keine festen IP-Adressen haben, muss man die jeweils aktuellen IP-Adressen einem DynDNS-Dienst der eigenen Wahl mitteilen. Gute Dienste ermöglichen sowohl eine IPv4 als auch eine IPv6-Adresse als A bzw. AAAA-Record zu präsentieren. Der Gateway-Server kann dabei auch selbst die DynDNS-Meldung absetzen - insbesondere für IPv6.

⇒ Passwortschutz

Der Gateway-Server kann wahlweise bestimmte Unterverzeichnisse und damit auch bestimmte interne Webserverinhalte erst nach Passworteingabe freigeben.

⇒ virtuelle Hosts

Der Gateway-Server kann auch so konfiguriert sein, dass er nach außen auf verschiedene Servernamen mit unterschiedlicher Konfiguration reagiert. So kann man zwei interne Server präsentieren, bei denen jeweils im Rootverzeichnis wichtige Informationen liegen. Natürlich kann auch Letsencrypt problemlos mehrere Hostnamen und Domains gleichzeitig verwalten. Diese müssen im DNS aber alle auf die IP-Adressen des Gateway-Servers zeigen. Genauer: Man lässt diese DNS-Einträge als CNAME-Einträge auf die Adresse des DynDNS-Dienstes zeigen, der dann die passenden IP-Adressen verrät.

⇒ Loadbalancer/Failover

…ist möglich, setzt aber zwei identische interne Webserver voraus. Vielleicht sinnvoll, wenn diese wiederum auf einen gemeinsamen Datenbankserver zugreifen - im Schulkontext höchstens für Failover sinnvoll - vermutlich nur für Informatikprojekte geeignet.

Realisierung

⇒ Reverse-Proxy-Dienst

Man sollte für einen Reverse-Proxy (darum handelt es sich bei dem Gateway-Server) einen Serverdienst verwenden, mit dem man sich auskennt, denn schließlich ist dieser Dienst tatsächlich im Internet präsent und sollte daher sicher konfiguriert sein. Ich verwende gerne den Webserver Apache, andere bevorzugen Nginx. Es gibt aus dem Cloud-Umfeld auch spezialisierte Dienste wie Traefik.

Nutzt man eine Komplettlösung wie OPNsense, so muss man sich mit der entsprechenden Konfiguration beschäftigen (hier: HA-Proxy)

⇒ Dynamisches DNS

siehe eigenen Beitrag zu Dynamisches DNS. So kann man z.B. spdyn.de direkt per curl aus einem Skript heraus aktualisieren.

⇒ DNS

Wenn die Schule die Domäne abc-schule.edu besitzt, dann wird der offizielle Webserver unter www.abc-schule.edu zu erreichen sein. Diesen ignorieren wir hier. Dann bietet sich folgende Namensvergabe an:

plan.abc-schule.edu für den Vertretungsplan

medien.abc-schule.edu für die Medienreservierung und

nextcloud.abc-schule.edu für die Nextcloud der Schule.

Sollen die letzten drei Server intern als getrennte (vermutlich virtuelle) Server laufen, so reicht trotzdem ein einzelner Gateway-Server, der eine IPv4-Adresse und eine eigene IPv6-Adresse hat. Die IPv4-Adresse ist meist die des Routers, welcher ein Port-Forwarding von 80 und 443 auf den Gateway-Server macht. Die IPv6-Adresse ändert sich gelegentlich, ist aber wirklich nur für diesen Host reserviert. Trotzdem muss im Router meist erst erlaubt werden, dass der Gateway-Server per IPv6 auf den beiden Ports erreicht werden darf.

In den Einstellungen der abc-schule.edu-Domain setzt man einmalig für plan., medien., und nextcloud. jeweils einen CNAME-Eintrag auf gatewayabcschule.my-firewall.org.

Nun muss der Gateway-Server seine IP-Adressen regelmäßig an den entsprechenden Dienst melden. Dieser liefert diese bei einem DNS-request nach z.B. gatewayabcschule.my-firewall.org.

Wie läuft das im Detail ab?

Ein Browser soll auf plan.abc-schule.edu zugreifen und fragt sein Betriebssystem.

Der DNS-Client des Betriebssystems erfährt von seinem DNS-Server, dass plan.abc-schule.edu auf gatewayabcschule.my-firewall.org zeigt (das bedeutet der CNAME).

Der DNS-Client fragt nun gatewayabcschule.my-firewall.org ab und erhält sowohl einen A-Record als auch einen AAAA-Record und damit je eine IPv4 und IPv6-Adresse.

Nach eigener Wahl ruft der Browser nun den Server unter einer der IP-Adressen an (meist IPv6 bevorzugt) und gibt den gewünschten Servernamen mit. So kann dann der Gateway-Server erkennen, welcher seiner virtual hosts gemeint ist.

Das verrät unter Linux alles der Befehl host (dezent gefälscht…)

cb@rechner:~$ host plan.abc-schule.de
plan.abc-schule.de is an alias for gatewayabcschule.my-firewall.org.
gatewayabcschule.my-firewall.org has address 91.41.116.37
gatewayabcschule.my-firewall.org has IPv6 address 2003:deaf:ff08:6400:ecc0:affe:cafe:9088
cb@rechner:~$

Test

Von außen:

sind alle Dienste so erreichbar wie sie sein sollen?

wird der Zwang zur Anmeldung durchgesetzt, oder kommt man mit einer geschickten URL durch?

was sagt SSLLabs zu dem Server?

welche Ports meldet nmap unter den verschiedenen IP-Adressen als offen?

Quellen

Die eigentliche Konfiguration des Reverse-Proxy ist im Internet oft beschrieben, siehe oben bei den drei Hauptdiensten.

Erfahrung an einer anderen Schule: https://www.schul-administrator.de/reverse-proxy-oder-mehrere-dienste-mit-gleicher-ip-adresse-und-gleichem-port/