Wie handhabt ein Reverse-Proxy TLS für Home-Server-Container?

Ein Reverse-Proxy verwaltet TLS für Heimserver-Container, indem er die verschlüsselte Verbindung des Browsers annimmt, das Zertifikat für den angeforderten Hostnamen präsentiert, die HTTP-Anfrage entschlüsselt, den passenden Container auswählt und eine separate Upstream-Verbindung zu diesem Dienst herstellt.

Die Verbindungen Browser-zu-Proxy und Proxy-zu-Container sind daher unterschiedliche Sicherheitsgrenzen. Die erste verwendet normalerweise ein öffentlich oder privat vertrauenswürdiges Zertifikat; die zweite kann ein isoliertes HTTP-Netzwerk, eine separate HTTPS-Verbindung oder TLS-Passthrough nutzen, wenn das Backend den privaten Schlüssel behalten muss.

Wo endet die TLS-Verbindung des Browsers?

Bei der TLS-Termination beendet der Reverse-Proxy das TLS des Clients. Der Browser authentifiziert den Proxy-Endpunkt und verhandelt die Verschlüsselung mit ihm, nicht direkt mit dem Anwendungscontainer.

Der Proxy hält daher den privaten Schlüssel des Zertifikats und kann die entschlüsselte HTTP-Methode, den Hostnamen, den Pfad, Header, Cookies und den Body lesen. Diese Sichtbarkeit ermöglicht es ihm, Anfragen zu routen, zu authentifizieren, zu filtern, zu komprimieren, zu cachen oder Sicherheitsheader hinzuzufügen.

Termination bedeutet nicht, dass das Backend das öffentliche Zertifikat besitzt. Aus Sicht des Browsers ist der Reverse-Proxy der HTTPS-Server; aus Sicht des Containers ist der Proxy ein neuer Client, der eine separate Anfrage stellt.

Wie erreicht ein HTTPS-Port mehrere Container?

Ein öffentlicher DNS-Name verweist die Clients auf den Reverse-Proxy, und Hostnamen wählen die passende Container-Route aus. Jeder Hostname kann sein eigenes Zertifikat und Ziel-Backend haben, während Port 443 gemeinsam genutzt wird.

Während des TLS-Handshakes gibt der Client normalerweise den beabsichtigten Servernamen an, damit der Proxy ein passendes Zertifikat auswählen kann. Nach der Entschlüsselung bestimmen der HTTP-Host-Header und die konfigurierte Route, ob die Anfrage an Jellyfin, Home Assistant, Vaultwarden oder einen anderen Container weitergeleitet wird.

Eine Standardroute sollte unbekannte Hostnamen ablehnen, anstatt sie an ein beliebiges Dashboard weiterzuleiten. Die Zentralisierung des Zugangs erfordert nicht, dass jeder interne Dienst über den öffentlichen Proxy erreichbar ist.

Wie werden Zertifikate ausgestellt und erneuert?

Reverse-Proxies können als ACME-Clients fungieren, und DNS-Challenges automatisieren die Zertifikatserneuerung, indem sie einen temporären DNS-Eintrag erstellen, der die Kontrolle über die angeforderte Domain beweist.

Eine HTTP-Challenge beweist die Kontrolle über einen Web-Endpunkt, während eine DNS-Challenge Zertifikate für interne Dienste oder Wildcard-Namen ausstellen kann, ohne jeden Container direkt zu veröffentlichen. Die Validierungsmethode beeinflusst die Angriffsfläche und die Anforderungen an die Zugangsdaten.

Automatisierung verlagert das Ablaufdatum von Zertifikaten von einer manuellen Kalenderaufgabe in den Infrastrukturzustand. Sie macht auch das DNS-API-Token des Proxys, ACME-Kontodaten und die Zertifikatspeicherung zu sensiblen Assets, die enge Berechtigungen und Backups benötigen.

Ist der Datenverkehr zwischen Proxy und Container verschlüsselt?

Der Upstream ist unabhängig konfiguriert, daher können Upstream-Verbindungen HTTP oder HTTPS verwenden. Die Beendigung von öffentlichem TLS entscheidet nicht automatisch, ob die interne Verbindung verschlüsselt ist.

Klartext-HTTP kann in einem privaten Container-Netzwerk, das auf einen vertrauenswürdigen Host beschränkt ist, sinnvoll sein, aber der Proxy kann diesen Datenverkehr lesen und verändern. Überschreitet der Upstream Hosts, nicht vertrauenswürdige Netzwerke oder stärkere Vertrauensgrenzen, reduziert eine separate verifizierte HTTPS-Verbindung die Angriffsfläche.

Die Re-Verschlüsselung erzeugt zwei TLS-Sitzungen und zwei Zertifikatsentscheidungen. Der Proxy muss das Backend-Zertifikat und den erwarteten Namen validieren; nur HTTPS zu aktivieren und die Überprüfung zu überspringen ersetzt die Verschlüsselung durch einen nicht authentifizierten Tunnel.

Wie erfährt der Container den ursprünglichen Client-Kontext?

Die Upstream-TCP-Verbindung stammt vom Proxy, daher verbergen Proxy-Verbindungen die ursprüngliche Client-Adresse. Weitergeleitete Header tragen die Client-IP, das ursprüngliche Schema, den Hostnamen und den Port, die von der Anwendung benötigt werden.

Ohne das ursprüngliche HTTPS-Schema kann eine Anwendung HTTP-Weiterleitungen erzeugen, sichere Cookies falsch kennzeichnen oder die falsche Callback-URL erstellen. Ohne eine vertrauenswürdige Client-Adresse können Protokolle, Ratenbegrenzungen und Zugriffsrichtlinien nur den Proxy identifizieren.

Der Proxy muss diese Werte konsistent setzen, und das Container-Framework muss so konfiguriert sein, dass es die korrekte Hop-Anzahl oder das Proxy-Netzwerk vertraut. Das Weiterleiten eines Headers und dessen sichere Interpretation sind getrennte Aufgaben.

Welche neue Vertrauensgrenze schafft die TLS-Beendigung?

Clients können gefälschte Weiterleitungsheader selbst senden, daher müssen vertrauenswürdige Proxies weitergeleitete Header bereinigen, bevor das Backend sie für Sicherheitsentscheidungen verwendet.

Direkter Zugriff auf den Container sollte blockiert werden, wenn die App der vom Proxy bereitgestellten Identität vertraut. Andernfalls kann ein Client den Proxy umgehen, eigene X-Forwarded-For- oder Schema-Werte einreichen und den Kontext vortäuschen, von dem die Anwendung annimmt, dass er vom vertrauenswürdigen Ingress stammt.

Container-Ingress schreibt den sichtbaren Client-Pfad um. Schützen Sie die privaten Schlüssel des Proxys, beschränken Sie seine Verwaltungsoberfläche, exponieren Sie nur beabsichtigte Routen und überwachen Sie die Zertifikatserneuerung sowie die Upstream-Gesundheit, da der Proxy nun eine gemeinsame Sicherheitsabhängigkeit ist.

FAQ

Braucht jeder Container ein eigenes öffentliches TLS-Zertifikat?

Nicht wenn der Reverse-Proxy TLS terminiert. Der Proxy kann Zertifikate für mehrere Hostnamen halten und entschlüsselte Anfragen an separate interne Container weiterleiten.

Ist HTTP vom Proxy zu einem Container immer unsicher?

Das hängt von der Vertrauensgrenze ab. Ein isoliertes Netzwerk auf demselben Host hat eine andere Exposition als ein geroutetes oder geteiltes Netzwerk. HTTPS mit Zertifikatsprüfung bietet stärkeren Schutz über nicht vertrauenswürdige Segmente hinweg.

Kann ein Reverse-Proxy HTTPS routen, ohne es zu entschlüsseln?

Ja. TLS-Passthrough kann anhand von Handshake-Informationen wie SNI routen, während das Backend TLS terminiert, aber der Proxy verliert die normale HTTP-Ebenen-Sichtbarkeit und Filterung.

Warum sollten Container direkten externen Zugriff ablehnen?

Wenn eine App weitergeleitete Header vertraut, ermöglicht direkter Zugriff Clients, die Proxy-Bereinigung zu umgehen und gefälschte Identitäts-, Schema- oder Hostnamenwerte einzureichen.

Fazit

Ein Reverse-Proxy übernimmt TLS, indem er zum öffentlichen kryptografischen Endpunkt wird und eine zweite, separat verwaltete Verbindung zu jedem Container herstellt. Zuverlässige Sicherheit hängt von korrektem Hostnamen-Routing, automatischer aber geschützter Zertifikatserneuerung, bewusster Upstream-Verschlüsselung, bereinigten Weiterleitungsheadern und dem Blockieren von Pfaden ab, die den vertrauenswürdigen Proxy umgehen.