Hoe gaat een reverse proxy om met TLS voor home server containers?

Een reverse proxy behandelt TLS voor home server-containers door de versleutelde verbinding van de browser te accepteren, het certificaat voor de gevraagde hostname te presenteren, het HTTP-verzoek te ontsleutelen, de bijpassende container te selecteren en een aparte upstream-verbinding naar die service te maken.

De verbindingen browser-naar-proxy en proxy-naar-container zijn dus verschillende beveiligingsgrenzen. De eerste gebruikt normaal gesproken een publiek of privé vertrouwd certificaat; de tweede kan een geïsoleerd HTTP-netwerk, een aparte HTTPS-verbinding of TLS-passthrough gebruiken wanneer de backend de private key moet behouden.

Waar eindigt de TLS-verbinding van de browser?

Met TLS-terminatie beëindigt de reverse proxy de TLS-verbinding van de client. De browser authenticereert het proxy-eindpunt en onderhandelt de encryptie met de proxy in plaats van direct met de applicatiecontainer.

De proxy houdt daarom de private key van het certificaat en kan de gedecrypteerde HTTP-methode, hostname, pad, headers, cookies en body lezen. Die zichtbaarheid stelt hem in staat te routeren, authenticeren, filteren, comprimeren, cachen of beveiligingsheaders toe te voegen.

Terminatie betekent niet dat de backend het publieke certificaat bezit. Vanuit het perspectief van de browser is de reverse proxy de HTTPS-server; vanuit het perspectief van de container is de proxy een nieuwe client die een apart verzoek doet.

Hoe bereikt één HTTPS-poort meerdere containers?

Een publieke DNS-naam verwijst clients naar de reverse proxy, en hostnamen selecteren de bijpassende containerroute. Elke hostname kan zijn eigen certificaat en upstream-bestemming hebben terwijl ze poort 443 delen.

Tijdens de TLS-handshake geeft de client normaal gesproken de bedoelde servernaam op zodat de proxy een bijpassend certificaat kan kiezen. Na decryptie bepalen de HTTP Host-header en de geconfigureerde route of het verzoek naar Jellyfin, Home Assistant, Vaultwarden of een andere container gaat.

Een standaardroute moet onbekende hostnamen weigeren in plaats van ze door te sturen naar een willekeurig dashboard. Het centraliseren van de toegang vereist niet dat elke interne dienst bereikbaar wordt via de publieke proxy.

Hoe worden certificaten uitgegeven en vernieuwd?

Reverse proxies kunnen optreden als ACME-clients, en DNS-uitdagingen automatiseren certificaatvernieuwing door een tijdelijke DNS-record te creëren die controle over het gevraagde domein bewijst.

Een HTTP-uitdaging bewijst controle via een webendpoint, terwijl een DNS-uitdaging certificaten kan uitgeven voor interne services of wildcard-namen zonder elke container direct te publiceren. De validatiemethode verandert de blootstelling en vereisten voor referenties.

Automatisering verplaatst het verlopen van certificaten van een handmatige kalender-taak naar de infrastructuurstatus. Het maakt ook het DNS-API-token van de proxy, ACME-accountgegevens en certificaatopslag gevoelige middelen die beperkte rechten en back-up nodig hebben.

Is het verkeer tussen de proxy en container versleuteld?

De upstream is onafhankelijk geconfigureerd, dus upstream-links kunnen HTTP of HTTPS gebruiken. Het beëindigen van publieke TLS bepaalt niet automatisch of de interne verbinding versleuteld is.

Eenvoudig HTTP kan redelijk zijn op een privé-containernetwerk dat beperkt is tot één vertrouwde host, maar de proxy kan dat verkeer lezen en wijzigen. Als de upstream hosts, onbetrouwbare netwerken of sterkere vertrouwensgrenzen overschrijdt, vermindert een aparte geverifieerde HTTPS-verbinding de blootstelling.

Her-encryptie creëert twee TLS-sessies en twee certificaatbeslissingen. De proxy moet het backendcertificaat en de verwachte naam valideren; alleen HTTPS inschakelen zonder verificatie vervangt encryptie door een niet-geauthenticeerde tunnel.

Hoe leert de container de oorspronkelijke clientcontext kennen?

De upstream TCP-verbinding komt van de proxy, dus verbergen proxyverbindingen het oorspronkelijke clientadres. Doorgegeven headers bevatten het client-IP, het oorspronkelijke schema, de hostnaam en de poort die de applicatie nodig heeft.

Zonder het oorspronkelijke HTTPS-schema kan een applicatie HTTP-omleidingen genereren, beveiligde cookies onjuist markeren of de verkeerde callback-URL bouwen. Zonder een betrouwbare clientadres kunnen logs, snelheidslimieten en toegangsbeleid alleen de proxy identificeren.

De proxy moet deze waarden consistent instellen en het containerframework moet worden geconfigureerd om het juiste aantal hops of het proxy-netwerk te vertrouwen. Het doorsturen van een header en het veilig interpreteren ervan zijn aparte taken.

Welke nieuwe vertrouwensgrens creëert TLS-terminatie?

Clients kunnen zelf vervalste doorstuurheaders verzenden, dus vertrouwde proxies moeten doorgestuurde headers saneren voordat de backend ze gebruikt voor beveiligingsbeslissingen.

Directe toegang tot de container moet worden geblokkeerd wanneer de app vertrouwt op door de proxy geleverde identiteit. Anders kan een client de proxy omzeilen, zijn eigen X-Forwarded-For- of schemawaarde indienen en zich voordoen als de context waarvan de applicatie aanneemt dat die van de vertrouwde ingress komt.

Container-ingress herschrijft het zichtbare clientpad. Bescherm de privésleutels van de proxy, beperk de beheerinterface, stel alleen bedoelde routes bloot en monitor certificaatvernieuwing en upstream-gezondheid omdat de proxy nu een gedeelde beveiligingsafhankelijkheid is.

FAQ

Heeft elke container een eigen publiek TLS-certificaat nodig?

Niet wanneer de reverse proxy TLS beëindigt. De proxy kan certificaten voor meerdere hostnamen beheren en ontsleutelde verzoeken doorsturen naar aparte interne containers.

Is HTTP van de proxy naar een container altijd onveilig?

Dat hangt af van de vertrouwensgrens. Een geïsoleerd netwerk op dezelfde host heeft een andere blootstelling dan een gerouteerd of gedeeld netwerk. HTTPS met certificaatverificatie biedt sterkere bescherming over niet-vertrouwde segmenten.

Kan een reverse proxy HTTPS routeren zonder het te ontsleutelen?

Ja. TLS passthrough kan routeren met behulp van handshake-informatie zoals SNI terwijl de backend TLS beëindigt, maar de proxy verliest dan de normale HTTP-laag zichtbaarheid en filtering.

Waarom zouden containers directe externe toegang moeten weigeren?

Wanneer een app vertrouwt op doorgestuurde headers, kan directe toegang ervoor zorgen dat clients de proxy-sanering omzeilen en vervalste identiteit-, schema- of hostname-waarden indienen.

Laatste conclusie

Een reverse proxy behandelt TLS door het publieke cryptografische eindpunt te worden en een tweede, afzonderlijk beheerde verbinding met elke container te maken. Betrouwbare beveiliging hangt af van correcte hostname-routing, geautomatiseerde maar beschermde certificaatvernieuwing, bewuste upstream-encryptie, gesaniteerde doorstuurheaders en het blokkeren van paden die de vertrouwde proxy omzeilen.