Comment vérifier qu’un proxy inverse envoie la bonne adresse IP du client

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Verify a Reverse Proxy Is Sending the Correct Client IP

Vérifiez le transfert d’IP client en comparant une source externe connue avec chaque en-tête proxy et l’adresse finale analysée du backend.

Un reverse proxy termine la connexion client, donc le backend voit normalement l’adresse socket du proxy à moins que ce dernier ne transmette des métadonnées de requête fiables. Le test doit distinguer l’adresse du pair direct des Forwarded, X-Forwarded-For et X-Real-IP, documenter chaque saut de confiance, et prouver qu’un client internet ne peut pas falsifier la valeur utilisée pour les logs, les limites de débit ou le contrôle d’accès.

Créer un Test d’IP Client Connue Depuis l’Extérieur du Domicile

Utilisez un appareil en données mobiles ou sur un autre réseau externe et enregistrez son adresse IPv4 ou IPv6 publique immédiatement avant la requête. Envoyez un chemin unique, une valeur de requête ou un horodatage via le reverse proxy public.

MDN décrit X-Forwarded-For comme un en-tête de facto pour préserver l’adresse client d’origine à travers les connexions proxy.

Collectez le journal du proxy de bord, tout journal de proxy intermédiaire, et le journal de l’application backend pour cette requête unique. Sans source connue et horodatage corrélé, plusieurs utilisateurs simultanés peuvent rendre la chaîne d’en-têtes ambiguë.

Enregistrer le Pair Socket et Chaque En-tête Transféré

Au backend, consignez séparément l’adresse TCP directe du pair des Forwarded, X-Forwarded-For, X-Real-IP et tout en-tête client spécifique au CDN. Ne pas écraser les valeurs brutes lors du premier test.

Une analyse pratique de la gestion de l’IP client « réelle » avertit que la précision dépend de la manière dont le proxy définit ou ajoute les en-têtes et si les valeurs antérieures peuvent être falsifiées. Le modèle complet de confiance proxy doit correspondre à l’architecture réseau réelle.

Le pair socket backend doit correspondre au proxy de confiance immédiat, tandis que l’adresse client sélectionnée doit correspondre à l’appareil de test externe. Si le backend ne journalise que l’adresse du proxy, la création ou l’analyse des en-têtes est manquante.

Vérifier Comment Chaque Proxy Ajoute ou Remplace l’En-tête

Inspectez chaque saut depuis le CDN ou tunnel jusqu’au proxy de bord, proxy interne et application. Enregistrez si chaque saut ajoute à une liste existante, remplace une entrée non fiable, ou transmet l’en-tête inchangé.

Sling Academy explique que NGINX peut définir X-Real-IP depuis la connexion immédiate et ajouter une chaîne avec proxy_add_x_forwarded_for.

Configurez le premier edge de confiance pour supprimer ou remplacer les en-têtes de transfert fournis par le client, puis ajoutez les adresses aux sauts internes contrôlés. Évitez d’accepter aveuglément la valeur la plus à gauche ou la plus à droite sans définir combien de proxies sont fiables.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Configurer le Backend pour Ne Faire Confiance Qu’aux Adresses Proxy Connues

Définissez la liste des proxies de confiance de l’application ou du serveur web aux adresses exactes des reverse proxies ou sous-réseaux contrôlés. Confirmez que les connexions directes depuis un LAN ordinaire ou des clients internet ne sont pas traitées comme sources d’en-têtes fiables.

L’explication d’Ip2Geo note que la connexion de l’application provient du load balancer ou reverse proxy et que l’analyse de l’IP originale en toute sécurité nécessite une règle de saut de confiance plutôt que d’accepter une entrée arbitraire.

Si l’adresse proxy change à cause de conteneurs, réseaux superposés ou CDN, documentez la plage prise en charge et mettez-la à jour délibérément. Ne faites pas confiance à toutes les adresses privées simplement parce que le proxy en utilise une actuellement.

Effectuer un Test d’En-tête Falsifié

Depuis l’appareil de test externe, envoyez une valeur falsifiée X-Forwarded-For ou Forwarded tout en vous connectant via le proxy réel. Comparez l’en-tête brut entrant, l’en-tête proxy normalisé, et l’adresse client sélectionnée par le backend.

Le résultat correct est que le edge de confiance remplace ou ajoute en toute sécurité à l’entrée non fiable et que le backend sélectionne l’adresse selon le nombre de sauts de confiance documenté. Une adresse falsifiée ne doit pas devenir la valeur utilisée pour l’authentification ou la liste blanche.

Répétez un test direct vers le backend depuis un segment LAN si ce port est accessible. Le backend doit ignorer les en-têtes transférés d’un client direct non fiable et enregistrer le pair socket réel.

Valider IPv4, IPv6 et les Chemins Multi-Proxy

Répétez le test via IPv4 et IPv6, via le nom d’hôte public normal, et via tout CDN, tunnel ou proxy secondaire utilisé en production. Confirmez que les logs conservent les formats d’adresses valides et ne tronquent pas la chaîne.

Le guide ZimaSpace sur l’identité de requête reverse-proxy fournit le contexte entourant l’importance des valeurs transférées correctes au-delà de la simple journalisation.

Le proxy est vérifié uniquement lorsque la source connue correspond à l’IP client analysée, que les proxies de confiance restent visibles dans la chaîne brute, que les tentatives de falsification échouent, et que les contrôles de sécurité utilisent la valeur normalisée de manière cohérente. Revérifiez après avoir ajouté un CDN, un tunnel ou un autre saut proxy.