vault backup: 2026-03-10 07:51:11

articles/2026/Maîtriser le Forwarding avec NPMplus et Apache.md

@@ -0,0 +1,75 @@
+---
+title: Maîtriser le Forwarding avec NPMplus et Apache
+description: 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é.
+tags: []
+date: 2026-03-10 07:43
+lastmod: 2026-03-10 07:51
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: 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` :
+
+```Nginx
+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`) :
+
+```Apache
+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 !