Méthodes pour récupérer l'adresse IP source du client

Dans certaines situations, nos services nécessitent l'utilisation de l'adresse IP du client pour des raisons commerciales ou de sécurité spécifiques. Cependant, le scénario habituel implique que le trafic passe par plusieurs réseaux, équilibreurs de charge ou services de proxy avant d'atteindre le service réel. À chaque étape de ce processus, l'adresse IP d'origine du client peut être perdue, laissant notre service avec uniquement l'adresse IP du réseau précédent. Ce résultat n'est pas idéal pour nous.

En raison de la complexité de notre pile technologique, l'obtention de l'adresse IP du client implique l'utilisation de diverses méthodes, parfois en combinaison.

Gestion de l'adresse IP du client via NAT

Dans certaines infrastructures IDC établies ou louées par les utilisateurs, nos services peuvent résider dans un réseau LAN séparé derrière une passerelle. Lorsque les clients tentent de se connecter à nos services depuis un réseau externe, le trafic est acheminé via la passerelle.

Un scénario similaire peut survenir lors de l'utilisation de services cloud. Le réseau VPC fourni par les plateformes de cloud public fonctionne comme un réseau LAN indépendant, isolé des autres VPC et d'Internet. Par conséquent, une passerelle est nécessaire pour faciliter l'accès à Internet externe et se connecter à des services externes.

Cette passerelle, qui pourrait être un routeur ou un pare-feu, offre généralement des services de traduction d'adresse DNAT (Destination NAT) pour les services internes. Cela implique que la passerelle détient une ou plusieurs adresses IP publiques et redirige le trafic de ports spécifiques sur l'adresse IP publique vers des ports spécifiques sur une adresse IP interne. La passerelle gère le transfert de trafic et le mappage de ports. Cependant, en raison de la modification de l'adresse source dans l'en-tête du paquet IP original par la passerelle, nos services au sein du réseau interne ne peuvent identifier que l'adresse IP de la passerelle, et non l'adresse réelle du client.

Historiquement, les capacités DNAT fournies par les dispositifs ou logiciels réseau étaient relativement basiques. Ils fonctionnaient principalement au niveau 3 et manquaient de capacités de manipulation et de conscience des charges utiles des couches plus profondes. Leur objectif principal était l'exposition des services, et ils ne pouvaient pas transmettre l'adresse IP du client en aval. De plus, en raison des limitations de performance de ces dispositifs ou logiciels, il y avait des contraintes sur le nombre de connexions actives et le nombre maximal de nouvelles connexions qu'ils pouvaient gérer. La mise à l'échelle sans mise à niveau matérielle était souvent difficile, les rendant moins adaptables à l'environnement dynamique d'aujourd'hui.

Pour répondre à ces limitations, nous nous tournons vers l'équilibrage de charge, qui possède des capacités de manipulation de trafic plus avancées.

Adresse IP du client dans l'équilibrage de charge

En général, l'équilibrage de charge est principalement catégorisé en deux types selon leur couche de travail : la couche 4 et la couche 7, correspondant respectivement aux flux de données TCP et au trafic applicatif (représenté par HTTP).

Contrairement aux passerelles IP, l'équilibrage de charge évite de modifier l'en-tête du paquet IP. Au niveau du paquet IP, il ne fait que du transfert transparent. Par conséquent, contrairement au DNAT discuté précédemment, l'équilibrage de charge assure le passage correct de l'adresse IP source contenue dans le paquet IP aux composants derrière l'équilibreur de charge.

Pour l'équilibrage de charge de couche 4, après avoir accompli le transfert de trafic de base, les services suivants peuvent récupérer avec précision l'adresse IP du client sans nécessiter de traitement spécial. Dans des scénarios exceptionnels, il peut utiliser le Proxy Protocol. Cela implique l'ajout d'une nouvelle section avant la charge utile du trafic original, englobant l'adresse IP du client. D'autres serveurs proxy inverses ou le service lui-même derrière l'équilibreur de charge peuvent ensuite interpréter les données du Proxy Protocol pour obtenir l'adresse IP du client.

Pour l'équilibrage de charge de couche 7, il possède des capacités de traitement de trafic plus profondes. Il peut directement transmettre l'adresse IP source au niveau du protocole HTTP. Une approche courante est l'utilisation de l'en-tête HTTP X-Forwarded-For. Le composant d'équilibrage de charge extrait l'adresse IP source du paquet IP du trafic, puis analyse et réécrit la requête HTTP. Il insère un nouveau champ XFF dans son en-tête de requête, incorporant la valeur de l'adresse IP du client.

HTTPS présente un défi particulier en raison de sa charge utile chiffrée, rendant le composant d'équilibrage de charge incapable de manipuler directement ses en-têtes HTTP. Dans de telles situations, les approches suivantes peuvent être envisagées :

• Sans exigence spécifique, traiter le trafic HTTPS comme un trafic TLS standard et le transférer directement au niveau de la couche 4 est une option. Dans ce scénario, l'adresse IP du client peut toujours être transmise au service derrière l'équilibreur de charge via l'en-tête du paquet IP.

• Lorsque la fonctionnalité de couche 7 est nécessaire, héberger le certificat TLS sur le composant d'équilibrage de charge permet la terminaison TLS. Ce processus implique la suppression du chiffrement TLS au niveau de l'équilibrage de charge, utilisant HTTP en clair sur le LAN derrière l'équilibreur de charge, ou établissant une nouvelle connexion HTTPS vers le service au lieu d'un transfert direct. Cela permet au composant d'équilibrage de charge de manipuler à nouveau le trafic HTTP original et de continuer à transmettre l'adresse IP en utilisant la méthode XFF.

Grâce à une gestion nuancée du trafic, l'équilibrage de charge offre diverses méthodes pour transmettre l'adresse IP du client au service backend. Les implémentations représentatives des composants d'équilibrage de charge incluent les services ELB basés sur le cloud, le matériel F5 BIG-IP, le Linux Virtual Server (LVS) basé sur le noyau Linux, et le logiciel utilisateur NGINX.

Transmission de l'adresse IP du client dans les services CDN

Parfois, nous utilisons les services CDN fournis par les plateformes de cloud public pour améliorer la vitesse d'accès des utilisateurs à nos services. Leur fonctionnement est similaire à celui d'un serveur proxy inverse de couche 7, mais dans un contexte plus large, les CDN peuvent être considérés comme faisant partie du domaine de l'équilibrage de charge.

Les services CDN fournissent généralement des capacités de terminaison TLS et peuvent incorporer l'adresse IP du client dans les requêtes HTTP envoyées au service. Par exemple, le service CDN AWS CloudFront prend en charge la transmission de l'adresse IP du client en utilisant la méthode XFF, ressemblant à l'approche utilisée dans l'équilibrage de charge de couche 7.

Utilisation de la passerelle API

Alors que les composants d'équilibrage de charge offrent généralement des capacités de contrôle de base pour le trafic, les API fournies par les équilibreurs de charge basés sur le cloud ou matériels peuvent être difficiles à aligner avec nos besoins commerciaux spécifiques. Dans de tels scénarios, nous nous tournons vers des composants plus adaptables pour appliquer des stratégies sur mesure à nos services. C'est là qu'une passerelle API, comme Apache APISIX ou API7 Enterprise, entre en jeu.

APISIX et API7 Enterprise prennent en charge le Proxy Protocol, permettant la récupération de l'adresse IP du client depuis l'équilibreur de charge.

De plus, ils disposent d'un plugin nommé "real-ip", similaire au module ngx_http_realip_module de NGINX. Ce plugin récupère l'adresse IP du client depuis une source et l'utilise pour la transmission en aval et la journalisation. Le plugin real-ip sur APISIX et API7 Enterprise améliore la fonctionnalité trouvée sur NGINX. Il permet l'activation ou la désactivation dynamique de la fonctionnalité de l'adresse IP source réelle et étend les sources de l'adresse IP du client au-delà des contraintes du module ngx_http_realip_module, qui est limité aux en-têtes HTTP et au Proxy Protocol. Il peut exploiter toute variable étendue de NGINX ou APISIX, telle que les paramètres de requête ou les champs de formulaire POST.

Résumé

En tirant parti d'une combinaison de technologies à différentes couches, nous pouvons efficacement transmettre l'adresse IP du client à travers chaque composant du service, répondant à la fois aux besoins commerciaux et de sécurité.

Pour en savoir plus sur les solutions de gestion d'API, contactez API7.ai.