Metainformationen zur Seite
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
sysbetr:reverse_proxy [2020/04/06 14:15] – cb | sysbetr:reverse_proxy [Unbekanntes Datum] (aktuell) – gelöscht - Externe Bearbeitung (Unbekanntes Datum) 127.0.0.1 | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | =====Reverse Proxy===== | ||
- | 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. Exemplarisch zeige ich, wie ich für Schüler [[sysbetr: | ||
- | ====Problem: | ||
- | Probleme/ | ||
- | * 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/ | ||
- | ====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, | ||
- | |||
- | Der Browser des Clients weiß nicht, welche Seiten der Gateway-Server von welchen Server holt. Alles wird 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 [[https:// | ||
- | |||
- | ===⇒ 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" | ||
- | ===⇒ dynamisches DNS=== | ||
- | Da die meisten Schulen keine festen IP-Adressen haben, muss man die jeweils aktuellen IP-Adressen einem [[dyndns|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, | ||
- | ===⇒ Loadbalancer/ | ||
- | ...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 [[https:// | ||
- | |||
- | 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 [[DynDNS]]. | ||
- | 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, | ||
- | |||
- | 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: | ||
- | 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: | ||
- | cb@rechner: | ||
- | ====Test==== | ||
- | Von außen: | ||
- | * sind alle Dienste so erreichbar wie sie sein sollen? | ||
- | * wird der Zwang zur Anmeldung durchgesetzt, | ||
- | * was sagt [[https:// | ||
- | * welche Ports meldet //nmap// unter den verschiedenen IP-Adressen als offen? | ||
- | ====Quellen==== | ||
- | Die eigentliche Konfiguration des Reverse Proxy ist im Internet oft beschrieben, | ||
- | |||
- | Erfahrung an einer anderen Schule: https:// | ||
- | |||
- | {{tag> |