IP-Transparenz und direkte Serverrückgabe mit NGINX und NGINX Plus als transparenter Proxy

In diesem Blogbeitrag wird beschrieben, wie NGINX Open Source und NGINX Plus als transparenter Proxy für den Datenverkehr zu Upstream-Servern konfiguriert werden. Es wird erläutert, wie Sie mit einem transparenten Proxy die Quell-IP-Adresse von Paketen fälschen und so IP-Transparenz implementieren können und wie Sie einen Lastenausgleichsmodus namens „Direct Server Return“ für UDP-Verkehr implementieren können.

Die Informationen in diesem Beitrag gelten sowohl für NGINX Open Source als auch für NGINX Plus . Der Kürze halber beziehen wir uns nur auf NGINX Plus.

Herausgeber – Dies ist der fünfte Beitrag in einer Reihe von Blogbeiträgen, die sich eingehend mit den neuen Funktionen in NGINX Plus R10 befassen.

• Authentifizieren von API-Clients mit JWT und NGINX Plus
• NGINX Plus R10 nutzt die Leistung von IBM
• Authentifizieren von Benutzern bei vorhandenen Anwendungen mit OpenID Connect und NGINX Plus
• Verwenden des NGINX-JavaScript-Moduls zum schrittweisen Umstellen von Clients auf einen neuen Server
• IP-Transparenz und direkte Serverrückgabe mit NGINX und NGINX Plus als transparenter Proxy (dieser Beitrag)

Schauen Sie sich auch unbedingt das On-Demand-Webinar „ Was ist neu in NGINX Plus R10?“ an.

Zusammenfassung

NGINX Plus fungiert als Layer-7-Reverse-Proxy. Dadurch kann NGINX Plus eine Reihe von Optimierungen und Verbesserungen auf die von ihm verwalteten Netzwerkanforderungen anwenden.

Infolgedessen stellen Upstreamserver (mit Lastenausgleich) sicher, dass der gesamte Datenverkehr von einer IP-Adresse auf dem NGINX Plus-Proxy stammt. Dies ist eine Herausforderung, wenn der Upstream-Server die wahre Ursprungs-IP-Adresse (des Remote-Clients) ermitteln muss, beispielsweise zu Authentifizierungs- oder Protokollierungszwecken.

Es gibt wirksame Workarounds für HTTP- und HTTPS-Verkehr, indem entweder der HTTP-Header „X-Forwarded-For“ oder das PROXY-Protokoll verwendet wird. In diesem Artikel werden zwei zusätzliche Methoden beschrieben, die für TCP- und UDP-Verkehr gelten:

• Durch IP-Transparenz wird sichergestellt, dass die Upstream-Server erkennen, dass jede Verbindung von dem Remote-Client stammt, der sie initiiert hat. Es ist auf TCP‑ und UDP‑basierte Protokolle anwendbar.
• Direct Server Return (DSR) sorgt außerdem dafür, dass Antworten von den Upstream-Servern direkt an die Remote-Clients gehen und den zwischengeschalteten Load Balancer umgehen. Es ist auf UDP-basierte Protokolle anwendbar und kann durch Ausführen von NAT (Network Address Translation) auf dem Ursprungsserver oder einem Zwischenrouter implementiert werden.

Die Bereitstellung und Fehlerbehebung von IP-Transparenz und DSR ist komplex. Implementieren Sie diese Konfigurationen nur, wenn der Standardbetriebsmodus des Reverse-Proxys für Ihre Anwendung oder Ihren Dienst nicht ausreicht.

Einführung: Paketfluss in einem Standard-Layer-7-Reverse-Proxy

Im Gegensatz zu einem Switch oder Router, der lediglich Pakete weiterleitet, fungiert NGINX Plus als Layer 7 -Reverse-Proxy . In diesem Betriebsmodus verwaltet NGINX Plus separate clientseitige und upstreamseitige TCP-Verbindungen (für HTTP- und TCP-Verkehr) oder UDP-Sitzungen, um die Kommunikation zwischen dem Remote-Client und dem ausgewählten Upstream-Server zu steuern.

1. Remote-Clients stellen TCP-Verbindungen her oder senden UDP-Datagramme direkt an den NGINX Plus-Reverseproxy an seine veröffentlichte IP-Adresse und seinen Port. NGINX Plus beendet die TCP-Verbindung oder UDP-Sitzung und liest die Anforderungsdaten darin.
2. NGINX Plus stellt dann eine neue Verbindung zum ausgewählten (lastausgeglichenen) Upstream-Server her ( oder verwendet eine vorhandene, inaktive Verbindung erneut ).
3. Wenn NGINX Plus die Anfrage an den Upstream-Server schreibt, geht die Verbindung von der internen IP-Adresse von NGINX Plus aus.
4. Wenn der Upstream-Server auf die Anfrage antwortet, schreibt er Daten an die interne IP-Adresse von NGINX Plus.
5. NGINX Plus empfängt die Antwortdaten über die Upstream-seitige Verbindung. Es kann die Antwort verarbeiten oder ändern (beispielsweise Komprimierung auf eine HTTP-Antwort anwenden).
6. NGINX Plus schreibt dann die Antwortdaten auf die clientseitige Verbindung.

Eine Folge dieses standardmäßigen Reverse-Proxy-Betriebsmodus ist, dass der Upstream-Server erkennt, dass TCP- und UDP-Verkehr vom lokalen NGINX Plus-Proxy stammt.

Vorteile und Einschränkungen des Layer 7-Reverse-Proxy-Modus

Der Layer-7-Reverse-Proxy-Betriebsmodus bietet erhebliche Leistungssteigerungen und Effizienzgewinne für den HTTP- und TCP-Verkehr (einschließlich TCP-Optimierungen, Pufferung und HTTP-Keepalive-Wiederverwendung). Es stellt eine Herausforderung dar, wenn der Upstream-Server die tatsächliche Ursprungs-IP-Adresse der Verbindung oder Sitzung ermitteln muss, beispielsweise für Zwecke der Authentifizierung und Zugriffskontrolle, Ratenbegrenzung und Protokollierung.

Für einige Protokolle kann NGINX Plus den X-Forwarded-For- HTTP-Header oder das PROXY-Protokoll verwenden, um Upstream-Servern die ursprüngliche IP-Adresse bereitzustellen. Dieser Beitrag beschreibt zwei zusätzliche Methoden, die durch den transparenten Parameter der Proxy_bind- Direktive ermöglicht werden, der in NGINX Plus Release 10 (R10)<.htmla> eingeführt wurde.

Methode 1: IP-Transparenz

Der Zweck von IP Transparency besteht darin, die Anwesenheit des Reverse-Proxys zu verbergen, sodass der Ursprungsserver erkennt, dass die IP-Pakete von der IP-Adresse des Clients stammen. IP-Transparenz kann mit TCP-basierten und UDP-basierten Protokollen verwendet werden.

Erstellen eines HTTP-Reverse-Proxy-Dienstes auf dem NGINX Plus-Load Balancer

Um IP-Transparenz zu demonstrieren, erstellen wir zunächst einen Cluster mit Lastenausgleich aus vier Webservern, die mit einigen einfachen Verbindungsinformationen antworten.

1. Konfigurieren Sie einen einfachen virtuellen HTTP-Server, der den Datenverkehr über eine Gruppe von Upstream-Servern ausgleicht:

   # im 'http'-Kontext
   Server {
   Listen 80;
   
   Standort / {
   Proxy-Pass http://http_upstreams;
   }
   }
   
   Upstream http_upstreams {
   Server 172.16.0.11;
   Server 172.16.0.12;
   Server 172.16.0.13;
   Server 172.16.0.14;
   }
   

2. Um zu bestätigen, dass die Upstream-Server erkennen, dass die Verbindungen vom NGINX Plus-Load Balancer stammen, konfigurieren Sie auf jedem der vier Server (172.16.0.11 bis 172.16.01.14) einen NGINX Plus-Webserver mit einem einfachen virtuellen Server, der Informationen zur Verbindung zurückgibt, wie etwa:

   # im 'http'-Kontext
   server {
   listen 80;
   
   location / {
   return 200 "Hallo von $hostname. Sie haben eine Verbindung von $remote_addr:$remote_port zu $server_addr:$server_port\n hergestellt";
   }
   }
   

Wenn wir diese Konfiguration testen, melden die Upstreams, dass die Verbindungen von der lokalen NGINX Plus-IP-Adresse (172.16.0.1) stammen:

$ für i in {1..4}; führe curl http://192.168.99.10 aus; fertig. Hallo von dev1. Sie haben eine Verbindung von 172.16.0.1:42723 zu 172.16.0.11:80 hergestellt. Hallo von dev2. Sie haben eine Verbindung von 172.16.0.1:39117 zu 172.16.0.12:80 hergestellt. Hallo von dev3. Sie haben eine Verbindung von 172.16.0.1:54545 zu 172.16.0.13:80 hergestellt. Hallo von dev4. Sie haben eine Verbindung von 172.16.0.1:57020 zu 172.16.0.14:80 hergestellt.

Konfigurieren von NGINX Plus und Ihren Upstreams für IP-Transparenz

NGINX Plus R10 und höher (und NGINX Open Source 1.11.0 und höher) können die Quelladresse des Upstream-Verkehrs fälschen. Fügen Sie der Proxy_Bind- Direktive den transparenten Parameter hinzu. Am häufigsten wird die Quelladresse auf die des Remote-Clients festgelegt:

Proxy_Bind $Remote_Addr transparent;

Dieser einfache Schritt stellt jedoch eine erhebliche Herausforderung dar, da Sie sicherstellen müssen, dass der Antwortverkehr (Ausgangsverkehr) an den Remote-Client ordnungsgemäß gehandhabt wird. Der Antwortverkehr muss an NGINX Plus weitergeleitet werden und NGINX Plus muss die Upstream-TCP-Verbindung beenden. NGINX Plus sendet dann den Antwortverkehr über die Client-TCP-Verbindung an den Remote-Client.

Sie müssen mehrere Konfigurationsänderungen sowohl am NGINX Plus-Load Balancer als auch an jedem Upstream-Server vornehmen:

1. Konfigurieren Sie auf dem NGINX Plus-Load Balancer die Arbeitsprozesse so, dass sie als Root ausgeführt werden, damit sie Upstream-Sockets an beliebige Adressen binden können.

   Fügen Sie im Hauptkontext (oberste Ebene) in /etc/nginx/nginx.conf die Benutzerdirektive ein, um die ID der NGINX Plus-Arbeitsprozesse auf root festzulegen:

   # im „Haupt“-Kontext
   # „Benutzer-Daemon“ ist die Standardeinstellung; ändern Sie es mit transparentem Proxy_Bind zu „Benutzer-Root“
   Benutzer-Root;
   

2. Stellen Sie beim NGINX Plus-Load Balancer sicher, dass jede Verbindung von der Remote-Client-Adresse stammt.

   Fügen Sie der Konfiguration für den virtuellen Server die Direktive proxy_bind mit dem transparenten Parameter hinzu:

   # im 'http'-Kontext
   server {
   listen 80;
   
   location / {
   proxy_bind $remote_addr transparent;
   proxy_pass http://http_upstreams;
   }
   }
   

3. Konfigurieren Sie im NGINX Plus-Load Balancer iptables so, dass die Rückgabepakete von den Upstream-Servern erfasst und an NGINX Plus übermittelt werden.

   In diesem Beispiel führen wir die Befehle iptables und ip rule aus, um den gesamten TCP-Verkehr auf Port 80 von den Servern zu erfassen, die durch den IP-Bereich 172.16.0.0/28 dargestellt werden:

   # IP-Regel fügt fwmark 1 lookup 100 hinzu # IP-Route fügt lokal 0.0.0.0/0 dev lo table 100 hinzu # iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff
   

   Führen Sie den folgenden Befehl aus, um die aktuelle Konfiguration aus der iptables- Mangle-Tabelle aufzulisten ( -L ):

   # iptables -t mangle -L Chain PREROUTING (Richtlinie AKZEPTIEREN) Ziel Schutz opt Quelle Ziel MARK tcp -- 172.16.0.0/28 überall tcp spt:http MARK gesetzt 0x1 Chain INPUT (Richtlinie AKZEPTIEREN) Ziel Schutz opt Quelle Ziel Chain FORWARD (Richtlinie AKZEPTIEREN) Ziel Schutz opt Quelle Ziel Chain OUTPUT (Richtlinie AKZEPTIEREN) Ziel Schutz opt Quelle Ziel Chain POSTROUTING (Richtlinie AKZEPTIEREN) Ziel Schutz opt Quelle Ziel
   

4. Konfigurieren Sie auf den Upstream-Servern das Routing so, dass der gesamte Rückverkehr an NGINX Plus weitergeleitet wird.

   Entfernen Sie auf jedem Upstreamserver alle bereits vorhandenen Standardrouten und konfigurieren Sie die Standardroute als IP-Adresse des NGINX Plus-Load Balancers/Reverse-Proxys. Beachten Sie, dass sich diese IP-Adresse im selben Subnetz befinden muss wie eine der Schnittstellen des Upstreamservers.

   # Route del Standard gw 10.0.2.2 # Route add Standard gw 172.16.0.1
   

   Überprüfen Sie, ob die Routing-Tabelle sinnvoll aussieht:

   # route -n Kernel-IP-Routingtabelle Ziel-Gateway Genmask Flags Metrik Ref Verwendung Iface 0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth2 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
   

   Wenn Ihre Upstream-Server eine Verbindung zu externen Servern herstellen können müssen, müssen Sie auch das neue NGINX Plus-Gateway so konfigurieren, dass der Datenverkehr weitergeleitet und maskiert wird – siehe unten „Upstreams zum Erreichen externer Server aktivieren“ .

Testen der IP-Transparenzkonfiguration

Sie können die Konfiguration jetzt testen, indem Sie Anfragen an NGINX Plus senden. Stellen Sie sicher, dass Sie Anfragen von einer Remote-IP-Adresse senden, die von den Upstream-Servern nicht direkt geroutet werden kann:

$ für i in {1..4}; führe curl http://192.168.99.10 aus; fertig. Hallo von dev1. Sie haben eine Verbindung von 192.168.99.1:60729 zu 172.16.0.11:80 hergestellt. Hallo von dev2. Sie haben eine Verbindung von 192.168.99.1:43070 zu 172.16.0.12:80 hergestellt. Hallo von dev3. Sie haben eine Verbindung von 192.168.99.1:45749 zu 172.16.0.13:80 hergestellt. Hallo von dev4. Sie haben eine Verbindung von 192.168.99.1:46609 zu 172.16.0.14:80 hergestellt.

Beachten Sie, dass die Verbindungen jetzt scheinbar von der IP-Adresse des Remote-Clients (192.168.99.1) und nicht von einer lokalen Adresse des NGINX Plus-Load Balancers stammen.

Wenn die Konfiguration nicht funktioniert, lesen Sie unten die Fehlerbehebung .

Zusammenfassung: Wie funktioniert die IP-Transparenzkonfiguration?

• NGINX Plus empfängt eine HTTP-Anfrage von einem Remote-Client (192.168.99.1).
• NGINX Plus trifft eine Entscheidung zum Lastenausgleich und wählt einen Upstream-Server (z. B. 172.16.0.11) für die Verbindung aus. Bevor NGINX Plus eine Verbindung herstellt, bindet es seinen Upstream-Socket an die Adresse des Remote-Clients.
• Der Upstream-Server empfängt die Verbindung, die scheinbar direkt vom Remote-Client stammt.
• Der Upstream-Server antwortet, indem er Pakete an die Adresse des Remote-Clients adressiert und sie über NGINX Plus (den Standardrouter) leitet.
• Die iptables- Regel des NGINX Plus-Load Balancers markiert diese Pakete und das Routing stellt sie lokal zu.
• NGINX Plus liest die Antwort.
• NGINX Plus sendet dann die Antwort an den Remote-Client.

Das Nettoergebnis ist, dass aus Sicht der Upstream-Server die Verbindungen scheinbar direkt von den Remote-Clients stammen.

Methode 2: Direkte Serverrückgabe

Direct Server Return (DSR) ist eine Erweiterung des IP-Transparenzkonzepts. Bei IP-Transparenz empfängt der Upstream-Server Pakete, die scheinbar vom Remote-Client stammen. Mit DSR antwortet der Upstream-Server zusätzlich direkt dem Remote-Client; die Antwortpakete umgehen den Load Balancer vollständig.

DSR kann einen kleinen Leistungsvorteil bringen, da es die Belastung des Load Balancers reduziert, bringt aber eine Reihe von Einschränkungen mit sich:

• Der Load Balancer sieht die Rückgabepakete nie und kann daher nicht erkennen, ob der Upstream-Server antwortet oder ausgefallen ist.
• Der Load Balancer kann eine Anforderung nicht über das erste Paket hinaus prüfen, bevor er einen Upstream auswählt. Daher ist seine Fähigkeit, Entscheidungen zum Lastenausgleich (inhaltsbasiertes Routing) zu treffen, sehr eingeschränkt.
• Der Load Balancer kann an keinerlei Verhandlungen oder zustandsbehafteten Verarbeitungen, wie etwa SSL/TLS, teilnehmen.
• Die meisten anderen Funktionen des Application Delivery Controllers (ADC), wie etwa Caching, HTTP-Multiplexing und Protokollierung, sind mit DSR nicht möglich.

DSR ist für TCP-Protokolle nur begrenzt nützlich und die Reverse-Proxy-Architektur von NGINX Plus lässt sich ohnehin nicht auf DSR/TCP anwenden.

UDP-Protokolle sind viel einfacher und verfügen über keine der Verbindungssemantiken von TCP. Sie können NGINX Plus so konfigurieren, dass DSR für UDP-Protokolle wie DNS unterstützt wird. Dies kann Leistungsvorteile bringen. DSR bedeutet insbesondere, dass NGINX Plus UDP-Sockets nicht in Erwartung eines Antwortpakets offen halten muss (was die Skalierbarkeit verbessert) und Antwortpakete die Layer-7-Verarbeitung von NGINX Plus vollständig umgehen können (was die Latenz reduziert).

Worin unterscheidet sich eine DSR-Konfiguration von IP-Transparenz?

Es gibt drei Unterschiede zwischen einer IP-Transparenzkonfiguration und einer DSR-Konfiguration für UDP-Verkehr:

• NGINX Plus muss beim Senden von Datagrammen an Upstream-Server sowohl die IP-Adresse als auch den Port des Remote-Clients fälschen ( Proxy_Bind- Portkonfiguration).
• NGINX Plus darf nicht so konfiguriert werden, dass es Antwortdatagramme von Upstream-Servern erwartet (die proxy_responses0 Richtlinie).
• Ein zusätzlicher Schritt ist erforderlich, um die Quelladresse der Rückgabedatagramme so umzuschreiben, dass sie mit der öffentlichen Adresse des Load Balancers übereinstimmt.

Darüber hinaus muss NGINX Plus so konfiguriert werden, dass aktive Integritätsprüfungen der Upstream-Server durchgeführt werden. NGINX Plus kann zur Feststellung der Funktionstüchtigkeit eines Servers nicht auf seine üblichen passiven Prüfungen vertrauen, da NGINX Plus die vom Server gesendeten Antwortpakete nicht beobachtet.

Erstellen eines Standard-UDP-Reverse-Proxy-Dienstes

Um DSR zu demonstrieren, erstellen Sie zunächst einen Cluster mit Lastenausgleich aus vier DNS-Servern, die bei Suchvorgängen nach dem Namen www.example.com mit unterschiedlichen IP-Adressen antworten.

Konfigurieren Sie eine einfache Reverse‑Proxy‑Konfiguration, die einen Lastenausgleich zwischen den DNS‑Servern vornimmt:

# im Kontext „Stream“
Server {
Listen 53 udp;

Proxy-Antworten 1;
Proxy-Timeout 1 s;
Proxy-Pass dns_upstreams;
}

Upstream dns_upstreams {
Server 172.16.0.11:53;
Server 172.16.0.12:53;
Server 172.16.0.13:53;
Server 172.16.0.14:53;
}

Die Anweisungen proxy_responses und proxy_timeout implementieren eine grundlegende Integritätsprüfung. Wenn ein Upstream-Server innerhalb einer Sekunde keine Antwort sendet, geht NGINX Plus davon aus, dass der Server ausgefallen ist, und versucht die DNS-Anfrage erneut.

Konfigurieren Sie jeden DNS-Server so, dass er auf Suchanfragen nach www.example.com mit seiner eigenen IP-Adresse antwortet:

$TTL 604800
@ IN SOA ns1.example.com. admin.example.com. (
2; Seriell
604800; Aktualisieren
86400; Erneut versuchen
2419200; Ablaufen
604800); Negative Cache-TTL

example.com.    IN NS ns1.example.com.

ns1 IN A 172.16.0.11
www IN A 172.16.0.11

Tests machen deutlich, dass NGINX Plus die Last der Anfragen zwischen den DNS-Servern ausgleicht:

$ für i in {1..4}; führe dig +short @192.168.99.10 www.example.com aus; fertig
172.16.0.11
172.16.0.12
172.16.0.13
172.16.0.14

Konfigurieren von NGINX Plus und Ihren UDP-Upstreams für DSR

NGINX Plus R10 und höher (und NGINX Open Source 1.11.2 und höher) können sowohl die Quelladresse als auch den Port des Upstream-Verkehrs fälschen. Fügen Sie der Proxy_Bind- Direktive den transparenten Parameter hinzu:

Proxy_Bind $Remote_Addr:$Remote_Port transparent;

Dadurch kann der Upstreamserver die vollständige Quell-IP-Adresse beobachten und Antwortdatagramme erstellen, die direkt an den Remoteclient gesendet werden.

Der Upstream-Server generiert Antwortpakete („Egress“) mit dem richtigen IP-Ziel, verwendet jedoch seine lokale IP-Adresse als Quelladresse. Die Quelladresse muss in die IP-Adresse und den Port des NGINX Plus-Load Balancers umgeschrieben werden, mit dem der Client ursprünglich verbunden war.

Es gibt zwei Möglichkeiten:

1. Router-NAT – Schreiben Sie die ausgehenden Pakete auf einen Zwischenrouter (wie etwa den NGINX Plus-Proxy) um.
2. Origin NAT – Schreiben Sie die ausgehenden Pakete neu, wenn sie jeden Upstream-DNS-Server verlassen

Beide Methoden verwenden die zustandslose NAT-Funktion, die Sie mit dem Befehl tc konfigurieren. Wenn die Upstream-Server direkt mit dem Internet verbunden sind (aufgrund der Topologie werden Rückgabepakete nicht über einen von Ihnen gesteuerten Zwischenrouter gesendet), müssen Sie die ursprüngliche NAT-Methode auswählen.

NGINX Plus für DSR konfigurieren

Die Antwortpakete werden nicht an NGINX Plus übermittelt, daher müssen Sie die Integritätsprüfung deaktivieren, die Sie unter „Erstellen eines standardmäßigen UDP-Reverse-Proxy-Dienstes“ konfiguriert haben: Ändern Sie die Direktive „proxy_responses“ und deaktivieren Sie die Direktive „proxy_timeout“ . Jetzt wartet NGINX Plus nicht mehr auf Antworten und kommt nicht zu dem Schluss, dass der Upstream-Server ausgefallen ist, wenn er keine Antworten empfängt. Durch das Deaktivieren dieser Prüfung kann NGINX Plus die Socket-Ressourcen außerdem sofort wiederverwenden.

Fügen Sie außerdem die Variablen „$remote_addr“ und „$remote_port“ in den ersten Parameter der Direktive „proxy_bind“ ein, damit NGINX Plus sowohl die ursprüngliche Quelladresse als auch den Quellport in den an die Upstream-Server gesendeten Datagrammen beibehält:

# im Kontext „Stream“
Server {
Listen 53 udp;

Proxy_Bind $Remote_Addr:$Remote_Port transparent;
Proxy_Responses 0;
#Proxy_Timeout 1s;
}

Router-NAT – Umschreiben der ausgehenden Pakete auf einem Zwischenrouter

Sie können ausgehende Pakete auf einem einzelnen Zwischenrouter umschreiben. Wenn sich die Upstream-Server beispielsweise in einem privaten Netzwerk hinter dem NGINX Plus-Load Balancer befinden, können Sie den Load Balancer als Standardroute verwenden und die Pakete beim Weiterleiten umschreiben.

1. Konfigurieren Sie jeden Upstream-Server so, dass der gesamte ausgehende Datenverkehr über den NGINX Plus-Server geleitet wird:

   # Route hinzufügen Standard-GW- Nginx-IP-Adresse
   

2. Konfigurieren Sie den NGINX Plus-Server für die Weiterleitung von IP-Verkehr:

   # sysctl -w net.ipv4.ip_forward=1
   

3. Konfigurieren Sie den NGINX Plus-Server so, dass eine zustandslose NAT-Umschreibung durchgeführt wird:

   # tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10 # tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.12 match ip sport 53 action nat egress 172.16.0.12 192.168.99.10 # tc filter add dev eth0 parent 10 : protocol ip prio 10 u32 match ip src 172.16.0.13 match ip sport 53 action nat egress 172.16.0.13 192.168.99.10 # tc filter add dev eth0 parent 10: Protokoll IP Prio 10 u32 Match IP Src 172.16.0.14 Match IP Sport 53 Aktion NAT Ausgang 172.16.0.14 192.168.99.10
   

   Stellen Sie sicher, dass Sie für jeden Upstream-Server die entsprechende Ausgangsschnittstelle und die entsprechenden IP-Adressen auswählen.

Weitere Informationen zu Stateless NAT finden Sie auf der Manpage von tc nat . Abhängig von Ihrer Konfiguration können Sie die TC -Filterbefehle möglicherweise auf einen einzigen Befehl reduzieren, indem Sie CIDR-Masken für die alten Quell- und Ausgangsparameter verwenden.

Um die aktuelle TC- Filterkonfiguration anzuzeigen, führen Sie diesen Befehl aus:

# tc filter show dev eth0

Origin NAT – Neuschreiben der ausgehenden Pakete auf jedem Upstream-Server

Wenn Sie die Netzwerkkonfiguration auf den Upstream-Servern durchführen können, insbesondere wenn diese direkt mit dem Internet verbunden sind, können Sie die folgende Konfiguration verwenden. Es muss auf jeden Upstream-Server angewendet werden.

Konfigurieren Sie jeden Upstream-Server so, dass er eine zustandslose NAT-Umschreibung durchführt:

# tc qdisc add dev eth0 Root-Handle 10: htb # tc filter add dev eth0 Parent 10: Protokoll IP Prio 10 u32 Match IP Src 172.16.0.11 Match IP Sport 53 Aktion NAT Ausgang 172.16.0.11 192.168.99.10

Stellen Sie sicher, dass Sie bei jedem Upstream die entsprechende Schnittstelle und die entsprechenden IP-Adressen auswählen.

Testen der DSR-Konfiguration

Zum Testen der Konfiguration senden Sie DNS-Anfragen an den Load Balancer von NGINX Plus und überprüfen Sie, ob deren Lastenausgleich auf den Upstream-Servern erfolgt.

DSR hat keine direkt sichtbaren Auswirkungen. Sie können sicher sein, dass es funktioniert, wenn Sie die Proxy-Antworten verwendet haben0 Anweisung zum Konfigurieren von NGINX Plus, sodass keine Antwortpakete erwartet werden, Ihre DNS-Clients jedoch dennoch lastausgeglichene Antworten erhalten. Sie können den Paketfluss außerdem mit tcpdump beobachten, wie unten unter „Fehlerbehebung“ beschrieben.

Zusammenfassung: Wie funktioniert die DSR-Konfiguration?

• NGINX Plus empfängt ein UDP-Datagramm von einem Remote-Client (192.168.99.1: Port ).
• NGINX Plus trifft eine Entscheidung zum Lastenausgleich und wählt einen Upstream-Server aus (z. B. 172.16.0.11), auf den der Datagramminhalt geschrieben wird. Bevor NGINX Plus eine Verbindung herstellt, bindet es die lokale Seite des Upstream-Sockets an die IP-Adresse und den Port des Remote-Clients.
• Der Upstream-Server empfängt das von NGINX Plus gesendete Datagramm, das offenbar direkt von der Adresse und dem Port des Remote-Clients stammt.
• Der Upstream-Server antwortet, indem er Datagramme an den Remote-Client zurücksendet. Der Upstream-Server setzt die Quell-IP-Adresse und den Quell-Port der Antwort-Datagramme auf seine eigene lokale IP-Adresse und seinen eigenen lokalen Port.
• Die Quell-IP-Adresse (und der Port, falls erforderlich) werden entweder vom Upstream-Server (der ursprünglichen NAT- Konfiguration) oder einem Zwischenrouter (der Router-NAT- Konfiguration) neu geschrieben.
• Der Remote-Client empfängt die Datagramme, adressiert mit dem richtigen 4-Tupel (Quell- und Ziel-IP-Adressen und Ports).
• NGINX Plus erwartet keine Antwort-Datagramme und schließt den Upstream-Socket sofort.

Das Nettoergebnis ist, dass Antwortpakete die Layer-7-Verarbeitung in NGINX Plus umgehen und direkt an den Remote-Client gehen.

Fehlerbehebung

Wenn IP Transparency oder DSR nicht wie erwartet funktionieren, ermitteln Sie anhand der folgenden Vorschläge die möglichen Ursachen:

Als Root ausführen

Stellen Sie sicher, dass die NGINX Plus-Arbeitsprozesse für die Ausführung als Root konfiguriert sind. Andernfalls wird in Ihrem Fehlerprotokoll eine Fehlermeldung ähnlich der folgenden angezeigt, wenn NGINX Plus versucht, den Socket an eine nicht lokale Adresse zu binden:

setsockopt(IP_TRANSPARENT) fehlgeschlagen (1: Vorgang nicht zulässig) beim Verbinden mit Upstream, Client: 192.168.99.1, Server: , Anfrage: "GET / HTTP/1.1", Upstream: "http://172.16.0.11:80/", Host: „192.168.99.10“

Test mit Ping

Überprüfen Sie, ob Sie Clients und Server vom NGINX Plus-Proxy aus anpingen können. Die Upstream-Server können keine Ping-Nachrichten an die IP-Adressen der Remote-Clients senden, es sei denn, Sie erstellen zuerst die erforderliche Routing-Konfiguration und konfigurieren den NGINX Plus-Vermittler für die Weiterleitung von Paketen.

Keine überlappenden IP-Bereiche

Stellen Sie sicher, dass die von den Remoteclients verwendeten IP-Subnetze nicht direkt mit den Upstream-Servern verbunden sind. Wenn dies der Fall ist, treten wahrscheinlich zwei Probleme auf:

• Der „Reverse Path Filtering“-Schutz von Linux lehnt möglicherweise Pakete von NGINX Plus stillschweigend ab, weil die Quell-IP-Adresse mit einem Subnetz auf einer anderen Schnittstelle verknüpft ist.
• Rückgabepakete verwenden nicht die Standardroute, sondern werden direkt an den lokal verbundenen Remote-Client gesendet.

Verwenden Sie tcpdump überall

Während Sie die Konfiguration aufbauen und jeden Zwischenschritt testen, führen Sie tcpdump kontinuierlich auf jedem einzelnen Server aus, um zu überprüfen, ob in jeder Phase Pakete an die richtigen Endpunkte gesendet und von diesen empfangen werden:

$ sudo tcpdump -i beliebig -n TCP-Port 80

Untersuchen Sie ungewöhnliches Verhalten mithilfe der unten aufgeführten Prüfungen.

Routing-Tabellen prüfen

Überprüfen Sie sorgfältig die Routing-Tabellen auf jedem Server und achten Sie dabei besonders auf die Upstream-Server:

# route -n Kernel-IP-Routingtabelle Ziel-Gateway Genmask Flags Metrik Ref Verwendung Iface 0.0.0.0 172.16.0.1 0.0.0.0 UG 0 0 0 eth2 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Gibt es unerwartete Routen? Können Sie bestätigen, dass alle Pakete im Fluss an das richtige Ziel weitergeleitet werden? Denken Sie daran, dass in den iptables- und Router-NAT-Konfigurationen alle ausgehenden Pakete über den zwischengeschalteten NGINX Plus-Proxy geleitet werden müssen.

Fehlende Pakete

Wenn Pakete unerwartet gelöscht werden ( tcpdump zeigt an, dass sie von einer Maschine gesendet, aber von einer anderen nicht empfangen wurden), ist die Reverse-Path-Filterung ein potenzieller stiller Übeltäter. Um die umgekehrte Pfadfilterung vorübergehend zu deaktivieren, führen Sie den folgenden Befehl aus:

# für f in /proc/sys/net/ipv4/conf/*/rp_filter; mache echo 0 > $f; fertig

Upstream-Servern den Zugriff auf externe Server ermöglichen

Wenn sich Ihre Upstream-Server in einem privaten Netzwerk befinden und NGINX Plus (oder einen anderen Server) als Standard-Gateway verwenden, möchten Sie das Gateway möglicherweise so konfigurieren, dass die Upstream-Server externe (Internet-)Hosts erreichen können.

Sie müssen die IP-Weiterleitung aktivieren, damit das Gateway Pakete von den Upstream-Servern weiterleiten kann; in der Regel ist die IP-Weiterleitung standardmäßig deaktiviert. Wenn die Server keine routingfähigen IP-Adressen haben (sie verwenden private Adressen wie 172.16.0.0/24), müssen Sie die IP-Masquerading auch auf den externen Schnittstellen des Gateway-Servers konfigurieren:

# sysctl -w net.ipv4.ip_forward=1 # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Überprüfen Sie, ob Sie von Ihrem internen Upstream-Server aus einen externen Server anpingen können:

root@dev1:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) Bytes Daten.
64 Bytes von 8.8.8.8: icmp_seq=1 ttl=61 Zeit=6,72 ms 64 Bytes von 8.8.8.8: icmp_seq=2 ttl=61 Zeit=5,49 ms ^C

Um Ihre aktuelle Weiterleitungs-, Routing- und Iptables- NAT- Konfiguration anzuzeigen, führen Sie die folgenden drei Befehle aus:

# sysctl net.ipv4.ip_forward # route -n # iptables -t nat -L

Unterstützung von NGINX erhalten

Die Konfiguration für IP-Transparenz oder Direct Server Return ist komplex und andere zwischengeschaltete Netzwerkgeräte können die Bereitstellung beeinträchtigen, indem sie Pakete löschen oder anderweitig umschreiben. Wenn Sie Hilfe benötigen, steht Ihnen das Professional Services -Team von NGINX gerne zur Verfügung.

Probieren Sie IP-Transparenz und DSR mit NGINX Plus selbst aus – starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .