Methoden zur Ermittlung der Client-Quell-IP

In bestimmten Situationen erfordern unsere Dienste die Verwendung der Client-IP aus spezifischen geschäftlichen oder sicherheitsrelevanten Gründen. In der Regel durchläuft der Datenverkehr jedoch mehrere Netzwerke, Load Balancer oder Proxy-Dienste, bevor er den eigentlichen Dienst erreicht. Auf jeder Ebene dieses Prozesses kann die ursprüngliche Client-IP verloren gehen, sodass unser Dienst nur die IP des vorherigen Netzwerks erhält. Dieses Ergebnis ist für uns nicht ideal.

Aufgrund der komplexen Natur unseres Technologie-Stacks erfordert das Ermitteln der Client-IP verschiedene Methoden, manchmal in Kombination.

Verwaltung der Client-IP über NAT

In bestimmten IDC-Infrastrukturen, die von Benutzern eingerichtet oder gemietet wurden, können unsere Dienste in einem separaten LAN-Netzwerk hinter einem Gateway liegen. Wenn Clients versuchen, von einem externen Netzwerk aus eine Verbindung zu unseren Diensten herzustellen, wird der Datenverkehr über das Gateway geleitet.

Ein ähnliches Szenario kann auftreten, wenn Cloud-Dienste genutzt werden. Das VPC-Netzwerk, das von öffentlichen Cloud-Plattformen bereitgestellt wird, fungiert als unabhängiges LAN-Netzwerk, das von anderen VPCs und dem Internet isoliert ist. Daher ist ein Gateway erforderlich, um den Zugang zum externen Internet und die Verbindung zu externen Diensten zu ermöglichen.

Dieses Gateway, das ein Router oder ein Firewall-Gerät sein könnte, bietet in der Regel DNAT (Destination NAT)-Adressübersetzungsdienste für interne Dienste an. Dabei hält das Gateway eine oder mehrere öffentliche IP-Adressen und leitet den Datenverkehr von bestimmten Ports der öffentlichen IP an bestimmte Ports einer internen IP weiter. Das Gateway verwaltet die Datenverkehrsweiterleitung und Port-Zuordnung. Aufgrund der Änderung der Quelladresse im ursprünglichen IP-Paketheader durch das Gateway können unsere Dienste innerhalb des internen Netzwerks jedoch nur die IP-Adresse des Gateways identifizieren, nicht die tatsächliche Client-Adresse.

Historisch gesehen waren die DNAT-Fähigkeiten, die von Netzwerkgeräten oder Software bereitgestellt wurden, relativ einfach. Sie arbeiteten hauptsächlich auf Schicht 3 und verfügten nicht über die Fähigkeit, tiefer liegende Nutzdaten zu erkennen oder zu manipulieren. Ihr Hauptzweck war die Bereitstellung von Diensten, und sie konnten die Client-IP nicht an nachgelagerte Komponenten weitergeben. Aufgrund der Leistungsbeschränkungen dieser Geräte oder Software gab es zudem Einschränkungen hinsichtlich der Anzahl aktiver Verbindungen und der maximalen Anzahl neuer Verbindungen, die sie verarbeiten konnten. Eine Skalierung ohne Hardware-Upgrades war oft schwierig, was sie weniger anpassungsfähig an die dynamische Umgebung von heute machte.

Um diese Einschränkungen zu überwinden, greifen wir auf Load Balancing zurück, das über fortschrittlichere Fähigkeiten zur Datenverkehrsmanipulation verfügt.

Client-IP im Load Balancing

Im Allgemeinen wird Load Balancing basierend auf der Arbeitsschicht in zwei Haupttypen unterteilt: Schicht 4 und Schicht 7, die jeweils TCP-Datenströmen und Anwendungsdatenverkehr (repräsentiert durch HTTP) entsprechen.

Im Gegensatz zu IP-Gateways modifiziert Load Balancing den IP-Paketheader nicht. Auf der Ebene des IP-Pakets erfolgt lediglich eine transparente Weiterleitung. Daher wird im Gegensatz zum zuvor diskutierten DNAT sichergestellt, dass die im IP-Paket enthaltene Quell-IP korrekt an die Komponenten hinter dem Load Balancer weitergegeben wird.

Bei Schicht-4-Load-Balancing können nach der grundlegenden Datenverkehrsweiterleitung nachgelagerte Dienste die Client-IP korrekt abrufen, ohne dass eine spezielle Verarbeitung erforderlich ist. In Ausnahmefällen kann das Proxy Protocol genutzt werden. Dabei wird vor der ursprünglichen Nutzlast des Datenverkehrs ein neuer Abschnitt hinzugefügt, der die Client-IP enthält. Andere Reverse-Proxy-Server oder der Dienst selbst hinter dem Load Balancer können dann die Proxy-Protocol-Daten interpretieren, um die Client-IP zu erhalten.

Bei Schicht-7-Load-Balancing bestehen tiefergehende Fähigkeiten zur Datenverarbeitung. Es kann die Quell-IP direkt auf der Ebene des HTTP-Protokolls übermitteln. Ein verbreiteter Ansatz ist die Verwendung des X-Forwarded-For HTTP-Headers. Die Load-Balancing-Komponente extrahiert die Quell-IP aus dem IP-Paket des Datenverkehrs, analysiert und überschreibt dann die HTTP-Anfrage. Dabei wird ein neues XFF-Feld in den Anfrageheader eingefügt, das den Wert der Client-IP enthält.

HTTPS stellt aufgrund seiner verschlüsselten Nutzlast eine besondere Herausforderung dar, da die Load-Balancing-Komponente die HTTP-Header nicht direkt manipulieren kann. In solchen Situationen können die folgenden Ansätze in Betracht gezogen werden:

• Ohne spezifische Anforderungen kann HTTPS-Datenverkehr als standardmäßiger TLS-Datenverkehr behandelt und direkt auf Schicht 4 weitergeleitet werden. In diesem Szenario kann die Client-IP weiterhin über den IP-Paketheader an den Dienst hinter dem Load Balancer übermittelt werden.

• Wenn Schicht-7-Funktionalität erforderlich ist, ermöglicht das Hosting des TLS-Zertifikats auf der Load-Balancing-Komponente die TLS-Terminierung. Dabei wird die TLS-Verschlüsselung auf der Load-Balancing-Schicht entfernt, und es wird entweder unverschlüsseltes HTTP im LAN hinter dem Load Balancer verwendet oder eine neue HTTPS-Verbindung zum Dienst hergestellt, anstatt den Datenverkehr direkt weiterzuleiten. Dies ermöglicht es der Load-Balancing-Komponente, erneut den ursprünglichen HTTP-Datenverkehr zu verarbeiten und die IP weiterhin über die XFF-Methode zu übermitteln.

Durch differenzierte Datenverkehrsbehandlung bietet Load Balancing verschiedene Methoden, um die Client-IP an den Backend-Dienst zu übermitteln. Repräsentative Implementierungen von Load-Balancing-Komponenten umfassen cloudbasierte ELB-Dienste, hardwarebasierte F5 BIG-IP, Linux Virtual Server (LVS) basierend auf dem Linux-Kernel und benutzersoftwarebasierte NGINX.

Übermittlung der Client-IP in CDN-Diensten

Gelegentlich nutzen wir CDN-Dienste, die von öffentlichen Cloud-Plattformen bereitgestellt werden, um die Geschwindigkeit des Benutzerzugriffs auf unsere Dienste zu erhöhen. Ihre Funktionsweise ähnelt der eines Schicht-7-Reverse-Proxy-Servers, aber in einem breiteren Kontext können CDNs als Teil des Load-Balancing-Bereichs betrachtet werden.

CDN-Dienste bieten in der Regel TLS-Terminierungsfunktionen und können die Client-IP in HTTP-Anfragen einbeziehen, die an den Dienst gesendet werden. Beispielsweise unterstützt der AWS CloudFront CDN-Dienst die Übermittlung der Client-IP über die XFF-Methode, ähnlich dem Ansatz, der bei Schicht-7-Load-Balancing verwendet wird.

Nutzung von API-Gateways

Während Load-Balancing-Komponenten in der Regel grundlegende Kontrollfunktionen für den Datenverkehr bieten, können die APIs, die von cloudbasierten oder hardwarebasierten Load Balancern bereitgestellt werden, schwer mit unseren spezifischen geschäftlichen Anforderungen in Einklang gebracht werden. In solchen Szenarien greifen wir auf anpassungsfähigere Komponenten zurück, um maßgeschneiderte Strategien auf unsere Dienste anzuwenden. Hier kommt ein API-Gateway wie Apache APISIX oder API7 Enterprise ins Spiel.

APISIX und API7 Enterprise unterstützen das Proxy Protocol, wodurch die Client-IP vom Load Balancer abgerufen werden kann.

Darüber hinaus verfügen sie über ein Plugin namens "real-ip", das dem ngx_http_realip_module von NGINX ähnelt. Dieses Plugin holt die IP des Clients aus einer Quelle und verwendet sie für die Weiterleitung und Protokollierung. Das real-ip-Plugin auf APISIX und API7 Enterprise erweitert die Funktionalität, die auf NGINX verfügbar ist. Es ermöglicht die dynamische Aktivierung oder Deaktivierung der Funktion für die echte Quell-IP und erweitert die Quellen der Client-IP über die Einschränkungen des ngx_http_realip_module hinaus, das auf HTTP-Header und das Proxy Protocol beschränkt ist. Es kann jede NGINX- oder APISIX-erweiterte Variable nutzen, wie z. B. Abfrageparameter oder POST-Formularfelder.

Zusammenfassung

Durch die Nutzung einer Kombination von Technologien auf verschiedenen Ebenen können wir die Client-IP effektiv durch jede Komponente des Dienstes weitergeben, um sowohl geschäftliche als auch sicherheitsrelevante Anforderungen zu erfüllen.

Um mehr über API-Management-Lösungen zu erfahren, kontaktieren Sie API7.ai.