Proxy Protocol im L4- und L7-Betrieb korrekt einsetzen

TL;DR

Das Proxy Protocol überträgt Verbindungsinformationen wie die ursprüngliche Client-IP über eine Proxy- oder Loadbalancing-Verbindung hinweg. Im L4- und L7-Betrieb gelten dabei unterschiedliche Integrationsanforderungen. Entscheidend ist, dass der Backend-Dienst das Protokoll erwartet, korrekt auswertet und nicht mit normalen HTTP-Headern verwechselt.

Einleitung

Ein Backend sieht nicht automatisch die Adresse des tatsächlichen Clients. Sobald eine Edge-Plattform eine neue Verbindung zum Zielsystem aufbaut, erscheint zunächst die Edge als Kommunikationspartner. Das ist architektonisch gewollt, kann aber für Zugriffskontrolle, Rate Limiting, Audit-Logs oder forensische Analysen problematisch werden. Das Proxy Protocol löst dieses Problem, indem die Edge Verbindungsinformationen vor den eigentlichen Nutzdaten an das Backend übergibt. Die Funktion ist jedoch keine rein technische Einstellung am Loadbalancer: Sie bildet einen Integrationsvertrag zwischen Edge und Backend. Wird sie auf einer Seite aktiviert und auf der anderen nicht erwartet, entstehen keine besseren Logs, sondern fehlerhafte Verbindungen.

1. Was das Proxy Protocol tatsächlich überträgt

Das Proxy Protocol ergänzt eine Backend-Verbindung um Metadaten zur ursprünglichen Verbindung. Dazu gehören typischerweise Quell- und Zieladresse sowie die verwendeten Ports. Das Backend kann dadurch die Client-IP erkennen, obwohl die TCP-Verbindung technisch von der Edge Cloud aufgebaut wurde.

Wichtig ist die Abgrenzung zu einer transparenten Netzwerkverbindung: Das Proxy Protocol verändert nicht die Quelladresse auf IP-Ebene. Es übermittelt die Information innerhalb eines Protokollpräfixes, das vor dem eigentlichen Anwendungsprotokoll steht. Der Backend-Dienst oder ein vorgeschalteter Listener muss dieses Präfix deshalb interpretieren können.

Für ayedo Edge Cloud ist das Proxy Protocol eine Funktion innerhalb der Backend-Verbindung. Die Edge übernimmt weiterhin den öffentlichen Traffic-Eingang, das Routing und die Verteilung. Das Backend erhält zusätzliche Verbindungsinformationen, bleibt aber hinter der Edge verborgen. Diese Kombination unterstützt Backend Cloaking, ohne den Bedarf an belastbaren Logging- und Sicherheitsinformationen zu beseitigen.

2. L4: Verbindungsinformationen ohne HTTP-Verarbeitung

Im L4 Loadbalancing arbeitet die Edge auf Transportebene. Sie verteilt beispielsweise TCP-Verbindungen, ohne den Inhalt der Anwendung auf HTTP-Ebene auswerten zu müssen. Das ist relevant für TLS-Passthrough, Datenbanken, proprietäre TCP-Protokolle oder andere Dienste, bei denen die Edge den Anwendungsinhalt nicht terminieren soll.

Das Proxy Protocol wird in diesem Szenario am Anfang der Backend-TCP-Verbindung eingefügt. Der Backend-Endpunkt muss daher bereits vor dem eigentlichen Protokoll-Handshake mit dem Präfix rechnen. Ein Dienst, der unmittelbar einen TLS-, SMTP- oder proprietären Handshake erwartet, kann die Verbindung sonst als beschädigt interpretieren.

Die Client-IP bleibt für den Backend-Prozess verfügbar, obwohl die Edge die Verbindung weiterleitet. Gleichzeitig muss die Backend-Infrastruktur sicherstellen, dass nur vertrauenswürdige vorgelagerte Systeme Proxy-Informationen liefern dürfen. Akzeptiert ein öffentlich erreichbarer Dienst beliebige Proxy-Header, kann ein Angreifer Quelladressen fälschen und dadurch IP-basierte Regeln oder Logs manipulieren.

3. L7: Proxy Protocol vor HTTP oder TLS

Im L7-Betrieb terminiert die Edge typischerweise eine HTTP- oder HTTPS-Verbindung und baut anschließend eine separate Backend-Verbindung auf. Ohne zusätzliche Information kennt das Backend daher nur die Adresse der Edge. Das gilt auch dann, wenn die ursprüngliche Client-IP in der Edge selbst bekannt ist.

Das Proxy Protocol kann diese Information an den Beginn der neuen Backend-Verbindung setzen. Der Backend-Listener muss das Präfix lesen und danach das erwartete Protokoll an den zuständigen Dienst weiterreichen. Bei HTTP bedeutet das: Erst kommt das Proxy-Protocol-Präfix, danach folgen Request Line und Header. Bei einer verschlüsselten Backend-Verbindung muss die Verarbeitung zur gewählten TLS-Architektur passen.

Proxy Protocol und HTTP-Header wie X-Forwarded-For sind nicht dasselbe. Header gehören zur Anwendungsschicht und müssen vom HTTP-Stack ausgewertet werden. Das Proxy Protocol liegt davor und kann auch dann sinnvoll sein, wenn ein vorgeschalteter TCP-Listener, Ingress oder Service Mesh die Verbindung zunächst auf Transportebene übernimmt. Die Entscheidung hängt deshalb vom tatsächlichen Backend-Pfad ab, nicht allein davon, ob der öffentliche Dienst HTTP nutzt.

4. Der Integrationsvertrag zwischen Edge und Backend

Die Aktivierung des Proxy Protocols ist nur dann erfolgreich, wenn beide Seiten dieselben Erwartungen haben. Zur technischen Abstimmung gehören mindestens der Listener-Typ, die Protokollvariante, das Transportprotokoll, der Port und die Frage, an welcher Stelle die Information entfernt oder weitergereicht wird.

Ein häufiger Fehler ist die Aktivierung am Edge-Service, während der Backend-Dienst weiterhin ein unverändertes HTTP- oder TLS-Protokoll erwartet. Der Dienst interpretiert die ersten Bytes des Proxy-Präfixes dann als Nutzdaten. Umgekehrt verwirft ein Proxy- oder Ingress-Listener ohne Proxy-Protocol-Unterstützung eine Verbindung, wenn er die zusätzliche Präambel nicht verarbeiten kann.

Auch Health Checks müssen berücksichtigt werden. Ein Backend kann reguläre Verbindungen mit Proxy Protocol akzeptieren, aber Prüfverbindungen anders behandeln. Für einen stabilen Betrieb müssen Health Checks denselben relevanten Verbindungsbedingungen entsprechen wie der produktive Traffic. Logging- und Security-Systeme sollten außerdem dokumentieren, aus welcher vertrauenswürdigen Quelle die Client-IP stammt. Nur dann bleibt die Information über mehrere Backend-Verbindungen hinweg belastbar.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt einen HTTPS-Service auf einem Kubernetes-Cluster außerhalb von ayedo Managed Kubernetes. Die ayedo Edge Cloud übernimmt TLS Termination und leitet Requests an einen Ingress im Cluster weiter. Für Security-Logs und IP-basierte Zugriffskontrollen muss der Ingress die ursprüngliche Client-IP erhalten.

Eine mögliche Umsetzung ist die Übergabe per HTTP-Header. Dafür muss der gesamte HTTP-Pfad diese Header vertrauenswürdig behandeln. Alternativ nimmt ein vorgelagerter Listener das Proxy Protocol entgegen und reicht die Verbindung anschließend an den HTTP-Ingress weiter. Dieser Ansatz kann sinnvoll sein, wenn die Client-Information bereits vor der HTTP-Verarbeitung benötigt wird. Entscheidend ist, dass genau ein dafür konfigurierter Einstiegspunkt das Präfix verarbeitet. Wird es zusätzlich an einen nicht dafür vorgesehenen Dienst weitergereicht, schlägt der Request fehl.

FAQ

Ersetzt das Proxy Protocol X-Forwarded-For?

Nein. Das Proxy Protocol überträgt Metadaten vor dem Anwendungsprotokoll. X-Forwarded-For ist ein HTTP-Header. Welche Variante geeignet ist, hängt davon ab, an welcher Stelle im Backend die Client-IP benötigt und verarbeitet wird.

Funktioniert Proxy Protocol mit TLS-Passthrough?

Grundsätzlich kann es vor einer TLS-Verbindung eingesetzt werden. Der empfangende Listener muss das Proxy-Protocol-Präfix jedoch vor dem TLS-Handshake verarbeiten und die Verbindung anschließend korrekt an den TLS-Dienst weitergeben.

Kann jedes Backend die Client-IP direkt auswerten?

Nein. Der konkrete Listener, Reverse Proxy, Ingress oder Dienst muss Proxy Protocol unterstützen und aktiviert haben. Andernfalls wird das Präfix als unbekannte oder ungültige Nutzlast behandelt.

Fazit

Das Proxy Protocol ist kein Schalter für „bessere Logs“, sondern ein verbindlicher Bestandteil der Verbindung zwischen Edge und Backend. Im L4-Betrieb schützt es die Client-Information über transportbasierte Weiterleitungen hinweg; im L7-Betrieb ergänzt es die neu aufgebaute Backend-Verbindung nach Termination. Die ayedo Edge Cloud kann diese Information an Backend-Verbindungen weitergeben – zuverlässig wird das Ergebnis aber erst durch einen passend konfigurierten und abgesicherten Backend-Listener.