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.
Schauen Sie sich auch unbedingt das On-Demand-Webinar „ Was ist neu in NGINX Plus R10?“ an.
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:
Methode 1 – IP-Transparenz | Methode 2a – DSR (Router-NAT) | Methode 2b – DSR (Origin-NAT) | |
---|---|---|---|
Unterstützte Protokolle | TCP‑basiert und UDP‑basiert | Nur UDP‑basiert | Nur UDP‑basiert |
Verkehrsrouting durch Upstreamserver | Der gesamte ausgehende Datenverkehr wird an den NGINX Plus-Proxy weitergeleitet und beendet | Der gesamte ausgehende Datenverkehr wird über den zwischengeschalteten NGINX Plus-Server geleitet | Der gesamte Verkehr wird normal weitergeleitet |
Leistung | Standard: Ausgehender Datenverkehr wird auf dem NGINX Plus-Proxy beendet. | Besser: Der ausgehende Datenverkehr wird vom zwischengeschalteten NGINX Plus-Server weitergeleitet | Am besten: Der ausgehende Datenverkehr wird unter Umgehung von NGINX Plus direkt an den Remote-Client weitergeleitet. |
Gesundheitschecks | Standardmäßig passiv; aktiv unterstützt | Aktiv erforderlich; passiv nicht möglich | Aktiv erforderlich; passiv nicht möglich |
Erforderliche Konfiguration | |||
TCP und UDP auf NGINX Plus-Proxy | TCP: funktioniert standardmäßig UDP: Proxy_Antworten 1 |
TCP: nicht unterstützt UDP: Proxy_Antworten 0 |
TCP: nicht unterstützt UDP: Proxy_Antworten 0 |
Wie und wo werden Pakete verarbeitet? | iptables wird auf dem NGINX Plus-Proxy beendet |
tc nat -Umschreibungen auf dem zwischengeschalteten NGINX Plus-Server |
tc nat -Umschreibungen auf den Upstream-Servern |
Netzwerkkonfiguration auf dem NGINX Plus-Proxy | iptables zum Erfassen ausgehender Pakete |
IP-Weiterleitung und Stateless NAT | Keiner |
Netzwerkkonfiguration auf Upstream-Server | NGINX Plus als Standardroute festlegen | NGINX Plus als Standardroute festlegen | Zustandsloses NAT |
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.
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.
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.
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.
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.
Um IP-Transparenz zu demonstrieren, erstellen wir zunächst einen Cluster mit Lastenausgleich aus vier Webservern, die mit einigen einfachen Verbindungsinformationen antworten.
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;
}
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.
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:
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;
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;
}
}
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
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“ .
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 .
iptables-
Regel des NGINX Plus-Load Balancers markiert diese Pakete und das Routing stellt sie lokal zu.Das Nettoergebnis ist, dass aus Sicht der Upstream-Server die Verbindungen scheinbar direkt von den Remote-Clients stammen.
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:
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).
Es gibt drei Unterschiede zwischen einer IP-Transparenzkonfiguration und einer DSR-Konfiguration für UDP-Verkehr:
Proxy_Bind-
Portkonfiguration).proxy_responses
0
Richtlinie).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.
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
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:
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.
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;
}
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.
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
Konfigurieren Sie den NGINX Plus-Server für die Weiterleitung von IP-Verkehr:
# sysctl -w net.ipv4.ip_forward=1
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
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.
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.
Das Nettoergebnis ist, dass Antwortpakete die Layer-7-Verarbeitung in NGINX Plus umgehen und direkt an den Remote-Client gehen.
Wenn IP Transparency oder DSR nicht wie erwartet funktionieren, ermitteln Sie anhand der folgenden Vorschläge die möglichen Ursachen:
Root
ausführenStellen 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“
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.
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:
tcpdump
überallWä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.
Ü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.
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
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
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 .
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."