出于安全考虑，近期在处理一个记录用户真实IP的需求。本来以为很简单，后来发现没有本来以为的简单。这里主要备忘下，如果服务器处于端口回流（hairpin NAT）,keepalived，nginx之后，如何取得客户端的外网IP。
来自客户端PC的流量路径如上，在这样的拓扑中，在应用服务中取得，客户端PC的外网ip，可能会遇到哪些问题呢？（ip 编的随意，为便于说明，不考虑合理）。
- 编程实现
Java 为例，这个我会。
public static String getClientIP(HttpServletRequest request) {String remoteAddr = request.getRemoteAddr();return remoteAddr;}
运行一下，输出呢是 3.3.3.3 。 这是因为这个API所取得的是IP数据包的源地址。Nginx的反向代理时工作在应用层的，当他收到一个http请求时，会对应生成一个新的请求，发送给应用服务，这个请求的IP包的源地址是Nginx服务器的IP即3.3.3.3。
- Nginx头部注入
因为是应用层，那这个请求ip包的源地址肯定就是3.3.3.3了，但是在应用层我们可以附加一点信息，以便后面的应用服务，可以通过这个附加信息，了解这个请求对应的原始源地址。这个我也会。
在Nginx 中配置。
server {...proxy_set_header X-Real-IP $remote_addr;
在应用层http协议中，加一个http header。X-Real-IP:$remote_addr. $remote_addr 是一个预设变量，代表所代理转发请求的原始源ip地址。
在Java 程序中，读取对应的附加信息
public String getRealIp(HttpServletRequest request) {String realIp = request.getHeader("X-Real-IP");if (realIp != null && !realIp.isEmpty()) {return "Client's Real IP: " + realIp;} return "";}
运行一下，此时输出2.2.2.2。 显然我们向前推进了一步。
- Keepalived负载均衡模式
印象里这里keepalived的主要作用应该是解决nginx 代理服务器的单点问题的，似乎也被配置为负载均衡了？翻了下配置文件，实际的情况如下。
运维大壮说他配置keepalived 时候多考虑了一步，如果机器活着，nginx 挂了怎么办，于是又做了一层负载均衡（这种情况虚拟IP不会漂移到右边的备机）。他说的也确实不是没有道理。keepalived 的负载均衡貌似是工作在第三层的，那肯定在负载均衡的时候，又对ip包的源地址进行了修改。这是网络层，向nginx 这样附加信息肯定是不行了。于是，翻了翻手册发现，keepalived 的负载均衡支持三种路由模式，NAT，Direct Routing 和 Tunneling。
NAT 模式，会修改源IP，出入流量都会经过负载均衡器。而DR模式，会直接修改MAC地址，那回程流量就不再经过负载均衡器了，也就意味这种模式，源地址不会被修改，回程流量会直接发送给源ip地址。
DR模式有个要求，就是负载均衡器需要能知道后端服务的MAC地址，这是依赖于ARP实现的，也就是，要求负载均衡器和后端服务器在同一广播域。恰好我门可以满足。于是。
virtual_server 192.168.11.242 80 {
……
lb_kind DR
……
将负载均衡路由模式切换为DR模式。重新看一下这次，取得客户端地址变成了 1.1.1.1, 这一步一坑。为什么到达keepalived的ip包的源地址会变成，出口路由器的外网地址呢？
- 路由器端口回流（Hairpin NAT）
离胜利是不远了，此时见多识广的大壮说，这应该是跟端口回流有关，之前有个系统也是类似问题， 你的web端口配置了端口回流，如果关掉端口回流就可以取得外网地址了。什么是端口回流？
首先，路由器做了端口映射，1.1.1.1:80->192.168.0.2:80
服务器A，由于某些原因，不方便使用内网地址192.168.0.2访问B，而要通过外网IP或者域名访问服务器B，即访问1.1.1.1:80， 按端口转发规则，路由器会将这个来自于内网接口的流量再次转发回内网服务器B，形成了一个180度的急弯——发卡弯，这也就是Haripin NAT的名字由来，十分形象。
如果不做设置，服务器A通过访问1.1.1.1:80 是无法正常访问服务器B的。原因是，hairpin会影响Tcp连接建立的握手过程。
1. A发送握手请求给入口路由器，路由器修改目的ip为192.68.0.2 ，发送到服务器B。
2.B收到握手请求后，回复握手确认应答给这个握手请求的源IP地址，此处是A的地址192.168.0.1
3.因为A，B同一网络，握手确认会直接到达A。
4.A发现这个握手确认回复的源ip（192.168.0.2）并不是我期望与之建立连接的握手请求目的地址（1.1.1.1），A并不认识B，只认识路由器，导致TCP连接无法建立。
解决以上问题的关键，就是让握手确认应当同样经过路由器，发送给A。因此，需要在之前将握手请求转发给B时，同时修改源ip地址为（1.1.1.1），如此，B服务器作出确认回复时，自然也会发送给1.1.1.1。
但是这个源地址转化（SNAT）的过程，实际上只对于来自内网的流量是有必要的。对于外网流量，其源IP本身就处于网络外部，必然会经过再次经过路由器返回。
于是联系管路由器的小明，请他不要偷懒，规则配置的细致一点，不要做无差别的源地址转换。即
1.对内网接口流量进行源地址和目标地址转换
2.对外网流量只进行目标地址转化。
重新测试。 终于输出实际了客户PC实际ip地址0.0.0.0
OK，一波三折，跌宕起伏，写到这里～
![[OI] 欢夏！邪龙？马拉车！](https://img2024.cnblogs.com/blog/3389876/202408/3389876-20240807174521455-1310234398.png)
![[Paper Reading] DEFORMABLE DETR: DEFORMABLE TRANSFORMERS FOR END-TO-END OBJECT DETECTION](https://img2024.cnblogs.com/blog/1067530/202408/1067530-20240807173005213-1961915705.png)
