Nginx (VIII) 记录并获取客户端的真实 IP 地址
最编程
2024-06-03 14:09:07
...
一 nginx关于日志的配置
备注: main'不是日志级别',而是采用的'日志格式'
日志官方参考
(1)错误日志配置
针对虚拟主机设置
server {
access_log /data/log/www; '核心'
listen 80;
server_name www.wzj.com;
location / {
root /data/www/www;
index index.html index.htm;
}
error_log logs/error_www.wzj.com.log error; '核心'
}
access_log off; --> 关闭access_log,即'不记录访问日志'
(2)日志格式
注意:log_format配置'必须放在http内',否则会出现'警告'信息
$request_time:'整个请求'的总时间
$upstream_response_time:请求过程中,'upstream的响应时间' -->'502和504报错'
二 Nginx日志分隔
三 Nginx日志了解业务状态
四 通过代理获取客户端真实的ip
具体的业务场景: 通过'WAF和CDN'去获取客户端的'真实ip'
CDN获取客户端真实的ip
默认 'ngx_http_realip_module' 这个模块是安装的 --> Nginx作为负载均衡'获取真实IP'依赖该http_realip_module模块
环境说明: A nginx'配置了反向代理','后端服务器'B也是nginx,'后端服务器B'去'获取客户端真实的ip',而'不是'代理服务器的ip
++++++++++'各组件的说明'++++++++++
'proxy':172.25.2.100
'backend':172.25.2.200、172.25.2.201
'client': 172.25.2.202
1)代理服务器的配置
'错误的'方式
备注:'正确'方式
2)backend的首页面的修改
3)客户端测试
备注: 172.25.2.202没有做本地解析'/etc/hosts',curl通过'--resolve'来进行本地解析
查看proxy的日志
查看两个backend的日志
结论: 很明显'默认的配置',backend并不能'获取客户端真实的ip'
4)获取客户端的ip
各种场景获取客户端真实的ip
CDN下nginx获取用户真实IP地址
备注: 从上面的日志中我们可以看出'proxy'已经获取客户端的ip,我们只需要让'proxy'在转发请求的时候'透传'出去即可
++++++++++++++'分割线'
备注: 我们需要知道整个流量的走向,换句话说'经过了多少个代理'-->'proxy'
与代理相关的变量
场景1: '不修改'backend的日志格式
+++++++++++++'分割线'+++++++++++++
上面我们已经知道:默认情况下,'remote_addr'是跟其直连的ip,可能为'proxy'或者'client'
思路1: proxy在透传的时候直接修改'backend'要获取的'remote_addr'的数值
log_format默认的 '$http_x_forwarded_for'就是'proxy_set_header X-Forwarded-For $remote_addr;'这个'代理转发请求头'的值
++++++++++'分割线'++++++++++
从'默认的日志'可以看出: 该变量的值为'-'表示置空,即表示设置该请求头
172.25.2.200 - - [26/Dec/2020:22:18:53 -0500] "GET / HTTP/1.0" 200 7 "-" "curl/7.29.0" "-"
修改proxy的配置文件
测试
两个'backend'都'获取客户端的真实ip'
'场景2': 修改proxy的配置文件-->修改'backend'的日志格式
5)二层代理
场景说明: 172.25.2.202('client') --> 172.25.2.100(proxy) --> 172.25.2.200(proxy) --> 172.25.2.201('backend')
核心两个请求头
proxy_set_header X-Real-IP $remote_addr;
获取的是'直接TCP连接'的客户端IP这个是'无法伪造'的
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; --> 特点: 将上一层的'X-Forwarded-For' 进行叠加传给'proxy_add_x_forwarded_for'作为心得XFF头
拿到用户从请求源头到应用'所经过的各个代理IP呢'
一级代理
这个理解不错
只有'客户端直接请求到'的那个'proxy nginx'能够拿到'客户端的真实IP',所以第一级'proxy nginx'配置了
proxy_set_header X-Real-IP $remote_addr;
备注: 这个请求头在'日志中没有体现' --> '$http_x_real_ip'加入日志的格式中
原因: 'http_x_real_ip' 记录的是和自己直接相连接的'上游服务器的ip',也即自己接受的请求是从哪里'发送或转发'过来的
+++++++++++++++'分割线'+++++++++++++++
说明:下面的日志中都没有'进行改动'
说明: 实际上'X-Real-IP'这个请求头在这里'没有意义',日志中'没有体现'的到
二级代理
客户端测试
说明: 显然每级'proxy'中XFF为-->'client ip proxy1 proxy(n-1)' -->'以空格隔开'
备注:n>2 为上面的格式
说明:n=1为'-',n=2为'client ip'
说明: 'remote_addr' 从二级代理一直到第最后一级的代理,包括backend,都是'第一级'代理的IP
+++++++++++++'思考'
为什么backend的'remote_addr'不是上一级的'proxy'的IP?
备注: '后台服务器'获取真实的客户端ip地址,headers中的X-Forwarded-For选项中'逗号前第一个'ip就是真实客户端ip
比较有研究价值的博客
从限流谈到伪造 IP
获取客户端的ip
推荐阅读
-
五种简单易懂的PHP方法获取IP地址,并附带用户登录日志记录实例演示
-
PC 服务器带外管理批量自动配置-BMC 批量配置的原理如下: A.前提条件:所有服务器的BMC地址在到达时出厂默认设置为DHCP(目前到达服务器的BMC地址均为静态地址,如BMC默认为192.168.2.100。) B、网络物理拓扑图:一台DHCP服务器(只有在执行脚本期间才会开启DHCP服务,平时不会开启,以最大限度控制风险)---- 已连接到待配置BMC服务器的网络(以下简称客户端); C、用户需要操作:提前为服务器BMC规划地址,分配静态IP(手动分配给服务器BMC的静态IP与我们目前的做法保持一致,一方面便于管理,一方面可以有效降低DHCP带来的不可控风险),并将服务SN的序列号与实际分配的静态IP做一个对应,形成ip.txt配置文件并上传到DHCP服务器; D.实现原理(简要步骤):在现有的BMC管理网区新增一台DHCP服务器,并为其预先划分一个IP地址池(初始定位50个),待配置BMC的服务器接入网络后,首先通过DHCP获取IP地址池中的一个临时IP,从而与DHCP服务器建立临时通信,然后DHCP服务器检测到该客户端,DHCP服务器检测到该客户端有静态IP地址后,形成ip.txt 配置文件并上传到 DHCP 服务器。DHCP 服务器检测到客户端后,会主动获取其序列号 SN,并根据该 SN 在用户上传的配置文件(ip.txt)中获取其对应的静态 IP,然后 DHCP 服务器将该静态 IP 配置给客户端(红鱼协议),客户端获取静态 IP 后关闭 DHCP-客户端。客户端获得静态 IP 后,关闭 DHCP 客户端服务,所有客户端配置完成后,DHCP 服务器关闭 DHCP 服务器服务。 这种方法的优点是 最终登陆服务器 BMC 的是一个静态 IP,由用户手动分配,台账易于管理。 只有在执行脚本时,DHCP 服务器才会开启 DHCP 服务,平时则关闭,最大限度地降低了风险。 几种特殊情况及相应的处理逻辑:
-
Nginx (VIII) 记录并获取客户端的真实 IP 地址
-
通过 nginx 进行 CDN 加速,获取网站访客的真实 IP 地址
-
通过 Node.js、Express 框架获取客户端 IP 地址,并获取 IP 对应的城市名称"????简单实用,收藏不丢
-
在阿里云中,如何获取通过负载均衡访问的客户端的真实IP地址?