Transparence IP et retour direct du serveur avec NGINX et NGINX Plus comme proxy transparent

Cet article de blog décrit comment configurer NGINX Open Source et NGINX Plus comme proxy transparent pour le trafic vers les serveurs en amont. Il explique comment vous pouvez utiliser un proxy transparent pour usurper l'adresse IP source des paquets afin d'implémenter la transparence IP et comment vous pouvez implémenter un mode d'équilibrage de charge appelé Direct Server Return pour le trafic UDP.

Les informations contenues dans cet article s'appliquent à la fois à NGINX Open Source et à NGINX Plus . Par souci de concision, nous nous référerons uniquement à NGINX Plus.

Éditeur – Il s’agit du cinquième d’une série d’articles de blog qui explorent en profondeur les nouvelles fonctionnalités de NGINX Plus R10.

• Authentification des clients API avec JWT et NGINX Plus
• NGINX Plus R10 exploite la puissance d'IBM
• Authentification des utilisateurs sur des applications existantes avec OpenID Connect et NGINX Plus
• Utilisation du module JavaScript NGINX pour effectuer la transition progressive des clients vers un nouveau serveur
• Transparence IP et retour direct du serveur avec NGINX et NGINX Plus comme proxy transparent (ce post)

N'oubliez pas également de consulter le webinaire à la demande « Quoi de neuf dans NGINX Plus R10 ? »

Résumé

NGINX Plus fonctionne comme un proxy inverse de couche 7. Cela permet à NGINX Plus d’appliquer un certain nombre d’optimisations et d’améliorations aux demandes réseau qu’il gère.

Par conséquent, les serveurs en amont (à charge équilibrée) observent que tout le trafic provient d’une adresse IP sur le proxy NGINX Plus. Il s’agit d’un défi si le serveur en amont doit déterminer la véritable adresse IP d’origine (celle du client distant), par exemple, à des fins d’authentification ou de journalisation.

Il existe des solutions de contournement efficaces pour le trafic HTTP et HTTPS, en utilisant soit l'en-tête HTTP X-Forwarded-For, soit le protocole PROXY . Cet article décrit deux méthodes supplémentaires, qui s'appliquent au trafic TCP et UDP :

• La transparence IP garantit que les serveurs en amont observent que chaque connexion provient du client distant qui l'a initiée. Elle s’applique aux protocoles basés sur TCP et UDP.
• Le retour direct du serveur (DSR) permet en outre aux réponses des serveurs en amont d'être envoyées directement aux clients distants et de contourner l'équilibreur de charge intermédiaire. Elle s'applique aux protocoles basés sur UDP et peut être implémentée en effectuant une NAT (traduction d'adresse réseau) sur le serveur d'origine ou un routeur intermédiaire.

Il est complexe de déployer et de dépanner la transparence IP et le DSR. N'implémentez ces configurations que si le mode de fonctionnement standard du proxy inverse n'est pas suffisant pour votre application ou service.

Introduction: Flux de paquets dans un proxy inverse standard de couche 7

Contrairement à un commutateur ou un routeur qui transfère simplement les paquets, NGINX Plus fonctionne comme un proxy inverse de couche 7. Dans ce mode de fonctionnement, NGINX Plus gère des connexions TCP côté client et côté amont distinctes (pour le trafic HTTP et TCP) ou des sessions UDP afin de contrôler la communication entre le client distant et le serveur en amont sélectionné.

1. Les clients distants établissent des connexions TCP ou envoient des datagrammes UDP directement au proxy inverse NGINX Plus à son adresse IP et à son port publiés. NGINX Plus met fin à la connexion TCP ou à la session UDP et lit les données de la demande à l'intérieur.
2. NGINX Plus établit ensuite une nouvelle connexion ( ou réutilise une connexion existante et inactive ) au serveur en amont sélectionné (à charge équilibrée).
3. Lorsque NGINX Plus écrit la requête sur le serveur en amont, la connexion provient de l’adresse IP interne de NGINX Plus.
4. Lorsque le serveur en amont répond à la demande, il écrit des données sur l’adresse IP interne de NGINX Plus.
5. NGINX Plus reçoit les données de réponse sur la connexion côté amont. Il peut traiter ou modifier la réponse (par exemple, appliquer une compression à une réponse HTTP).
6. NGINX Plus écrit ensuite les données de réponse sur la connexion côté client.

Une conséquence de ce mode de fonctionnement proxy inverse standard est que le serveur en amont observe que le trafic TCP et UDP provient du proxy NGINX Plus local.

Avantages et limites du mode proxy inverse de couche 7

Le mode de fonctionnement du proxy inverse de couche 7 apporte des gains de performances et d'efficacité significatifs pour le trafic HTTP et TCP (y compris les optimisations TCP, la mise en mémoire tampon et la réutilisation de la fonction HTTP keepalive). Cela pose un défi si le serveur en amont doit déterminer la véritable adresse IP d’origine de la connexion ou de la session, à des fins telles que l’authentification et le contrôle d’accès, la limitation du débit et la journalisation.

Pour certains protocoles, NGINX Plus peut utiliser l'en-tête HTTP X-Forwarded-For ou le protocole PROXY pour fournir l'adresse IP d'origine aux serveurs en amont. Cet article décrit deux méthodes supplémentaires, rendues possibles par le paramètre transparent de la directive proxy_bind , qui a été introduit dans NGINX Plus Release 10 (R10)<.htmla>.

Méthode 1 : Transparence de la propriété intellectuelle

L’objectif de la transparence IP est de masquer la présence du proxy inverse afin que le serveur d’origine observe que les paquets IP proviennent de l’adresse IP du client. La transparence IP peut être utilisée avec les protocoles basés sur TCP et UDP.

Création d'un service proxy inverse HTTP sur l'équilibreur de charge NGINX Plus

Pour démontrer la transparence IP, nous créons d’abord un cluster à charge équilibrée de quatre serveurs Web qui répondent avec des informations de connexion simples.

1. Configurez un serveur virtuel HTTP simple qui équilibre la charge du trafic sur un groupe de serveurs en amont :

   # dans le contexte 'http'
   serveur {
   écoute 80 ;
   
   emplacement / {
   proxy_pass http://http_upstreams ;
   }
   }
   
   en amont http_upstreams {
   serveur 172.16.0.11 ;
   serveur 172.16.0.12 ;
   serveur 172.16.0.13 ;
   serveur 172.16.0.14 ;
   }
   

2. Pour confirmer que les serveurs en amont observent que les connexions proviennent de l'équilibreur de charge NGINX Plus, configurez un serveur Web NGINX Plus sur chacun des quatre (172.16.0.11 à 172.16.01.14) avec un serveur virtuel simple qui renvoie des informations sur la connexion, telles que :

   # dans le contexte 'http'
   serveur {
   écoute 80 ;
   
   emplacement / {
   retour 200 "Bonjour de $hostname. Vous vous êtes connecté depuis $remote_addr:$remote_port vers $server_addr:$server_port\n";
   }
   }
   

Lorsque nous testons cette configuration, les connexions en amont signalent que les connexions proviennent de l'adresse IP locale NGINX Plus (172.16.0.1) :

$ for i in {1..4}; do curl http://192.168.99.10 ; terminé Bonjour de dev1. Vous vous êtes connecté de 172.16.0.1:42723 à 172.16.0.11:80 Bonjour de dev2. Vous vous êtes connecté de 172.16.0.1:39117 à 172.16.0.12:80 Bonjour de dev3. Vous vous êtes connecté de 172.16.0.1:54545 à 172.16.0.13:80 Bonjour de dev4. Vous vous êtes connecté de 172.16.0.1:57020 à 172.16.0.14:80

Configuration de NGINX Plus et de vos flux en amont pour la transparence IP

NGINX Plus R10 et versions ultérieures (et NGINX Open Source 1.11.0 et versions ultérieures) peuvent usurper l'adresse source du trafic en amont. Incluez le paramètre transparent dans la directive proxy_bind . Le plus souvent, vous définissez l’adresse source sur celle du client distant :

proxy_bind $remote_addr transparent;

Cette étape simple crée toutefois un défi important, car vous devez vous assurer que le trafic de réponse (sortie) vers le client distant est correctement géré. Le trafic de réponse doit être acheminé vers NGINX Plus, et NGINX Plus doit mettre fin à la connexion TCP en amont. NGINX Plus envoie ensuite le trafic de réponse au client distant via la connexion TCP client.

Vous devez apporter plusieurs modifications de configuration à la fois à l'équilibreur de charge NGINX Plus et à chaque serveur en amont :

1. Sur l'équilibreur de charge NGINX Plus , configurez les processus de travail pour qu'ils s'exécutent en tant que root , afin qu'ils puissent lier les sockets en amont à des adresses arbitraires.

   Dans le contexte principal (de niveau supérieur) de /etc/nginx/nginx.conf , incluez la directive utilisateur pour définir l'ID des processus de travail NGINX Plus sur root :

   # dans le contexte « main »
   # « user daemon » est la valeur par défaut ; remplacez-la par « user root » avec un proxy_bind transparent
   user root ;
   

2. Sur l’équilibreur de charge NGINX Plus , assurez-vous que chaque connexion provient de l’adresse du client distant.

   Ajoutez la directive proxy_bind avec le paramètre transparent à la configuration du serveur virtuel :

   # dans le contexte 'http'
   serveur {
   écoute 80 ;
   
   emplacement / {
   proxy_bind $remote_addr transparent ;
   proxy_pass http://http_upstreams ;
   }
   }
   

3. Sur l'équilibreur de charge NGINX Plus , configurez iptables pour capturer les paquets de retour des serveurs en amont et les livrer à NGINX Plus.

   Dans cet exemple, nous exécutons les commandes iptables et ip rule pour capturer tout le trafic TCP sur le port 80 à partir des serveurs représentés par la plage IP 172.16.0.0/28 :

   # règle IP ajouter fwmark 1 recherche 100 # route IP ajouter local 0.0.0.0/0 dev lo table 100 # iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff
   

   Exécutez la commande suivante pour répertorier ( -L ) la configuration actuelle de la table mangle iptables :

   # iptables -t mangle -L Chaîne PREROUTING (politique ACCEPT) cible prot opt source destination MARK tcp -- 172.16.0.0/28 n'importe où tcp spt:http MARK set 0x1 Chaîne INPUT (politique ACCEPT) cible prot opt source destination Chaîne FORWARD (politique ACCEPT) cible prot opt source destination Chaîne OUTPUT (politique ACCEPT) cible prot opt source destination Chaîne POSTROUTING (politique ACCEPT) cible prot opt source destination
   

4. Sur les serveurs en amont , configurez le routage de sorte que tout le trafic de retour soit transmis à NGINX Plus.

   Sur chaque serveur en amont, supprimez toute route par défaut préexistante et configurez la route par défaut comme étant l’adresse IP de l’équilibreur de charge/proxy inverse NGINX Plus. Notez que cette adresse IP doit être sur le même sous-réseau que l’une des interfaces du serveur en amont.

   # route supprimer par défaut gw 10.0.2.2 # route ajouter par défaut gw 172.16.0.1
   

   Vérifiez que la table de routage semble raisonnable :

   # route -n Table de routage IP du noyau Destination Passerelle Genmask Drapeaux Métrique Référence Utiliser 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
   

   Si vos serveurs en amont doivent pouvoir se connecter à des serveurs externes, vous devez également configurer la nouvelle passerelle NGINX Plus pour transférer et masquer le trafic. Voir Activation des serveurs en amont pour atteindre les serveurs externes ci-dessous.

Test de la configuration de transparence IP

Vous pouvez désormais tester la configuration en envoyant des requêtes à NGINX Plus. Assurez-vous que vous envoyez des requêtes à partir d’une adresse IP distante qui n’est pas directement routable depuis les serveurs en amont :

$ for i in {1..4}; do curl http://192.168.99.10 ; terminé Bonjour de dev1. Vous vous êtes connecté de 192.168.99.1:60729 à 172.16.0.11:80 Bonjour de dev2. Vous vous êtes connecté de 192.168.99.1:43070 à 172.16.0.12:80 Bonjour de dev3. Vous vous êtes connecté de 192.168.99.1:45749 à 172.16.0.13:80 Bonjour de dev4. Vous vous êtes connecté de 192.168.99.1:46609 à 172.16.0.14:80

Notez que les connexions semblent désormais provenir de l’adresse IP du client distant (192.168.99.1) plutôt que d’une adresse locale à l’équilibreur de charge NGINX Plus.

Si la configuration ne fonctionne pas, consultez Dépannage ci-dessous.

Résumé: Comment fonctionne la configuration de la transparence IP ?

• NGINX Plus reçoit une requête HTTP d'un client distant (192.168.99.1).
• NGINX Plus prend une décision d’équilibrage de charge en sélectionnant un serveur en amont (par exemple, 172.16.0.11) auquel se connecter. Avant que NGINX Plus se connecte, il lie son socket en amont à l’adresse du client distant.
• Le serveur en amont reçoit la connexion, qui semble provenir directement du client distant.
• Le serveur en amont répond en adressant les paquets à l’adresse du client distant et en les acheminant via NGINX Plus (le routeur par défaut).
• La règle iptables sur l'équilibreur de charge NGINX Plus marque ces paquets et le routage les délivre localement.
• NGINX Plus lit la réponse.
• NGINX Plus envoie ensuite la réponse au client distant.

Le résultat net est que, du point de vue des serveurs en amont, les connexions semblent provenir directement des clients distants.

Méthode 2 : Retour direct du serveur

Direct Server Return (DSR) est une extension du concept de transparence IP. Dans IP Transparency, le serveur en amont reçoit des paquets qui semblent provenir du client distant. Avec DSR, en plus le serveur en amont répond directement au client distant ; les paquets de retour contournent complètement l'équilibreur de charge.

Le DSR peut offrir un léger avantage en termes de performances car il réduit la charge sur l'équilibreur de charge, mais il comporte un certain nombre de limitations :

• L'équilibreur de charge ne voit jamais les paquets de retour, il ne peut donc pas détecter si le serveur en amont répond ou est en panne.
• L'équilibreur de charge ne peut pas inspecter une demande au-delà du premier paquet avant de sélectionner un paquet en amont. Sa capacité à prendre des décisions d'équilibrage de charge (routage basé sur le contenu) est donc très limitée.
• L'équilibreur de charge ne peut participer à aucune forme de négociation ou de traitement avec état, tel que SSL/TLS.
• La plupart des autres fonctionnalités du contrôleur de distribution d’applications (ADC) ne sont pas possibles avec DSR, telles que la mise en cache, le multiplexage HTTP et la journalisation.

Le DSR est d’une utilité limitée pour les protocoles TCP et, dans tous les cas, l’architecture proxy inverse de NGINX Plus ne peut pas être appliquée au DSR/TCP.

Les protocoles UDP sont beaucoup plus simples, sans aucune des sémantiques de connexion du TCP. Vous pouvez configurer NGINX Plus pour prendre en charge DSR pour les protocoles UDP tels que DNS, ce qui peut offrir des avantages en termes de performances. Plus précisément, DSR signifie que NGINX Plus n’a pas besoin de maintenir les sockets UDP ouverts dans l’attente d’un paquet de réponse (ce qui améliore l’évolutivité), et les paquets de réponse peuvent contourner complètement le traitement de couche 7 de NGINX Plus (ce qui réduit la latence).

En quoi une configuration DSR diffère-t-elle de la transparence IP ?

Il existe trois différences entre une configuration de transparence IP et une configuration DSR pour le trafic UDP :

• NGINX Plus doit usurper à la fois l'adresse IP et le port du client distant lors de l'envoi de datagrammes aux serveurs en amont (configuration du port proxy_bind ).
• NGINX Plus ne doit pas être configuré pour attendre des datagrammes de réponse des serveurs en amont (les proxy_responses0 directif).
• Une étape supplémentaire est nécessaire pour réécrire l’adresse source des datagrammes de retour afin qu’elle corresponde à l’adresse publique de l’équilibreur de charge.

De plus, NGINX Plus doit être configuré pour effectuer des contrôles de santé actifs sur les serveurs en amont. NGINX Plus ne peut pas s'appuyer sur ses contrôles passifs habituels pour vérifier si un serveur est sain, car NGINX Plus n'observe pas les paquets de réponse envoyés par le serveur.

Création d'un service proxy inverse UDP standard

Pour démontrer DSR, créez d’abord un cluster à charge équilibrée de quatre serveurs DNS qui répondent avec des adresses IP différentes pour les recherches du nom www.example.com .

Configurez une configuration de proxy inverse simple qui équilibre la charge entre les serveurs DNS :

# dans le contexte 'stream'
server {
liste 53 udp ;

proxy_responses 1 ;
proxy_timeout 1 s ;
proxy_pass dns_upstreams ;
}

en amont dns_upstreams {
serveur 172.16.0.11 : 53 ;
serveur 172.16.0.12 : 53 ;
serveur 172.16.0.13 : 53 ;
serveur 172.16.0.14 : 53 ;
}

Les directives proxy_responses et proxy_timeout implémentent une vérification de l'état de santé de base. Si un serveur en amont n'envoie pas de réponse dans un délai d'une seconde, NGINX Plus suppose que le serveur a échoué et réessaye la requête DNS.

Configurez chaque serveur DNS pour répondre avec sa propre adresse IP aux recherches de www.example.com :

$TTL 604800
@ DANS SOA ns1.exemple.com.admin.exemple.com. (
2 ; Série
604800 ; Rafraîchir
86400 ; Réessayer
2419200 ; Expirer
604800 ) ; Cache TTL négatif

exemple.com.    EN NS ns1.exemple.com.

ns1 DANS UN 172.16.0.11
www DANS UN 172.16.0.11

Les tests montrent clairement que NGINX Plus équilibre la charge des requêtes entre les serveurs DNS :

$ pour i dans {1..4} ; faire dig +short @192.168.99.10 www.example.com ; terminé
172.16.0.11
172.16.0.12
172.16.0.13
172.16.0.14

Configuration de NGINX Plus et de vos flux UDP en amont pour DSR

NGINX Plus R10 et versions ultérieures (et NGINX Open Source 1.11.2 et versions ultérieures) peuvent usurper à la fois l'adresse source et le port du trafic en amont. Incluez le paramètre transparent dans la directive proxy_bind :

proxy_bind $remote_addr:$remote_port transparent;

Cela permet au serveur en amont d’observer l’adresse IP source complète, afin de pouvoir construire des datagrammes de réponse qui sont envoyés directement au client distant.

Le serveur en amont génère des paquets de réponse (« sortie ») avec la destination IP correcte, mais en utilisant son adresse IP locale comme adresse source. L'adresse source doit être réécrite avec l'adresse IP et le port de l'équilibreur de charge NGINX Plus auquel le client s'est connecté à l'origine.

Deux méthodes sont possibles :

1. Routeur NAT – Réécrire les paquets de sortie sur un routeur intermédiaire (tel que le proxy NGINX Plus)
2. NAT d'origine – Réécrire les paquets de sortie lorsqu'ils quittent chaque serveur DNS en amont

Les deux méthodes utilisent la capacité NAT sans état que vous configurez avec la commande tc . Si les serveurs en amont sont directement connectés à Internet (la topologie signifie que les paquets de retour ne sont pas envoyés via un routeur intermédiaire que vous pouvez contrôler), vous devez alors sélectionner la méthode NAT d'origine .

Configuration de NGINX Plus pour DSR

Les paquets de réponse ne sont pas livrés à NGINX Plus, vous devez donc désactiver le contrôle d'état que vous avez configuré dans Création d'un service proxy inverse UDP standard : modifiez la directive proxy_responses et désactivez la directive proxy_timeout . Désormais, NGINX Plus n'attend pas les réponses et ne conclut pas que le serveur en amont est en panne lorsqu'il ne les reçoit pas. La désactivation de cette vérification permet également à NGINX Plus de réutiliser immédiatement les ressources du socket.

Incluez également les variables $remote_addr et $remote_port dans le premier paramètre de la directive proxy_bind afin que NGINX Plus conserve à la fois l'adresse source d'origine et le port source dans les datagrammes envoyés aux serveurs en amont :

# dans le contexte 'stream'
server {
listen 53 udp;

proxy_bind $remote_addr:$remote_port transparent;
proxy_responses 0;
#proxy_timeout 1s;
}

Routeur NAT – Réécriture des paquets de sortie sur un routeur intermédiaire

Vous pouvez réécrire les paquets de sortie sur un seul routeur intermédiaire. Par exemple, si les serveurs en amont sont situés sur un réseau privé derrière l’équilibreur de charge NGINX Plus, vous pouvez utiliser l’équilibreur de charge comme itinéraire par défaut et réécrire les paquets au fur et à mesure de leur transfert.

1. Configurez chaque serveur en amont pour acheminer tout le trafic sortant via le serveur NGINX Plus :

   # route ajouter adresse IP nginx par défaut gw
   

2. Configurer le serveur NGINX Plus pour transférer le trafic IP :

   # sysctl -w net.ipv4.ip_forward=1
   

3. Configurez le serveur NGINX Plus pour effectuer une réécriture NAT sans état :

   # tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocole ip prio 10 u32 correspondance ip src 172.16.0.11 correspondance ip sport 53 action nat sortie 172.16.0.11 192.168.99.10 # tc filter add dev eth0 parent 10: protocole ip prio 10 u32 correspondance ip src 172.16.0.12 correspondance ip sport 53 action nat sortie 172.16.0.12 192.168.99.10 # tc filter add dev eth0 parent 10: protocole ip prio 10 u32 correspondance ip src 172.16.0.13 correspondance ip sport 53 action nat sortie 172.16.0.13 192.168.99.10 # tc filter add dev eth0 parent 10: protocole ip prio 10 u32 correspondance ip src 172.16.0.14 correspondance ip sport 53 action nat sortie 172.16.0.14 192.168.99.10
   

   Assurez-vous de sélectionner l’interface de sortie appropriée et les adresses IP appropriées de chaque serveur en amont.

Pour plus d'informations sur NAT sans état, consultez la page de manuel tc nat . Selon votre configuration, vous pourrez peut-être réduire les commandes de filtre tc à une seule commande en utilisant des masques CIDR pour les anciens paramètres src et egress .

Pour afficher la configuration actuelle du filtre tc , exécutez cette commande :

# filtre tc afficher dev eth0

NAT d'origine – Réécriture des paquets de sortie sur chaque serveur en amont

Si vous êtes en mesure de configurer la mise en réseau sur les serveurs en amont, en particulier s’ils sont directement connectés à Internet, vous pouvez utiliser la configuration suivante. Elle doit être appliquée à chaque serveur en amont.

Configurez chaque serveur en amont pour effectuer une réécriture NAT sans état :

# tc qdisc ajoute dev eth0 root handle 10 : htb # tc filter ajoute dev eth0 parent 10 : protocole ip prio 10 u32 correspond à l'ip src 172.16.0.11 correspond à l'ip sport 53 action nat egress 172.16.0.11 192.168.99.10

Assurez-vous de sélectionner l’interface et les adresses IP appropriées sur chaque flux en amont.

Test de la configuration DSR

Pour tester la configuration, envoyez des requêtes DNS à l'équilibreur de charge NGINX Plus et vérifiez qu'elles sont équilibrées sur les serveurs en amont.

Le DSR n’a pas d’effets directement visibles. Vous pouvez être sûr que cela fonctionne si vous avez utilisé les proxy_responses0 directive permettant de configurer NGINX Plus pour ne pas attendre de paquets de réponse, mais vos clients DNS reçoivent des réponses à charge équilibrée. Vous pouvez également observer le flux de paquets à l'aide de tcpdump , comme décrit dans Dépannage ci-dessous.

Résumé: Comment fonctionne la configuration DSR ?

• NGINX Plus reçoit un datagramme UDP d'un client distant (192.168.99.1 : port ).
• NGINX Plus prend une décision d’équilibrage de charge en sélectionnant un serveur en amont (par exemple, 172.16.0.11) sur lequel écrire le contenu du datagramme. Avant de se connecter, NGINX Plus lie le côté local du socket en amont à l'adresse IP et au port du client distant.
• Le serveur en amont reçoit le datagramme envoyé par NGINX Plus, qui provient apparemment directement de l'adresse et du port du client distant.
• Le serveur en amont répond en renvoyant des datagrammes au client distant. Le serveur en amont définit l’adresse IP source et le port des datagrammes de réponse sur sa propre adresse IP locale et son propre port.
• L'adresse IP source (et le port si nécessaire) est réécrite soit par le serveur en amont (la configuration NAT d'origine ), soit par un routeur intermédiaire (la configuration NAT du routeur ).
• Le client distant reçoit les datagrammes, adressés avec le 4-tuple correct (adresses IP et ports source et destination).
• NGINX Plus ne s'attend pas à observer de datagrammes de réponse et ferme immédiatement le socket en amont.

Le résultat net est que les paquets de réponse contournent le traitement de la couche 7 dans NGINX Plus et vont directement au client distant.

Dépannage

Si la transparence IP ou le DSR ne fonctionnent pas comme prévu, utilisez les suggestions suivantes pour rechercher les causes possibles :

Exécuter en tant que root

Vérifiez que les processus de travail NGINX Plus sont configurés pour s’exécuter en tant que root . Dans le cas contraire, vous verrez un message d’erreur dans votre journal des erreurs similaire au suivant lorsque NGINX Plus tente de lier le socket à une adresse non locale :

setsockopt(IP_TRANSPARENT) a échoué (1 : (Opération non autorisée) lors de la connexion au client en amont : 192.168.99.1, serveur : , requête : "GET / HTTP/1.1", en amont : "http://172.16.0.11:80/", hôte : "192.168.99.10"

Tester avec ping

Vérifiez que vous pouvez envoyer une requête ping aux clients et aux serveurs à partir du proxy NGINX Plus. Les serveurs en amont ne peuvent pas envoyer de ping aux adresses IP des clients distants, sauf si vous créez d'abord la configuration de routage nécessaire et configurez l'intermédiaire NGINX Plus pour transférer les paquets.

Aucune plage IP qui se chevauche

Assurez-vous que les sous-réseaux IP utilisés par les clients distants ne sont pas directement connectés aux serveurs en amont. Si tel est le cas, deux problèmes risquent de survenir :

• La protection « filtrage de chemin inverse » de Linux peut rejeter silencieusement les paquets de NGINX Plus car l’adresse IP source est associée à un sous-réseau sur une interface différente.
• Les paquets de retour n'utilisent pas la route par défaut et sont plutôt envoyés directement au client distant connecté localement.

Utilisez tcpdump partout

Au fur et à mesure que vous établissez la configuration et testez chaque étape intermédiaire, exécutez tcpdump en continu sur chaque serveur pour vérifier que les paquets sont envoyés et reçus par les points de terminaison appropriés à chaque étape :

$ sudo tcpdump -i tout -n port tcp 80

Enquêtez sur tout comportement inhabituel à l’aide des vérifications répertoriées ci-dessous.

Vérifier les tables de routage

Vérifiez soigneusement les tables de routage sur chaque serveur, en accordant une attention particulière aux serveurs en amont :

# route -n Table de routage IP du noyau Destination Passerelle Genmask Drapeaux Métrique Référence Utiliser 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

Y a-t-il des itinéraires inattendus ? Pouvez-vous confirmer que tous les paquets du flux seront acheminés vers la bonne destination ? Rappelons que dans les configurations iptables et Router NAT, tous les paquets de sortie doivent être acheminés via le proxy NGINX Plus intermédiaire.

Paquets manquants

Si des paquets sont supprimés de manière inattendue ( tcpdump montre qu'ils sont envoyés par une machine mais non reçus par une autre), le filtrage de chemin inverse est un coupable silencieux potentiel. Pour désactiver temporairement le filtrage du chemin inverse, exécutez la commande suivante :

# pour f dans /proc/sys/net/ipv4/conf/*/rp_filter ; faire echo 0 > $f ; terminé

Permettre aux serveurs en amont d'atteindre les serveurs externes

Si vos serveurs en amont résident sur un réseau privé et utilisent NGINX Plus (ou un autre serveur) comme passerelle par défaut, vous souhaiterez peut-être configurer la passerelle pour permettre aux serveurs en amont d'atteindre des hôtes externes (Internet).

Vous devez activer la redirection IP pour que la passerelle puisse transférer les paquets des serveurs en amont ; la redirection IP est généralement désactivée par défaut. Si les serveurs n'ont pas d'adresses IP routables (ils utilisent des adresses privées telles que 172.16.0.0/24), vous devez également configurer le masquage IP sur les interfaces externes du serveur de passerelle :

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

Vérifiez que vous pouvez envoyer un ping à un serveur externe à partir de votre serveur interne en amont :

root@dev1:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) octets de données.
64 octets de 8.8.8.8 : icmp_seq=1 ttl=61 time=6.72 ms 64 octets de 8.8.8.8 : icmp_seq=2 ttl=61 time=5.49 ms ^C

Pour afficher votre configuration actuelle de transfert, de routage et de nat iptables , exécutez les trois commandes suivantes :

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

Obtenir de l'aide de NGINX

La configuration de la transparence IP ou du retour direct au serveur est complexe et d'autres périphériques réseau intermédiaires peuvent avoir un impact sur le déploiement en supprimant ou en réécrivant des paquets. Si vous avez besoin d'aide, l'équipe des services professionnels de NGINX est prête à vous aider.

Découvrez par vous-même la transparence IP et le DSR avec NGINX Plus – démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .