获取客户端真实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.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，一波三折，跌宕起伏，写到这里～