Proxy Protocol im Backend-Pool korrekt einsetzen

TL;DR

Proxy Protocol überträgt Verbindungsinformationen aus einem Proxy- oder Loadbalancing-Layer an das Backend. Damit können Anwendungen die ursprüngliche Client-IP und weitere Transportdaten auswerten. Voraussetzung sind ein abgestimmtes Protokoll, kompatible Listener und eine konsistente Konfiguration im gesamten Backend-Pool.

Einleitung

Proxy Protocol ist kein optionales Detail im Loadbalancing, sondern ein Integrationsvertrag zwischen Edge und Backend. Wird es an der ayedo Edge Cloud aktiviert, erwartet jedes Zielsystem im entsprechenden Backend-Pool die zusätzliche Protokollzeile vor der eigentlichen Anwendungskommunikation. Ein gewöhnlicher TCP- oder HTTP-Listener kann diese Daten nicht automatisch interpretieren. Die Folge sind abgewiesene Verbindungen, fehlerhafte Client-IP-Auswertung oder schwer nachvollziehbare Unterschiede zwischen einzelnen Backends. Entscheidend ist daher nicht nur, ob Proxy Protocol grundsätzlich unterstützt wird. Entscheidend ist, ob Edge, Protokolltyp, Listener und Anwendung dieselbe Annahme über den Verbindungsaufbau teilen.

1. Welche Informationen Proxy Protocol weitergibt

Ein Proxy beendet die ursprüngliche TCP-Verbindung des Clients und baut zum Backend eine neue Verbindung auf. Ohne zusätzliche Metadaten sieht das Backend deshalb zunächst die Quelladresse des Edge-Systems. Für Zugriffskontrollen, Rate Limits, Audit-Logs oder forensische Analysen kann diese Information unzureichend sein.

Proxy Protocol ergänzt die neue Verbindung um Verbindungsinformationen der ursprünglichen Sitzung. Dazu gehören typischerweise Quell- und Zieladresse sowie die verwendeten Ports. Das Backend kann dadurch zwischen Edge-Verbindung und ursprünglichem Client unterscheiden, ohne diese Informationen aus anwendungsspezifischen Headern ableiten zu müssen.

Wichtig ist die Abgrenzung zu HTTP-Headern wie X-Forwarded-For: Proxy Protocol arbeitet auf der Transportebene und ist deshalb auch für TCP-Dienste relevant. Es ersetzt jedoch keine Authentisierung und beweist nicht, dass die übermittelten Daten aus einer vertrauenswürdigen Quelle stammen. Das Backend muss Proxy Protocol nur auf dem dafür vorgesehenen, kontrollierten Eingang akzeptieren.

2. Der Backend-Pool als Protokollvertrag

Die Aktivierung von Proxy Protocol ist eine Eigenschaft des Zusammenspiels aus Edge und Backend-Pool. Die ayedo Edge Cloud kann Verbindungen per Proxy Protocol an Backends weitergeben. Ob diese Verbindungen erfolgreich verarbeitet werden, hängt anschließend vom Listener des jeweiligen Zielsystems ab.

Ein Backend-Pool sollte deshalb nicht nur nach Erreichbarkeit, Port und Health Check modelliert werden. Auch die erwartete Verbindungsform gehört zur Pool-Definition. Alle Ziele eines Pools müssen denselben Protokollvertrag erfüllen: Sie müssen Proxy Protocol am verwendeten Listener akzeptieren und die nachfolgenden Daten korrekt an den Dienst weiterreichen.

Ein häufiger Fehler ist die Mischung inkompatibler Ziele. Ein Pool enthält beispielsweise einen für Proxy Protocol konfigurierten Ingress und zusätzlich einen direkten TCP-Dienst. Der Loadbalancer kann beide Ziele technisch erreichen, aber nur eines versteht den Verbindungsbeginn. Health Checks können dabei irreführend sein, wenn sie einen anderen Listener oder eine andere Prüfmethodik verwenden als der reale Traffic. Protokollkompatibilität muss daher ausdrücklich getestet werden.

3. Protokollkompatibilität entlang der Verbindung

Proxy Protocol wird vor der eigentlichen Nutzlast übertragen. Der empfangende Listener muss diese Information erkennen, verarbeiten und anschließend den ursprünglichen Datenstrom an die Anwendung weitergeben. Ist der Listener ausschließlich für unveränderte TLS-, HTTP- oder proprietäre TCP-Daten ausgelegt, interpretiert er den Proxy-Header als ungültige Nutzlast.

Das betrifft mehrere Schichten: den externen Listener des Ingress, einen möglichen Sidecar oder Reverse Proxy und den eigentlichen Anwendungsprozess. Bereits eine nicht kompatible Zwischenkomponente kann die Verbindung abbrechen. Bei TLS ist besonders wichtig, dass Proxy Protocol vor dem TLS-Handshake ankommt und der TLS-Listener diese Reihenfolge unterstützt. Proxy Protocol verschlüsselt die Metadaten nicht selbst.

Auch die eingesetzte Variante muss zusammenpassen. Die textbasierte und die binäre Variante unterscheiden sich in Aufbau und Parser-Verhalten. Wird am Edge eine Variante erwartet, die der Listener nicht unterstützt, entsteht kein belastbarer Fallback. Deshalb gehören Protokollvariante, Transporttyp und Listener-Verhalten in die technische Schnittstellenbeschreibung des Dienstes.

4. Betriebsfehler systematisch vermeiden

Die häufigsten Fehler entstehen durch Konfigurationsänderungen ohne Pool-weite Betrachtung. Wird Proxy Protocol am Edge aktiviert, aber nur ein Teil der Backends angepasst, erscheinen Ausfälle zunächst wie zufällige Health- oder Netzwerkprobleme. Tatsächlich hängt die Verfügbarkeit dann davon ab, welches Ziel der Loadbalancer auswählt.

Für den Betrieb sind getrennte Pools mit eindeutigem Protokollverhalten meist robuster als ein gemischter Pool. Migrationen sollten schrittweise erfolgen: zunächst einen kompatiblen Listener bereitstellen, anschließend mit realistischen Verbindungen testen und erst danach weitere Ziele aufnehmen. Logs müssen den Verbindungsaufbau am Listener, die erkannte Client-Adresse und mögliche Parserfehler sichtbar machen.

Besondere Aufmerksamkeit verdient die Vertrauensgrenze. Ein Backend darf die im Proxy Protocol enthaltene Quelladresse nur dann für Sicherheitsentscheidungen verwenden, wenn ausschließlich bekannte Edge-Pfade diesen Listener erreichen können. Wird derselbe Port direkt aus dem Internet oder aus unkontrollierten Netzen zugänglich, kann ein Angreifer falsche Verbindungsinformationen einspeisen. Proxy Protocol verbessert damit die Transparenz, ersetzt aber keine Netzwerksegmentierung und keine Zugriffskontrolle.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt einen HTTPS-Service auf Kubernetes und einen TCP-basierten Legacy-Dienst auf virtuellen Maschinen. Beide sollen über die ayedo Edge Cloud erreichbar sein. Für den HTTPS-Service wird ein Ingress eingesetzt, dessen Listener Proxy Protocol versteht. Der Legacy-Dienst verwendet dagegen weiterhin einen Standard-TCP-Listener.

Beide Zielsysteme in einem gemeinsamen Backend-Pool zu führen, wäre falsch: Die ayedo Edge Cloud würde denselben Verbindungsaufbau an unterschiedliche Listener liefern. Stattdessen werden getrennte Pools mit jeweils passender Protokollvereinbarung definiert. Der HTTPS-Pool verarbeitet Proxy Protocol bis zum kompatiblen Ingress; der Legacy-Pool erhält nur Verbindungen, deren Zielsystem den vereinbarten Transport tatsächlich unterstützt. Ein eigener Health Check pro Pool prüft zusätzlich den richtigen Listener und nicht nur die Erreichbarkeit des Hosts.

FAQ

Ist Proxy Protocol nur für HTTP-Dienste relevant?

Nein. Proxy Protocol arbeitet auf der Transportebene und kann auch TCP-Dienste mit ursprünglichen Verbindungsinformationen versorgen. Der jeweilige Listener muss das Protokoll jedoch explizit unterstützen.

Kann Proxy Protocol durch HTTP-Header ersetzt werden?

Bei HTTP können Forwarding-Header Clientinformationen übertragen. Das ist aber nicht gleichwertig für TCP-Dienste und erfordert Vertrauen in die Header-Kette. Proxy Protocol liegt unterhalb der Anwendungsschicht.

Warum funktionieren Health Checks trotz fehlerhaftem Proxy Protocol?

Ein Health Check kann einen anderen Port, Listener oder Verbindungsaufbau verwenden als der produktive Traffic. Erreichbarkeit allein bestätigt daher nicht, dass der Backend-Dienst Proxy Protocol korrekt verarbeitet.

Fazit

Proxy Protocol ist ein klar zu definierender Integrationspunkt zwischen Edge-Proxy und Backend-Dienst. Die technische Frage lautet nicht nur, ob Client-IP-Informationen benötigt werden, sondern welcher Listener sie in welcher Form und unter welcher Vertrauensgrenze verarbeitet. In der ayedo Edge Cloud gehört diese Entscheidung zur Abstimmung des Backend-Pools. Sauber getrennte Pools, kompatible Listener und passende Health Checks verhindern, dass aus einer kleinen Protokollabweichung ein intermittierendes Betriebsproblem wird.