Proxy Protocol im L4-Loadbalancing korrekt einsetzen

TL;DR

Beim L4-Loadbalancing endet die ursprüngliche Client-Verbindung häufig an der Edge. Das Backend sieht dann zunächst nur die IP-Adresse des Loadbalancers. Das Proxy Protocol überträgt die ursprünglichen Verbindungsdaten als vorgelagerte Metainformation. Damit das zuverlässig funktioniert, müssen Edge, Zielprotokoll und Backend dieselbe Erwartung an Format, Position und Vertrauensgrenze haben.

Einleitung

Ein L4-Loadbalancer kann eine TCP-Verbindung annehmen und anschließend eine neue Verbindung zum Backend aufbauen. Aus Sicht des Backends ist der direkte Kommunikationspartner dann nicht mehr der ursprüngliche Client, sondern die Loadbalancing-Schicht. Für Logging, Zugriffskontrolle, Rate Limiting oder forensische Analysen fehlt damit eine zentrale Information: die originale Client-IP.

Das Proxy Protocol löst dieses Problem nicht durch Änderung des eigentlichen Anwendungsprotokolls, sondern durch einen Verbindungsheader vor dessen Nutzdaten. Genau darin liegt zugleich die wichtigste Einschränkung: Der Empfänger muss diesen Header erwarten und korrekt verarbeiten. Wird die Übergabe nur auf einer Seite aktiviert, scheitert die Verbindung oder das Protokoll wird als ungültige Nutzlast interpretiert.

1. Welche Information das Proxy Protocol überträgt

Beim klassischen L4-Loadbalancing werden Transportverbindungen getrennt betrachtet. Die Edge nimmt die Verbindung des Clients an, entscheidet anhand von Routing- und Health-Check-Informationen über ein Backend und stellt dorthin eine eigene Backend-Verbindung her. TCP überträgt die ursprüngliche Quelladresse nicht automatisch über diese Grenze hinweg.

Das Proxy Protocol ergänzt deshalb den Beginn der Backend-Verbindung um Verbindungsmetadaten. Dazu gehören typischerweise Quell- und Zieladresse sowie die verwendeten Ports und das Transportprotokoll. Das Backend kann dadurch zwischen der tatsächlichen Client-IP und der IP-Adresse der Edge unterscheiden.

Wichtig ist die Abgrenzung zu HTTP-Headern wie X-Forwarded-For: Diese funktionieren auf Layer 7 und setzen voraus, dass ein HTTP-Proxy die Anfrage versteht. Proxy Protocol wird dagegen vor dem eigentlichen Protokoll übertragen und eignet sich deshalb auch für TCP-basierte Dienste oder TLS-Passthrough. Es ersetzt jedoch keine Authentisierung der Anwendung und ist keine eigenständige Sicherheitskontrolle.

2. Die Protokollgrenze zwischen Edge und Backend

Das Proxy Protocol ist kein Bestandteil von TCP selbst. Es wird als zusätzliche Information am Anfang der vom Loadbalancer zum Backend aufgebauten Verbindung übertragen. Der erste Empfänger auf dem Backend-Pfad muss diese Information lesen, bevor er das eigentliche Protokoll verarbeitet.

Das erzeugt eine klare Kompatibilitätsanforderung. Ein Webserver, Datenbankdienst, Ingress oder vorgeschalteter Proxy muss für Proxy Protocol konfiguriert sein. Erwartet der Dienst direkt einen TLS-Handshake, HTTP-Daten oder ein anderes binäres Protokoll, kann der zusätzliche Header als fehlerhafte Nutzlast erscheinen. Besonders relevant ist das bei TLS-Passthrough: Der Backend-TLS-Endpunkt muss den Proxy-Header vor dem ClientHello akzeptieren.

Auch die eingesetzte Variante muss zusammenpassen. Textbasierte und binäre Ausprägungen unterscheiden sich in Format und Parserverhalten. Die Edge und der unmittelbar empfangende Dienst müssen daher dieselbe Variante unterstützen. Ein nachgelagerter Proxy darf den Header außerdem nicht versehentlich erneut als normale Nutzlast weiterreichen.

3. Client-IP, Logging und Sicherheitsgrenzen

Die weitergegebene Client-IP ist nur dann vertrauenswürdig, wenn das Backend die Quelle der Verbindung kontrolliert. Ein öffentlich erreichbarer Dienst, der Proxy-Protocol-Header von beliebigen Clients akzeptiert, kann manipulierte Ursprungsdaten übernehmen. Backend Cloaking und passende Netzwerkregeln sind deshalb wichtige Begleitmaßnahmen: Die Anwendung sollte Verbindungen möglichst nur von den vorgesehenen Edge-Systemen annehmen.

Für das Logging muss klar definiert sein, welche Adresse dokumentiert wird. Die Transport-Peer-IP bleibt die Adresse der Edge und kann für Netzwerk- und Verbindungsdiagnose relevant sein. Die im Proxy Protocol enthaltene Adresse beschreibt dagegen den ursprünglichen Client. Beide Werte sollten nicht semantisch vermischt werden.

Zudem sollten nachgelagerte Komponenten die Information nur innerhalb der vorgesehenen Vertrauenszone weiterverwenden. Eine Anwendung darf die Client-IP etwa für Auditdaten oder Policy-Entscheidungen nutzen, aber nicht automatisch als authentifizierte Identität behandeln. Werden mehrere Proxies verkettet, muss feststehen, welcher Hop den Header erzeugt und welcher ihn auswertet.

4. Betrieb und Integration im L4-Loadbalancing

Die Aktivierung von Proxy Protocol ist eine Ende-zu-Ende-Änderung für die Backend-Verbindung. Ein einzelner Listener oder ein einzelnes Backend kann nicht isoliert betrachtet werden. Bei Failover, Rolling Updates und parallelen Backend-Pools müssen alle potenziellen Ziele dieselbe Erwartung erfüllen. Andernfalls führt der Wechsel auf einen anderen Pool zu schwer erklärbaren Protokollfehlern.

Für die Inbetriebnahme empfiehlt sich ein schrittweises Vorgehen: Zuerst wird der tatsächliche Verbindungsweg dokumentiert, danach der empfangende Dienst identifiziert und anschließend die Header-Verarbeitung gezielt getestet. Ein Paketmitschnitt oder verbindungsnahes Debugging kann zeigen, ob der Header ankommt; die Anwendungseinstellungen entscheiden jedoch, ob er korrekt interpretiert wird.

Die ayedo Edge Cloud unterstützt Proxy Protocol im Rahmen ihres L4-Loadbalancings. Damit lässt sich die ursprüngliche Verbindungsinformation auch bei einer providerunabhängigen Nutzung vor eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern an das Backend übergeben. Entscheidend bleibt, dass der jeweilige Service oder Ingress die gewählte Übergabe unterstützt und nur aus der vertrauenswürdigen Edge-Zone erreichbar ist.

Praxisszenario: TCP-Service hinter einer verteilten Edge

Ein Unternehmen betreibt einen TCP-basierten Dienst in zwei Kubernetes-Clustern unterschiedlicher Provider. Die ayedo Edge Cloud verteilt eingehende Verbindungen per Anycast auf den geeigneten Backend-Pool. Ohne Proxy Protocol protokolliert der Dienst als Quelladresse nur die Edge-Verbindung. Für Kapazitätsanalyse und Abuse-Untersuchungen ist das unzureichend.

Mit aktiviertem Proxy Protocol liest der erste TCP-fähige Empfänger den Header und reicht die eigentlichen Nutzdaten anschließend an den Dienst weiter. Beide Cluster müssen dieselbe Variante akzeptieren; ein direkter Testzugriff ohne Header muss ausgeschlossen oder separat behandelt werden. Fällt ein Pool aus, muss auch der Failover-Pfad kompatibel sein. Die Architektur gewinnt damit verwertbare Client-Metadaten, ohne das anwendungsseitige Protokoll selbst umzubauen.

FAQ

Ist Proxy Protocol nur für HTTP geeignet?

Nein. Es arbeitet vor dem Anwendungsprotokoll und kann auch TCP-Dienste oder TLS-Passthrough unterstützen. Der jeweilige Backend-Endpunkt muss den Header jedoch explizit verarbeiten können.

Ersetzt Proxy Protocol X-Forwarded-For?

Nein. X-Forwarded-For ist ein HTTP- beziehungsweise Layer-7-Mechanismus. Proxy Protocol überträgt Verbindungsdaten bereits an der Layer-4-Grenze und ist nicht auf HTTP angewiesen.

Muss jedes Backend Proxy Protocol unterstützen?

Jeder erste Empfänger einer so aufgebauten Backend-Verbindung muss es unterstützen oder vorher entfernen. Andernfalls interpretiert der Dienst den Header als ungültige Protokolldaten.

Fazit

Proxy Protocol ist eine präzise Lösung für ein typisches Problem getrennter TCP-Verbindungen: Das Backend erhält Informationen über den ursprünglichen Client, obwohl die Edge die Verbindung terminieren und neu aufbauen muss. Der Nutzen entsteht aber nur mit einer konsistenten Vertrauenskette aus Edge, Protokollvariante, Backend und Netzwerkzugriff. Im L4-Loadbalancing der ayedo Edge Cloud ist diese Übergabe besonders relevant, wenn Dienste unabhängig vom Compute-Provider betrieben werden und ihre Client-IP weiterhin auswerten müssen.