Proxy-Protokoll-Header auf ELB wiederverwenden

Question

Ich kann turn on Proxy Protocol on ELB.

Aber in meinem Fall möchte ich Proxy-Protokoll-Header auf ELB wiederverwenden. Ist es möglich?

Ich meine, ich sende eine Anfrage mit Proxy-Protokoll-Header bereits auf ELB gesetzt. Und ich möchte, dass ELB diesen speziellen Header übernimmt und weitergibt. Kein neues erzeugen (bei dem sich Quelle/Port vom Original unterscheiden).

Answer 1

Bezug auf die "Header" ist nicht technisch ungenau, aber ist möglicherweise etwas irreführende oder mehrdeutige Terminologie.

Es ist ein "Header" in dem Sinne, dass es am Anfang einer Verbindung ankommt, aber es ist kein HTTP-Request-Header, im Gegensatz zu der bekannten X-Forwarded-For, die natürlich ein HTTP-Request-Header ist.

Elegant in seiner Einfachheit, Version 1 dieses Protokolls injiziert eine Nachricht zu Beginn einer TCP-Verbindung:

PROXY TCP4 192.168.0.1 192.168.0.11 56324 443\r\n 

Die Felder sind Protokoll (TCP über IPv4), Quelle-IP, Ziel-IP, Quell-Port, Ziel-Port, getrennt durch jeweils genau ein Leerzeichen.

Wenn das Protokoll PROXY in einem Stapel verwendet wird, ist es obligatorisch. Eine fehlende oder fehlerhafte PROXY Nachricht zu Beginn einer Verbindung ist eine Fehlerbedingung. Die Existenz einer Nachricht PROXY führt zu einer Vertrauensstufe, die höher ist als diejenige, die von X-Forwarded-For bereitgestellt wird, die mit der Änderung übergeben wird (spätere Werte, die an frühere Werte angehängt wurden). Das Protokoll PROXY macht keine offizielle Genehmigung für die Kaskadierung mehrerer Werte.

Wenn Sie ELB benötigen, um diesen Wert "innerhalb" zu transportieren, dann ist es wichtig, dass die Ingress-Sicherheitsgruppe des ELB nur auf Anforderungen von vertrauenswürdigen Quelladressen beschränkt ist.

Sobald dies geschehen ist, tl; dr:

Konfigurieren des ELB Zuhörer im TCP-Modus (nicht HTTP) und Deaktivieren von Proxy-Protokoll auf der ELB selbst wird das Original, externe PROXY Nachricht ermöglichen, durch transportiert werden die Systeme hinter dem ELB.

Es ist nicht möglich, dies mit einem ELB im HTTP-Modus zu übergeben, da ELB dies bei Anfragen nicht erwartet und die Back-End-Verbindung für Anfragen mehrerer Front-End-Clients wiederverwendet werden kann ist nicht grundsätzlich kompatibel mit dem Proxy-Protokoll - es wurde entwickelt, um die IP-Quelladresse und den Port einer eingehenden Verbindung des Client-Rechners zu identifizieren (nicht die Quell-IP und -Port einer HTTP-Anfrage) ... und wie erwähnt kein HTTP-Anfrage-Header.

Die Idee hinter dem Protokoll PROXY besteht darin, den ursprünglichen Client über einen Stapel von Komponenten zu identifizieren, die nicht für die Nutzlast geeignet sind. In diesem Fall muss ELB diesem Modell folgen. (Es ist natürlich möglich, dass eine Zwischenkomponente diese Nachricht abzieht und dann erneut injiziert, obwohl dies in vielen Fällen etwas sinnlos wäre und ELB diese Konfiguration nicht unterstützt.)

Im TCP-Modus wird der ELB protokollunabhängig und es besteht eine 1: 1-Beziehung zwischen Front-Side- und Backside-Verbindungen, so dass die Nachricht wie erwartet ankommen und funktionieren sollte.

Ein möglicher Nachteil, der zu beachten ist, kann davon abhängen, wie ELB die Paketnutzlast im TCP-Modus verarbeitet. Das Proxy-Protokoll erfordert, dass die gesamte Nachricht im ersten Datenpaket vorhanden ist. (Das Protokoll ist sogar so entworfen, dass es garantiert, dass die Daten immer in ein einzelnes Segment passen.) Wenn ELB dies jemals fragmentiert, muss das Ziel tolerant sein. Dies scheint kein Problem zu sein, aber berücksichtigen Sie die Möglichkeit, wenn das endgültige Ziel intermittierend eingehende Datenströme für ungültig hält.