LVS-Ip Tunnel模式应用

一、什么是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配置】

  1. 使用ipvsadm配置
  ipvsadm -A -t vip:port -s rr
  ipvsadm -a -t vip:port -r rip -i 
  1. 使用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配置】

  1. 加载ipip模块。
modprobe ipip
  1. 启动tunl0虚拟网卡
ifconfig tunl0 up
  1. 将vip绑定在tunl0网卡上。(注意这里也是与DR模式不同的地方,DR模式是将vip绑在LO网卡)
ip addr add vip dev tunl0
  1. 设置内核参数
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上的抓包结果:


MSS=1400

 LVS上收到来自客户端的数据包分片中的data长度也变成了1400,这样LVS就可以正常插入封装层IP头进行转发了。
 下图可以看到插入封装头后,数据包里面有两层IP头。
两层IP头

 下图展示的就是LVS收到No. 1442的请求包,大小为1454字节;插入20字节的封装头后,数据包变为1474字节,然后转发给RS。


Ip Tunnel转发

推荐阅读更多精彩内容

  • 原文链接:刘小七の技术站 - Itlxq 个人主页:主页直达 - http://www.itlxq.com 公众号...
    jian_js阅读 491评论 0 0
  • 01 《倚天屠龙记》中,有两处描写让人拍案叫绝。 张无忌大婚,赵敏不带任何兵马,孤身前去抢亲。厅堂上是正派和明教熙...
    衷曲无闻阅读 15,751评论 90 300
  • 我刚从狼群里出来, 又进入另一个虎口, 狼群的残暴, 老虎的凶恶, 没有把我吓倒。 生活中的小小失误又算得了什么?...
    田小麦阅读 15评论 0 0