获取客户端真实IP

获取客户端真实IP

出于安全考虑，近期在处理一个记录用户真实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.168.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，一波三折，跌宕起伏，写到这里～