3.7 KiB
title, description, tags, date, lastmod, type, category, status
| title | description | tags | date | lastmod | type | category | status | ||
|---|---|---|---|---|---|---|---|---|---|
| Maîtriser le Forwarding avec NPMplus et Apache | Marre de voir l'IP de votre reverse proxy dans vos logs Apache ? Découvrez comment configurer NPMplus et le module mod_remoteip pour restaurer la visibilité de l'IP réelle de vos visiteurs. Un guide détaillé pour DevOps incluant la gestion du header X-Forwarded-For et les bonnes pratiques de sécurité. | 2026-03-10 07:43 | 2026-03-10 07:51 |
|
|
terminé |
Maîtriser le Forwarding avec NPMplus et Apache
Par Cédrix | Date d'édition : 10 mars 2026
Dans l'architecture moderne des micro-services, le Reverse Proxy est devenu la pierre angulaire de la sécurité et de la flexibilité. Que ce soit pour la terminaison SSL, le load-balancing ou la gestion des noms de domaine, des outils comme NPMplus (Nginx Proxy Manager Plus) facilitent grandement la vie des DevOps.
Pourtant, un problème récurrent hante les administrateurs : la disparition de l'adresse IP réelle du client dans les logs applicatifs. Pourquoi votre serveur Apache ne voit-il que l'IP locale du proxy ? Comment restaurer la visibilité sans briser la chaîne de confiance ? Plongée au cœur des headers HTTP.
Le Problème : L'illusion de la connexion directe
Lorsqu'un utilisateur consulte votre site, il ne parle pas directement à Apache. Il établit une connexion TCP avec NPMplus. Pour Apache, le "client", c'est le proxy.
Le risque : Si votre Apache croit que tout le trafic provient de
192.168.100.95(votre proxy), vos outils d'analyse (Matomo, AWStats) sont aveugles, et vos outils de sécurité (Fail2Ban) risquent de bannir votre propre infrastructure au premier faux pas d'un utilisateur.
La Solution : Le Header X-Forwarded-For
Pour pallier cela, le reverse proxy doit devenir un "messager". Avant de transmettre la requête à Apache, il ajoute une étiquette à l'enveloppe HTTP : le header X-Forwarded-For (XFF).
1. La configuration du messager (NPMplus)
NPMplus utilise Nginx sous le capot. Pour qu'il transmette l'identité du visiteur, il doit injecter ces directives dans la configuration du bloc location :
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
$proxy_add_x_forwarded_for est crucial car il conserve la trace de tous les proxys traversés (si l'utilisateur passe déjà par un VPN ou un CDN comme Cloudflare).
Le Récepteur : Configurer Apache avec mod_remoteip
Côté Apache, il ne suffit pas de recevoir le header ; il faut lui donner une valeur légale. C'est ici qu'intervient le module mod_remoteip.
Étape A : Établir la relation de confiance
Apache refuse par défaut de croire n'importe quel header XFF (car n'importe quel pirate pourrait injecter une fausse IP). Vous devez définir une liste blanche d'IP de confiance.
Dans votre configuration (/etc/apache2/conf-available/remoteip.conf) :
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 192.168.100.95
Point d'attention : Une simple erreur de frappe ici, et Apache ignorera le header, revenant à l'affichage de l'IP du proxy.
Étape B : Réécrire le format de journalisation
Par défaut, Apache utilise la variable %h (hostname) dans ses logs. Pour afficher l'IP "extraite" par le module remoteip, il faut passer à la variable %a (peer IP address).
Modifiez votre LogFormat dans apache2.conf :
Apache
# Remplacez %h par %a
LogFormat "%a %l %u %t \"%r\" %>s %b" combined
Vérification finale
Un simple tail -f /var/log/apache2/access.log vous confirmera immédiatement si le réglage est opérationnel. Si vous voyez une IP publique au lieu de votre IP locale, vous avez réussi votre mise en production !