Reverse-Proxy

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 (Port 443 und ggf. 80) im Router klappt dies direkt wenn der Server in einer DMZ, also direkt hinter dem Router 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 unter verschiedenen Namen 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 dieser eine Gateway-Server für Letsencrypt konfiguriert werden.

Auch das Sicherstellen eine hochwertigen Verschlüsselung (TLS 1.2 und 1.3) muss nur an einem Rechner beachtet 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.

⇒ HTTP/2 und /3

Neuere Varianten des HTTP(S)-Protokolls müssen nur an einem Server konfiguriert werden und schon sind alle Dienste darüber erreichbar.

⇒ dynamisches DNS

Der Gateway-Server kann ggf. selbst die DynDNS-Meldung absetzen, damit die Adresse, auf die seine Erreichbarkeit angewiesen ist, aktuell bleibt. Siehe DynDNS.

⇒ 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.
Natürlich kann auch Letsencrypt problemlos mehrere Hostnamen, aber auch 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). Dies habe ich vor einigen Jahren gemacht und aufwendig dokumentiert - lt. Google eine meiner erfolgreichsten Einzelseiten im Netz :-). Die Lösung hielt jedoch nicht über mehrere Updates hinweg und erwies sich für mich als zu wartungsintensiv und definitiv zu kompliziert in der Fehlersuche.

⇒ Dynamisches DNS

Ein Gateway-Server ist darauf angewiesen, unter einer festen Adresse erreicht zu werden. Siehe dazu den eigenen Beitrag zu DynDNS.

⇒ DNS

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

• plan.beispiel-schule.de für den Vertretungsplan
• medien.beispiel-schule.de für die Medienreservierung und
• nextcloud.beispiel-schule.de 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 beispiel-schule.de-Domain setzt man einmalig für plan., medien., und nextcloud. jeweils einen CNAME-Eintrag auf beispielschulegateway.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. beispielschulegateway.my-firewall.org.

Wie läuft das im Detail ab?

• Ein Browser soll auf plan.beispiel-schule.de zugreifen und fragt sein Betriebssystem.
• Der DNS-Client des Betriebssystems erfährt von seinem DNS-Server, dass plan.beispiel-schule.de auf beispielschulegateway.my-firewall.org zeigt (das bedeutet der CNAME).
• Der DNS-Client fragt nun beispielschulegateway.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.beispiel-schule.de
plan.beispiel-schule.de is an alias for beispielschulegateway.my-firewall.org.
beispielschulegateway.my-firewall.org has address 91.41.116.37
beispielschulegateway.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.

Christian Bienmüller