Traffic-Pfade mit TLS und Proxy Protocol steuern

TL;DR

Ein stabiler Traffic-Pfad endet nicht bei der TLS Termination. Entscheidend ist das abgestimmte Zusammenspiel aus TLS-Endpunkt, Routing, Backend-Auswahl, Health Checks und Proxy Protocol . Die Edge bestimmt den öffentlichen Verbindungsweg; die Anwendung muss festlegen, wie sie übertragene Client-Informationen verarbeitet und welche Protokollparameter sie akzeptiert.

Einleitung

TLS Termination, Routing und Proxy Protocol werden in der Praxis häufig getrennt konfiguriert. Genau daraus entstehen Fehler: Ein Backend erhält zwar Verbindungen, kann aber die zusätzliche Proxy-Protocol-Zeile nicht verarbeiten. Oder die Edge terminiert TLS, während die Anwendung weiterhin von einer direkten HTTPS-Verbindung des Clients ausgeht. Der Traffic-Pfad muss deshalb als durchgängiger Ablauf betrachtet werden. Jede Komponente verändert die Verbindung oder ergänzt Informationen. Die zentrale Architekturfrage lautet nicht nur, wo TLS endet, sondern auch, welche Identität und Metadaten danach an das Backend übergeben werden und welche Verantwortung dort verbleibt.

1. Der Traffic-Pfad beginnt am TLS-Endpunkt

Bei einer Verbindung zu einem öffentlichen Service erreicht der Client zunächst einen Anycast-basierten Edge-Einstiegspunkt. Für HTTP- und HTTPS-Services kann die ayedo Edge Cloud TLS an der Edge terminieren. Der TLS-Endpunkt übernimmt damit die Aushandlung mit dem Client und stellt der nachgelagerten Verarbeitung bereits eine entschlüsselte Verbindung zur Verfügung.

Diese Entscheidung trennt zwei Verantwortungsbereiche. Die Edge verantwortet den öffentlichen TLS-Eingang, die Anwendung bleibt für ihre eigene Protokoll- und Sicherheitslogik zuständig. Ein Backend darf daher nicht automatisch davon ausgehen, dass die Verbindung zu ihm weiterhin dem ursprünglichen Client-TLS-Kanal entspricht. Informationen wie das ursprünglich verwendete Protokoll müssen über definierte Header oder andere Übergabemechanismen ausgewertet werden, sofern sie für die Anwendung relevant sind.

Für die Konfiguration sind insbesondere Zertifikat, Hostname, Listener und das erwartete Anwendungsprotokoll aufeinander abzustimmen. Ein TLS-Fehler am Edge-Endpunkt ist dabei etwas anderes als ein Fehler zwischen Edge und Backend. Diese Pfade sollten in Monitoring und Fehlersuche getrennt betrachtet werden.

2. Nach der Termination entscheidet die Edge über das Ziel

Nach der TLS Termination folgt die Routingentscheidung. Bei HTTP-Services können dabei unter anderem Hostname oder URL-Pfad zur Auswahl des Zielservices beitragen. Auf Layer 4 bleibt die Entscheidung stärker an Netzwerkparametern wie IP und Port orientiert. Welche Ebene verwendet wird, hängt vom Dienst und seinem Protokoll ab.

Die ayedo Edge Cloud verbindet diese Routinglogik mit Backend-Pools, Health Checks und Failover. Ein Pool beschreibt dabei nicht nur eine Liste erreichbarer Ziele, sondern einen betrieblichen Entscheidungsraum: Welche Backends gelten als verfügbar, und wohin wird Traffic verteilt, wenn einzelne Ziele ausfallen? Die Routingkonfiguration muss deshalb mit den tatsächlich exponierten Ports, Protokollen und Gesundheitsprüfungen übereinstimmen.

Wichtig ist die Grenze zwischen Edge und Anwendung: Die Edge entscheidet, welches Backend die Verbindung erhält. Sie entscheidet nicht, ob die Anwendung fachlich autorisiert ist oder eine Anfrage korrekt verarbeitet. Ein erfolgreiches Routing und ein erfolgreicher Health Check belegen nur die technische Erreichbarkeit beziehungsweise den definierten Prüfzustand, nicht die fachliche Funktionsfähigkeit des Services.

3. Proxy Protocol übergibt Verbindungsmetadaten

Wird Proxy Protocol für einen Backend-Pool aktiviert, erhält der Backend-Dienst vor den eigentlichen Nutzdaten eine zusätzliche Information über die ursprüngliche Verbindung. Dazu gehören insbesondere Quell- und Zielinformationen auf Verbindungsebene. Das ist relevant, wenn ein Service die Client-IP für Protokollierung, Zugriffskontrolle, Rate-Limiting oder forensische Auswertung benötigt.

Diese Funktion verändert jedoch das erwartete Eingangsprotokoll. Ein HTTP-Server, TLS-Listener oder TCP-Dienst muss Proxy Protocol ausdrücklich unterstützen und an der richtigen Stelle auswerten. Ein Backend, das unmittelbar mit HTTP- oder TLS-Daten rechnet, kann die zusätzliche Übergabe andernfalls als ungültige Nutzlast interpretieren. Das Problem liegt dann nicht zwingend im Routing, sondern an einer nicht abgestimmten Backend-Integration.

Proxy Protocol ist außerdem kein Ersatz für eine fachliche Identität. Die übertragenen Verbindungsinformationen müssen innerhalb der vertrauenswürdigen Edge-zu-Backend-Strecke verarbeitet werden. Anwendungen sollten daraus keine uneingeschränkte Benutzeridentität ableiten. Für Authentisierung und Autorisierung bleiben geeignete Anwendungsmechanismen zuständig.

4. Edge- und Anwendungskonfiguration müssen getrennt geprüft werden

Ein vollständiger Test muss jede Übergabestelle berücksichtigen: TLS-Verbindung zum Edge-Endpunkt, Zertifikats- und Hostname-Prüfung, Routingregel, Auswahl des Backend-Pools, Health-Check-Zustand, Proxy-Protocol-Verarbeitung und anschließende Anwendungskommunikation. Einzelne Tests am Backend reichen nicht aus, wenn sie den tatsächlichen öffentlichen Traffic-Pfad umgehen.

Auch die Protokollgrenzen müssen klar dokumentiert sein. Die Edge verarbeitet und verteilt eingehenden Traffic; das Backend entscheidet, wie Proxy Protocol, HTTP-Header und die eigentliche Nutzlast interpretiert werden. Für die Anwendung ist besonders wichtig, ob sie die Verbindung als HTTP, HTTPS oder reines TCP erwartet. Wird TLS am Edge beendet, muss die Anwendung ihre Annahmen über den ursprünglichen Transport entsprechend abbilden.

Bei Kubernetes kommt eine weitere Integrationsgrenze hinzu: Die Edge muss den extern erreichbaren Service und seine Backends erreichen können, während der Kubernetes-Service oder Ingress den erwarteten Listener bereitstellt. Das gilt unabhängig davon, ob der Cluster mit ayedo Managed Kubernetes oder bei einem anderen Provider betrieben wird. Providerunabhängigkeit ändert nicht die Protokollanforderungen des Backends.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine HTTPS-API in einem eigenen Kubernetes-Cluster. Der öffentliche Traffic erreicht die ayedo Edge Cloud, TLS wird dort terminiert und anhand des Hostnamens an einen Backend-Pool geroutet. Der Pool nutzt Health Checks und übergibt die Client-Verbindungsdaten per Proxy Protocol.

Der erste Test gegen den Service schlägt fehl, weil der vorgeschaltete Listener nur HTTP erwartet und Proxy Protocol nicht aktiviert verarbeitet. Nach der Anpassung des Listeners funktioniert die Verbindung. Ein zweiter Test zeigt jedoch, dass die Anwendung Redirects mit dem Schema http erzeugt, weil sie die TLS Termination nicht berücksichtigt. Das Problem liegt nun nicht mehr in Proxy Protocol, sondern in der Anwendungslogik zur Ermittlung des ursprünglichen Schemas. Beide Fehler entstehen entlang desselben Traffic-Pfads, benötigen aber unterschiedliche Verantwortliche und Prüfungen.

FAQ

Muss TLS am Edge immer terminiert werden?

Nein. Die Entscheidung hängt von Sicherheitsmodell, Protokoll und Backend-Anforderungen ab. Wird TLS an der Edge terminiert, müssen die nachgelagerten Protokoll- und Vertrauensgrenzen ausdrücklich definiert werden.

Ersetzt Proxy Protocol HTTP-Header für die Client-IP?

Nein. Proxy Protocol übergibt Verbindungsinformationen auf Transportebene. HTTP-Header gehören zur Anwendungsebene und verfolgen andere Anforderungen an Verarbeitung, Vertrauen und Validierung.

Funktioniert Proxy Protocol mit jedem Backend?

Nein. Der Backend-Listener muss das Protokoll unterstützen und korrekt konfigurieren. Andernfalls werden die zusätzlichen Daten vor der eigentlichen Nutzlast als ungültige Anfrage interpretiert.

Fazit

TLS Termination, Routing und Proxy Protocol sind keine unabhängigen Schalter, sondern aufeinanderfolgende Stationen eines Traffic-Pfads. Jede Station verändert den Kontext der Verbindung und verschiebt einen Teil der Verantwortung zwischen Edge und Anwendung. Die ayedo Edge Cloud bündelt diese Aufgaben am öffentlichen Eingang und kann Traffic über Edge-Routing, Backend-Pools, Health Checks und Proxy Protocol weitergeben. Stabil wird die Architektur erst, wenn die Protokollerwartungen an jeder Übergabe explizit dokumentiert und getestet werden.