J'ai 2 web serveurs nginx derriere l'Ip Load Balancing normal (pas la sunrise).
Je n'arrive absolument pas a récupérer la vrai adresse ip des visiteurs à travaers l'IPLB.
J'ai bien configuré nginx avec:
```
set_real_ip_from xxx.xxx.xxx.xxx;
real_ip_header X-Forwarded-For; # d'apres la doc ca devrait etre celui-la
real_ip_recursive on;
```
Pour le xxx.xxx.xxx.xxx j'ai tout essayé:
- l'ip du NAT interne de l'IPLB (xxx.xxx.xxx.xxx/29)
- l'ip publique de l'IPLB
- un range des ips locales que je retrouve dans mes logs
- etc...
Rien n'y fait.
Mes installations de nginx ont bien le module ngx_http_realip_module.
Quelqu'un saurait m'aiguiller la dessus ?
Solution Réseau et Sécurité-old - Récupérer real IP derriere IPLB
Related questions
- Bloquer des plages d'adresses IP
11317
18.10.2024 14:46
- Fonctionnement du FW sur les instances public cloud
7496
30.11.2016 16:01
- VPN Site à Site entre OVH et infrastructure locale
6585
27.05.2023 12:19
- IP client impossible à récupérer
6464
31.12.2017 12:29
- IPLB et deux serveurs VPN
6315
11.10.2016 21:12
- SSL activé et non reconnu sur site wordpress
6122
17.02.2018 09:24
- vRack entre deux DC
6052
29.10.2016 15:34
- Parefeu OVH et ICMP
6031
13.05.2020 12:52
- [IPLB NextGen] Redirection http vers https
5413
13.04.2017 17:02
Une capture de ce a quoi ressemblent les ips que je récupère (elles ne correspondent pas au NAT qui est 10.71.64.8/29):

Bonjour,
Les ranges d'adresses IP utilisées pour faire le NAT ont changées lors de la migration qui a eu lieu fin Août, les nouvelles ranges correspondent bien aux entrées dans les logs (10.108.xxx.xxx).
La configuration qui devrait fonctionner :
set_real_ip_from 10.108.0.0/16;
real_ip_header X-Forwarded-For;
Merci pour ta réponse mais ça marche pas avec ça, j'avais déjà essayé.
C bien le bon header qui est transmis par ipbl (majuscules, minuscules) ?
Tu arrives à récupérer tes ips visiteurs avec une conf identique ?
Oui, je viens de valider à nouveau. Sans les options en question, l'ip réelle apparait en fin de ligne du log nginx par défaut. Avec les options, l'ip en premier élément dans les logs est remplacée par l'ip réelle.
Sans option :
10.108.24.201 - - [26/Oct/2016:11:26:38 +0200] "GET / HTTP/1.1" 200 612 "-" "curl/7.43.0" "213.186.33.34"
Avec option :
213.186.33.34 - - [26/Oct/2016:11:27:25 +0200] "GET / HTTP/1.1" 200 612 "-" "curl/7.43.0" "213.186.33.34"
Ma configuration de test est celle par défaut, au delta des options dont nous parlons :
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
set_real_ip_from 10.108.0.0/16;
real_ip_header X-Forwarded-For;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
@ArnaudJ, sur la page web nginx de base, ca marche, j'arrive a avoir la bonne ip cliente.
Par contre sur mon site en prod qui utilise https et http2, j'ai toujours les ips privées de l'IPLB.
Mon load balancing ne gere pas le ssl, je le gere au niveau des serveurs web.
D'après toi, c'est possible que ca soit ca qui pose problème (le ssl), ou je dois chercher autre part dans ma conf ?
Sans aucun doute, c'est bien cela qui provoque l'absence du header.
Dans la mesure ou le flux est chiffré, IPLB est incapable de le modifier, et donc d'ajouter le header X-Forwarded-For.
Il y a plusieurs manière de gérer ce cas.
1) Tu remontes le certificat coté IPLB et tu laisse le flux en clair entre IPLB et ton serveur
2) Tu remontes le certificat coté IPLB et tu le laisse aussi coté serveur, en précisant a IPLB, via l'api, que tu souhaite joindre ton serveur en https. Le flux sera alors déchiffré coté IPLB, et re-chiffré avant de joindre ton serveur.