一、什么是Ip Tunnel模式

Ip Tunnel，又叫IP隧道，顾名思义，LVS通过在IP数据包外面再封装了一层Ip Tunnel 头部，将数据包的源地址改写为LVS自身的物理地址，目的地址改写为RS的物理地址，从而实现跨网段访问RS。整个过程看起来好像LVS和RS之间有一条隧道，数据包通过这条虚拟的隧道进行传输。
如下图所示：

Ip Tunnel封装

Ip Tunnel模式下，客户端的请求包到达负载均衡器的虚拟服务IP端口后，负载均衡器不会改写请求包的IP和端口，但是会在数据包IP层外面再封装一个IP层，然后将数据包转发；真实服务器收到请求后，会先将外面封装的Ip Tunnel头去掉，然后处理里面实际的请求报文；与DR模式类似，响应包也不再经过LVS，而是直接返回给客户端。所以Ip Tunnel模式的转发效率虽然弱于DR，但是强于NAT。

二、为什么要用Ip Tunnel模式

既然Ip Tunnel模式的性能比不上DR，那为什么还要用它呢？因为它可以跨网段转发！
Ip Tunnel模式最大的优点就在于它可以跨网段转发，没有DR和NAT模式的组网限制。这在部署上带来的很大的灵活性，甚至还可以跨机房转发，不过不建议这样使用，一是会带来跨机房间的流量，提高了成本；二是跨机房转发必然会要在RS机房上绑定LVS机房的VIP，这有可能会被运营商的防火墙认为是IP伪造请求而拦截。

三、如何配置Ip Tunnel模式

【LVS配置】

使用ipvsadm配置

  ipvsadm -A -t vip:port -s rr
  ipvsadm -a -t vip:port -r rip -i

使用Keepalived配置
推荐使用Keepalived管理LVS。Keepalived提供配置文件keepalived.conf，可以很方便的配置LVS，并且提供了健康检查功能。

virtual_server vip port {
    delay_loop 6
    lb_algo rr
    lb_kind TUN          //与DR模式唯一的区别就是这里配置为TUN
#    persistence_timeout 50
    protocol TCP

    real_server rip port {
        weight 100
        TCP_CHECK {
            connect_timeout 3
            retry 3
            delay_before_retry 3
        }
    }
}

注意这里只写了与DR模式配置不一样的地方，lvs上配置vip之类的就没写了。

【RS配置】

加载ipip模块。

modprobe ipip

启动tunl0虚拟网卡

ifconfig tunl0 up

将vip绑定在tunl0网卡上。（注意这里也是与DR模式不同的地方，DR模式是将vip绑在LO网卡）

ip addr add vip dev tunl0

设置内核参数

echo "0" > /proc/sys/net/ipv4/ip_forward
echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "0" > /proc/sys/net/ipv4/conf/tunl0/rp_filter

注意Ip Tunnel模式下需要将RS上的rp_filter参数配为0，否则无法正常工作，因为RS是在物理网卡收到请求，但是VIP是绑在虚拟网卡tunl0上的。

四、Ip Tunnel模式需要注意的地方

【Ip Tunnel模式存在的问题】

Ip Tunnel模式下，LVS会在数据报文原有的IP头部上再封装一层IP头，封装层IP头的源IP是LVS节点的物理IP，目的IP是RS的物理IP，相当于原有的数据报文是在一层封装的隧道中传输。
这样可以解决跨网段转发的问题，但是会带来一个新的问题：
每个数据包都要封装一个新的20字节的IP头，如果LVS上收到的数据包就已经达到了Ethernet帧的最大值1514（MTU1500+帧头14），这时候封装层的IP头就无法加进去。如果数据报文IP头中设置了DF标志位（Don't Fragment），这时候LVS就无法正常转发该报文。而是会返回一个Type=3，Code=4的ICMP报文给客户端，通知客户端目的地不可达，需要分片，并且在通知报文中指定了本端的MTU为1480。如果客户端支持PMTUD协议，那么客户端会根据ICMP中通知的MTU值重新计算合适的MSS，对要发送的数据进行分片后再重传给LVS节点。
下图是TUN模式下LVS上的抓包，可以看到一开始LVS收到的数据包的data长度为1460，加上20字节TCP头，加上20字节IP头，已经达到MTU1500了（抓包大小为1514是算上了14字节的Ethernet帧头）。

数据长度为1460

这时候LVS无法转发，通过ICMP报文通知客户端分片后重传。

ICMP通知重传

告知本端MTU为1480

下图可以看到重传后的数据报文中data长度变成了1440，剩余的data位于另外的分片中。1440加上20字节TCP头，加上20字节IP头刚好等于ICMP报文中通知的MTU值1480。此时LVS在1480的基础上再插入20字节的封装层的IP头，刚好等于物理网卡的MTU值1500。这时候IP TUNNEL模式就可以正常转发了。

数据长度为1440

出现这个问题的原因在于IP TUNNEL模式下，LVS需要在源数据报文中再插入20字节的封装层IP头，所以它将自身的MTU值降到了1480。这个情况下，LVS对每个大包（超过1480）的包都通过ICMP消息通知客户端分片。这依赖于客户端支持PMTUD，并且还依赖于ICMP通知能正常返回到客户端。因为在实际情况下，ICMP消息在返回客户端的过程中需要经过多跳公网路由，在中间很可能会被拦截过滤掉，这时客户端无法收到LVS返回的ICMP通知，就无法正常的分片重传了，导致LVS转发失败。

【解决方法】

可以通过减少RS侧的MSS值，比如调到1400。这样客户端在和RS三次握手协商MSS的时候，就会使用修改后的MSS值。这样客户端网卡在对数据包进行分片时就会减小单个请求中的data大小，确保LVS上收到的请求大小不会超过1480，从而不会触发到上述的问题。
iptables配置方法如下，实际情况中可以根据需求指定规则所要匹配的ip地址，这样可以减小配置修改的影响范围。

iptables -A OUTPUT -s xxx -p tcp --tcp-flags ALL SYN,ACK -j TCPMSS --set-mss 1400

下面是修改后的客户端上的抓包结果：

MSS修改为1400

从上图可以看到客户端在三次握手过程中收到的RS沟通的MSS值为修改后的值1400。
（注意wireshark中之所以能抓到超过1514字节的包，是因为目前大部分机器上都是开启了TSO/GSO的，TCP分片的工作下放给了网卡驱动去做；而wireshark抓到的是网卡缓冲区中的数据，还没有进行分片，所以有可能会看到大于1514的包；但是在真正发送出去的时候网卡驱动会根据MSS对TCP报文进行分片；可以对比服务端收到的抓包，服务端上收到的包就不会超过1514字节了）
下面是LVS上的抓包结果：