首页 > 所有文章 > 行业 >文章详情

多层nginx获取真实ip(nginx 实战)

时间:2024-02-13 12:39:58 浏览量:319

最近部门有个需求,需要对一些客户端IP做白名单,在白名单范围内,才能做一些业务操作。按我们的部门的一贯做法,我们会封装一个client包,提供给业务方使用。( 注: 我们的项目是运行在K8S上)本以为这是一个不是很难的功能,部门的小伙伴不到一天,就把功能实现了,他通过本地调试,可以获取到正确的客户端IP,但是发布到测试环境,发现获取到的客户端IP一直是节点的IP,后面那个小伙伴排查了很久,一直没头绪,就找到我帮忙一直排查一下。今天文章主要就是来复盘这个过程

这逻辑看着貌似没问题,因为本地调试可以获取到正确的客户端IP,而测试环境获取不到,大概率是环境有问题。于是就把方向转为定位环境的差异性

我们测试环境的访问流程为客户端–> k8s service nodeport—>pod

通过搜索在https://kubernetes.io/zh-cn/docs/tutorials/services/source-ip/
在这篇文章找到答案。

Kubernetes Service 转发场景下,无论使用 iptbales 或 ipvs 的负载均衡转发模式,转发时都会对数据包做 SNAT,即不会保留客户端真实源 IP

整体流程

上文的链接也贴了解法

具体步骤就是

1、步骤一:业务pod的配置调度到指定节点

示例

2、步骤二:将业务的service yaml 默认配置的externalTrafficPolicy: Cluster改为 externalTrafficPolicy: Local

示例

3、步骤三:通过指定在pod上的node节点 nodeport进行访问

示例

假设部署了node1和node2节点,只能通过node1:nodeport才能访问到具体业务,如果通过node2:nodeport,则请求的数据包会被抛弃

通过上述的方案,解决了在测试环境通过service nodeport获取不到正确客户端ip的问题

当测试环境没问题后,将项目发布到UAT环境,然后不出意外的话,又出意外了。

uat的访问流程为 客户端- -> nginx keepalive --> ingress --> pod

因为访问方式不一样,因此解法又有差异。通过搜索了解到* 用户ip的传递依靠的是X-Forwarded-参数。但是默认情况下,ingress是没有开启的 因此我们需要开启。开启需要如下参数

详细的介绍可以查看官网

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-forwarded-headers

我们在Ingress Nginx Controller 的 Configmap添加如下内容

配置后,发现没鸟用,没有效果。后面查了很多资料,发现网上都是那么配的,后面就觉得是不是nginx - keepalive 这一环节出了啥问题,于是就问了一下运维,看他nginx那边是否有配置X-Forwarded-For,他说没有,那我就问他能否配置一下,他的回答是因为nginx那边启用了 ssl_preread 模块无法使用X-Forwarded-For

后面就问他能否改下,他回答说是后面公司要采用F5了,到时候在配置一下就好。而他目前事情比较多,没时间帮我弄这个。

由于业务比较赶,运维又没空搞,于是就和业务那边沟通,采取了折中方案,就是通过自定义请求头,我们在client包配置了一个属性,那个属性用来让业务将白名单ip填进去,示例

在业务项目启动的时候,client包会自动将配置的白名单塞入请求头

服务端那边获取客户端ip做如下改造

其实做的事情,就将原来的工具类稍微重构了一下,并加入自定义请求头X-Custom-Forwarded-For

这次的复盘总结就是很多东西没那么想当然,有些简单的东西,里面可能也有有坑。当遇到跨部门合作时,如果遇到一些不可抗力因素,我们除了向上反馈之外,还要有兜底方案,不然会非常被动