Bonjour,
J'ai appliqué la procédure à la lettre mais rien à faire : https://docs.ovh.com/fr/iplb/http-headers/#transmissions-des-en-tetes-a-php_1. En effet, j'ai activé le remoteip dans apache et ajouté les deux lignes décrites dans sa conf. Toutefois, apache continue de voir uniquement l'adresse (les adresses) du load balancer et $_SERVER ne contient aucune variable de type FORWARDED.
La même procédure est aussi décrite dans https://www.globo.tech/learning-center/x-forwarded-for-ip-apache-web-server/ avec une modification supplémentaire sur les logs d'apacahe et mais la aussi les logs d'apache continuent de voir les adresses du load balancer.
Ma question : Vous êtes sur que vous renseigner ben et bien le X-Forwarded-For à la sortie du load balancer ou du moins avec la donnée client ?
Jamal
IP client impossible à récupérer
Related questions
- Bloquer des plages d'adresses IP
11353 
18.10.2024 14:46
- Fonctionnement du FW sur les instances public cloud
7510 30.11.2016 16:01
- VPN Site à Site entre OVH et infrastructure locale
6599 27.05.2023 12:19
- IPLB et deux serveurs VPN
6365 11.10.2016 21:12
- SSL activé et non reconnu sur site wordpress
6136 17.02.2018 09:24
- vRack entre deux DC
6087 29.10.2016 15:34
- Parefeu OVH et ICMP
6045 13.05.2020 12:52
- [IPLB NextGen] Redirection http vers https
5427 13.04.2017 17:02
- Récupérer real IP derriere IPLB
5244 25.10.2016 12:20
Je me réponds à moi m^me : Oui ça ne marchera pas car la procédure s'applique sur du HTTP et mes frontends/fermes sont en TCP (Pas le choix : https://community.ovhcloud.com/community/fr/ip-lb-creation-infra-multi-dc?id=community_question&sys_id=280571c49d5e4e901e11a21128f2cf37).
La question est alors désormais : comment faire pour récupérer l'ip client si on est en TCP ? (Debian 8, apache 2.4.10).
Jamal
Bonjour,
de ce que j'ai compris voici le guide pour votre configuration : https://docs.ovh.com/fr/iplb/proxyprotocol/
Cordialement, janus57
Bonjour,
Je te remercie janus57 pour ta réponse. J'avais vu ce guide mais j'avais voulu éviter car entre un module sur github non à jour depuis 3 ans et un module sur une version expérimentale d'apache, ce ne faisait pas trop sérieux.
J'ai quand même passé quelques heures à essayer ce qui est dans ce guide et voilà mes conclusions :
- Je confirme pour le remoteip, RemoteIPProxyProtocol n'est pas disponible en 2.4.29.
- Pour ce qui est de mod-proxy-protocol : Je l'ai compilé et déployé mais ne fonctionne pas non plus malgré les confirmations du guide. En effet, apache démarre bien mais rejette toutes le requêtes qu'ils reçoit avec l'erreur `[Mon Jan 01 18:02:32.046191 2018] [proxy_protocol:error] [pid 1302] [client 10.109.2.136:22625] ProxyProtocol: no valid header found`.
Bien évidemment, j'ai précisé sur le serveur de la ferme le protocole du proxy v1 puis v2 mais que dalle.
Bref, si on ajoute à ceci un nombre (j’arrête de compter) de bugs rencontré sur l'interface et l'api, tout ceci semble un peu bâclé.
Une dernière : Deux frontends (80,443), un sur GRA et l'autre sur BHS avec des serveurs up sur les deux mais tout le traffic passe par BHS même venant de la France !! La même config fonctionnait encore hier. Il n'y a qu'OVH qui est capable de ce genre d'exploit.
En résumé, si vous cherchez un Load Balancer avec un fonctionnement très basique sans multi DC, ni multi sites, bref, un simple dispatch de charge alors vous pouvez utiliser la nouvelle offre d’OVH (c’est ce que j’utilisais en beta depuis un an). Si en revanche votre besoin se complexifie un petit peu, allez voir les services AWS (Route 53) par exemple et revenez peut être dans 2 ou 3 ans quand ils auront terminé le travail.
En ce qui me concerne, je jette l’éponge.
Jamal