LVS TUN隧道模式详解：原理、配置与跨机房负载均衡实战

企业级负载均衡集群LVS—TUN隧道模式

做运维这几年，我接触过的负载均衡方案不算少，从硬件F5到软件Nginx、HAProxy，再到LVS的DR模式和NAT模式，基本都用过一轮。但说实话，真正让我在面试和实际项目中都觉得"这玩意儿有点东西"的，还是LVS的TUN隧道模式。之前帮一个客户搭视频点播集群，业务流量大得吓人，NAT模式扛不住，DR模式又受限于物理网络拓扑，最后就是靠TUN隧道模式把跨机房的几十台后端服务器统一调度起来，效果立竿见影。

先说人话解释一下TUN隧道模式到底干了啥。LVS一共有三种工作模式：NAT、DR、TUN。NAT模式像公司前台，所有进出都得过它；DR模式像直接给员工发快递，回程不经过前台了；而TUN模式更像是给每个后端服务器发了一个"虚拟工作证"，请求进来时，负载均衡器把数据包重新封装一下，通过IP隧道直接丢给后端服务器，后端处理完直接把响应返回给客户端，连负载均衡器都不用绕。

这篇文章适合谁看？刚接触LVS想搞懂三种模式区别的运维新人，被DR模式跨VLAN问题卡住的老手，以及正在做大规模视频、下载、流媒体类业务架构选型的技术负责人。我会把TUN隧道模式的原理拆开揉碎，配上我实际搭建集群的完整过程、参数解释、踩坑记录，以及和DR/NAT模式的对比选型建议，争取让你看完就能照着落地。

1. 为什么偏偏是TUN模式：它解决的核心痛点

1.1 NAT和DR模式的先天局限性

先说NAT模式。LVS-NAT模式下，负载均衡器就是整个集群的流量中枢，客户端请求进来要改目的地址，响应出去要改源地址。看起来逻辑简单，但问题也很明显：进出流量都走这一台机器，带宽瓶颈迟早会卡死你。我见过一个生产环境，后端吞吐明明有4Gbps，前端NAT模式的均衡器跑到1.5Gbps就开始丢包，加带宽又得花钱升硬件，非常被动。

DR模式倒是解决了回程流量的问题，它通过改写数据帧的目标MAC地址，让请求直接送到后端的VIP上，后端服务器回包时源IP就是VIP，客户端直接收到，完全绕开了均衡器。听起来很完美，但是DR模式有一个硬性前提：负载均衡器和所有后端服务器必须处于同一个二层网络里，也就是同一台交换机或者做了二层互通。可现实中很多企业机房不止一个网段，或者后端服务器分布在两个数据中心，DR模式就彻底没戏了。

TUN模式的价值就在这里。它不依赖二层网络，核心思想是把客户端的请求包通过IP隧道重新封装，内层是原始数据包，外层新加了一个IP头，目的IP是后端服务器的真实IP。这样后端服务器不管在哪个网段、哪个机房，只要IP能通，就能接收隧道包并处理，处理完直接把响应返回给客户端。四两拨千斤，把跨网段、跨机房的大规模调度问题直接解决。

1.2 什么样的业务场景最需要TUN模式

从我的经验看，以下三类场景非常适合TUN模式：

• 大流量下载和视频点播类业务：响应数据量远大于请求数据量，回程流量绕过负载均衡器是刚需，TUN模式天然满足。
• 后端服务器跨网段、跨机房部署：公司有多个可用区，或者业务容灾需要把集群分散在不同物理位置，TUN是比DR更现实的选择。
• 后端服务器数量大、需要横向扩展：理论上只要网络可达，加机器就是改一下配置文件的事，不会受二层设备端口和MAC表容量限制。

当然TUN模式也不是没有成本，它要求后端服务器支持IP隧道协议，Linux内核里对应模块就是ipip，还需要额外配置tunl0隧道网卡。这些后面实操部分我会一步步拆。

1.3 一句话总结：TUN模式和DR、NAT的本质区别

用一张表格做对比，方便你选型时快速定位：

2. 隧道模式的前置知识：图解IPIP封包与VIP的必要性

2.1 IPIP隧道的封包与解包过程

TUN模式最核心的机制是IPIP隧道。所谓隧道，说白了就是在原本的IP数据包外面再套一层IP头。你想象一下寄快递：内层是你原本的信件（客户端发往VIP的请求包），外层是快递包装袋（从均衡器发往后端真实IP的隧道包头），后端收到后拆开外层包装，取出里面的信件，一看目的地址是VIP，就知道这请求是发给自己的。

具体封包结构是这样变化的：

• 原始客户端请求包：源IP=客户端IP，目的IP=VIP（比如192.168.10.100）。
• 均衡器收到后不修改这个包的任何内容，而是直接在外面封装一个新的IP头：源IP=均衡器IP，目的IP=后端服务器的真实IP，协议号设置为4（IPIP封装）。
• 后端服务器的tunl0隧道接口收到这个外层包，发现协议号是4且自己是目的地址，就自动解封装，把内层包交到协议栈继续处理。

这里有个关键认知误区：很多人以为TUN模式需要修改内层包的目的IP，其实完全不用，正是因为没有改动内层包，后端才必须把VIP配置到自己身上，否则内层包到了协议栈，发现目标不是本机IP，直接就给丢了。

2.2 为什么后端必须绑定VIP，以及为什么不会冲突

TUN模式下，每台后端服务器都要在自己的回环接口（通常叫lo:0）上绑定VIP。这是很多新手最不理解的地方：多台机器配置同一个IP，不会IP冲突吗？

答案是：不会，因为VIP的地址只在本地协议栈内部使用，而且必须配合内核参数rp_filter（反向路径过滤）和arp_ignore/arp_announce调整。TUN模式之所以对ARP要求没那么苛刻，是因为隧道包的外层目的IP是后端真实IP，ARP解析只发生在这个真实IP上，VIP不会被广播到网络里。你可以把VIP理解为"本地斗篷"，只有隧道解封装后才会看到它。

但为了稳妥，我依然会在每台后端机器上做两个事情：

• 在lo:0配置VIP，并设置net.ipv4.conf.all.arp_ignore=1和net.ipv4.conf.all.arp_announce=2，防止后端机器对VIP的ARP请求做出响应。
• 设置net.ipv4.conf.all.rp_filter=0，避免反向路径过滤把隧道包判定为非法路由而丢弃。

这两步我后面会给出完整的sysctl.conf写法，直接抄作业就行。

2.3 隧道模式下数据包进出完整路径

为了让你脑子里有一个清晰的链路图，我按时间线把整个流程走一遍：

1. 客户端发起请求，目标地址是VIP，例如10.0.0.100。
2. 路由器把请求送到负载均衡器（Director）的VIP网卡上。
3. Director查看自己的IPVS调度表，根据调度算法（rr、wrr等）选中一台后端服务器，真实IP假设是172.16.1.20。
4. Director在原包外层封装IPIP隧道头，新包的源IP是Director的IP（比如172.16.0.10），目的IP是172.16.1.20，协议号4。
5. 隧道包经过路由和交换机，到达后端服务器172.16.1.20。
6. 后端服务器的tunl0接口收到外层包，解封装，露出内层请求包（目的IP仍是10.0.0.100）。
7. 因为后端已经在lo:0上绑定了VIP 10.0.0.100，协议栈接受这个包，交给Web服务进程处理。
8. 后端处理完，响应包直接以VIP作为源IP发送给客户端，完全不经Director。

整个链路中，Director只在请求阶段出现一次，响应阶段完全隐身。这对大流量场景的意义，怎么强调都不过分。

3. 手把手搭建LVS-TUN集群：环境规划到完整配置

3.1 环境规划与网络拓扑

我在实际项目中用三台服务器搭建过最小可用的TUN集群，这里我用一套模拟环境来演示。所有IP都是规划出来的测试地址，你替换成自己的生产IP即可。

注意一个关键点：TUN模式下，均衡器和后端服务器不需要在同一网段，甚至可以跨互联网部署。我这里故意把后端放在172.16网段，就是为了演示"路由可达即可"的效果。

3.2 负载均衡器端配置

第一步安装IPVS管理工具。CentOS/RHEL系的命令是：

yum install -y ipvsadm

Debian/Ubuntu系则是：

apt install -y ipvsadm

接下来创建VIP。我的习惯是先用命令验证效果，确认没问题再写成开机自启脚本：

ip addr add 192.168.1.100/32 dev eth0

这里必须强调，VIP一定要配成32位掩码，也就是只匹配单个IP，不要让它参与路由广播。否则会出现一些奇怪的ARP问题。

然后打开IP转发功能：

echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf sysctl -p

TUN模式虽然不像NAT模式那样强依赖iptables转发，但打开转发仍然是一个保险动作。接下来配置IPVS规则：

ipvsadm -A -t 192.168.1.100:80 -s rr ipvsadm -a -t 192.168.1.100:80 -r 172.16.1.101 -i ipvsadm -a -t 192.168.1.100:80 -r 172.16.1.102 -i

这里关键参数是最后那个-i，它代表隧道模式（IPIP encapsulation）。如果没有这个参数，默认会是NAT模式，后端服务器就会因为找不到VIP而抓狂。-s rr代表轮询调度算法，生产环境一般用wrr加权轮询或者lc最少连接，看业务来。

验证规则是否生效：

ipvsadm -L -n

输出里你会看到两行后端服务器的记录，转发策略显示TUN，就算配置成功了一半。

3.3 后端服务器的隧道网卡配置

这是TUN模式最容易出错的地方。后端服务器需要加载IPIP内核模块，并创建tunl0隧道接口。

第一步，加载模块并确认：

modprobe ipip lsmod | grep ipip

如果你用的是较新的内核，可能会发现模块名变成了tunnel4或者被编译进内核，不用太纠结，只要能创建tunl0接口就行。

第二步，启动tunl0接口并添加VIP：

ip link set tunl0 up ip addr add 192.168.1.100/32 dev tunl0

这里我要多说一句：很多教程会让你把VIP加在lo:0上，这其实也没有大问题，因为协议栈只看目的IP是否属于本机。但我实测下来，加在tunl0上更直观，因为tunl0是隧道包的接收口，VIP配置在这里逻辑上更顺。两种做法都可行，你选一种保持一致就好。

如果想开机自动生效，写入配置文件：

cat > /etc/sysconfig/network-scripts/ifcfg-tunl0 << 'EOF' DEVICE=tunl0 BOOTPROTO=none ONBOOT=yes IPADDR=192.168.1.100 PREFIX=32 EOF

第三步，调整内核参数。这是后端正确接收隧道包的关键，我直接用完整配置：

cat > /etc/sysctl.d/99-lvs-tun.conf << 'EOF' net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.tunl0.rp_filter = 0 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.ip_forward = 1 EOF sysctl --system

逐一解释一下：

• rp_filter：反向路径过滤，它默认会检查收到的数据包源IP是否能在路由表里找到对应路径，隧道包解封装后，内层包的源IP是客户端IP，后端可能没有到客户端IP的路由，所以必须关掉过滤，否则直接丢包。
• arp_ignore和arp_announce：防止后端向网络宣告自己的VIP，避免和均衡器VIP冲突。

3.4 验证整条链路是否跑通

后端两台服务器都部署好Nginx并启动后，先在均衡器上做连通性测试：

ping -c 3 172.16.1.101 ping -c 3 172.16.1.102

接着在客户端（另一台机器）上连续访问VIP多次，观察是否轮询到不同后端：

curl http://192.168.1.100/

如果后端返回的内容不同，说明调度正常。我习惯在每台后端的Nginx首页写上机器名，便于确认：

echo "This is rs01" > /usr/share/nginx/html/index.html echo "This is rs02" > /usr/share/nginx/html/index.html

最后在均衡器上看连接统计：

ipvsadm -L -n --stats

如果ActiveConn在增长，且两个后端都有流量，恭喜你，TUN隧道集群已经跑通了。

4. 实测中的坑：隧道通了但响应丢包，问题竟在内核参数

4.1 第一次搭建时的完整排查过程

第一次搞TUN模式时，我按照教程一步步配完，结果客户端能ping通VIP，curl却总是超时，或者偶尔成功一次。当时真是被折磨得不轻，这里把排查过程完整写出来，价值比配置本身大得多。

我当时的处理顺序是这样的：

先看均衡器上IPVS统计，发现转发计数一直在涨，说明调度器确实把包发出去了。接着看后端Nginx访问日志，结果日志里一条记录都没有，这说明请求根本没到Nginx，问题出在内核协议栈。

然后我在后端服务器上用tcpdump抓包：

tcpdump -i tunl0 -n

结果发现tunl0接口上完全没有流量。这就奇怪了，隧道包到底去哪了？我立刻换成抓物理网卡：

tcpdump -i eth0 -n ip proto 4

这次有发现，eth0上确实收到了协议号4的包。说明隧道包到达了服务器，但没被转交给tunl0接口。问题就出在rp_filter上。系统默认的rp_filter是宽松模式（值为1），它会校验反路由，而我的后端路由表里并没有到客户端IP的明细路由，于是内核直接判定为非法包，悄悄丢弃。

找到原因后我立刻应用了前面那份sysctl配置，把rp_filter置0，再试curl，秒开。

这个坑我后来在其他项目里又见到有人踩过，大家平时用DR模式习惯了，完全想不到TUN模式会栽在反向路径过滤上，所以建议你在配置后端时第一时间就把rp_filter关掉，不要等出了问题再去抓包。

4.2 隧道MTU引发的分片问题

第二个坑跟MTU有关，出现频率也很高。IPIP隧道会在原包外面增加20字节的新IP头，这样一来，如果客户端发出的包本身已经是1500字节（以太网最大传输单元），封装后就变成1520字节，超出物理链路MTU，就会触发分片。

分片带来的恶果是：部分防火墙和中间设备会直接丢弃带分片标志的包，导致大型请求或下载业务正常，但一些交互请求时好时坏，非常诡异。

我的解决方案是在均衡器上适当调低对外通告的MSS值，让TCP握手时协商一个更小的段大小：

iptables -A POSTROUTING -t mangle -p tcp --dport 80 -j TCPMSS --set-mss 1400

也可以在后端服务器上直接降低隧道接口MTU：

ip link set tunl0 mtu 1400

两种方式结合使用效果最好。我建议你把tunl0的MTU稳定设置在1400，能有效避开发和分片相关的大部分问题，代价是每个包多一点点头部开销，但换取稳定性完全值得。

4.3 keepalived对TUN模式支持的一些细节

生产环境肯定不能让均衡器单点，所以要配合keepalived做VIP的HA。keepalived对LVS-NAT和DR模式支持得很好，TUN模式也一样支持，但有一个细节要留意。

keepalived的配置文件中，real_server那一行需要加上tun关键字，否则keepalived会用NAT模式去健康检查后端，健康检查就会失败。正确写法是：

virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo rr lb_kind TUN persistence_timeout 20 protocol TCP real_server 172.16.1.101 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } real_server 172.16.1.102 80 { weight 1 TCP_CHECK { connect_port 80 connect_timeout 3 } } }

注意lb_kind TUN，这个对应ipvsadm里的-i参数。keepalived把转发模式声明为TUN后，健康检查请求会走隧道机制，后端回包直接返回客户端，整个链路才是完整的。

我遇到过一个问题：配置好keepalived后，主备切换一切正常，但后端的健康检查总是超时。后来排查发现是keepalived所在主机的防火墙拦了出方向的TCP_CHECK包。解决方法是放行健康检查源IP，或者改用HTTP_GET方式并指定健康检查的URL。调整后一切正常。如果你后面也遇到健康检查不通过的诡异问题，可以先看看是不是防火墙的问题，而不是急着怀疑tunnel配置。

5. 调度算法选型与性能调优经验

5.1 常见调度算法适用场景分析

IPVS自带的调度算法有十几种，生产环境我常用的就三个：rr、wrr、lc。简单对比一下：

• rr（轮询）：请求均匀分配给所有后端，适合后端性能基本一致的场景，配置最简单。
• wrr（加权轮询）：给性能强的机器分配更大的权重，适合后端配置参差不齐的集群。
• lc（最少连接）：记录当前活跃连接数，把请求分给当前负载最小的后端，适合长连接业务，比如WebSocket、数据库中间层。

我自己的视频点播项目用的是wrr，因为后端机器新旧不一，新机器的CPU和网卡性能明显强很多，统一轮询反而让老机器成为瓶颈。wrr配合权重调整，新老机器都能发挥各自能力。

如果你在后端同时提供HTTP和HTTPS服务，记得把443端口的VIP规则也加上：

ipvsadm -A -t 192.168.1.100:443 -s wrr ipvsadm -a -t 192.168.1.100:443 -r 172.16.1.101 -i -w 3 ipvsadm -a -t 192.168.1.100:443 -r 172.16.1.102 -i -w 1

5.2 连接超时参数调整

IPVS默认有一些连接超时时间，比如TCP空闲超时默认900秒。对于长连接业务，这个值往往不够，客户端连接被服务端默默断开，业务数据丢失，表现就是"一会好一会坏"。

调整方法：

ipvsadm --set 120 60 600

参数含义分别是TCP空闲超时120秒、TCP FIN等待60秒、UDP空闲超时600秒。具体数值根据业务来调，不是固定死的。我的经验是：如果HTTP请求之间间隔不会太长，120秒空闲超时足够；如果是长轮询或流媒体播放，建议把这个值调大到600秒以上，避免播放中断。

如果你用keepalived管理IPVS规则，那超时参数需要在配置文件里通过ipvsadm-extra传递，否则重启keepalived后会恢复默认值。这个坑我也踩过，特别提醒一句。

5.3 后端真实服务器数量与收敛性

TUN模式理论上可以挂几十台甚至上百台后端，但实际项目里我建议你控制在一个合理范围，比如20到30台以内。原因不是性能不够，而是运维复杂度指数级上升。每台后端都要配置VIP、调整内核参数、维护健康检查，规模越大越容易在某台机器上遗漏配置。

有一个比较实用的做法是把后端的tunl0配置和内核参数做成一个统一的初始化脚本，新机器上线时自动执行，从根源上避免人为遗漏。

我用的脚本简化版大概是这样的：

#!/bin/bash VIP="192.168.1.100" MTU="1400" modprobe ipip ip link set tunl0 up ip addr add ${VIP}/32 dev tunl0 2>/dev/null || true ip link set tunl0 mtu ${MTU} || true cat > /etc/sysctl.d/99-lvs-tun.conf << 'EOF' net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 EOF sysctl --system

配合自动化工具分发执行，后端扩容从半小时缩减到一分钟以内。

6. 安全与高可用：生产架构需要额外考虑的事

6.1 rsync和防火墙配合，确保后端配置一致

后端服务器多了以后，配置文件漂移是个非常常见的问题。我们用配置管理工具或脚本把初始化内容统一推送到所有后端，再配合定时校验，确保每台机器的VIP、MTU、内核参数完全一致。

我的校验思路是：把VIP和tunl0状态写入一个文本文件，通过定时任务对比各机器的输出差异。不用写太复杂的逻辑，一个diff脚本就够了。出现差异时告警，人工介入处理，而不是放任它"看起来能用就行"。

6.2 后端服务器异常时IPVS的自动摘除

生产环境一定要配置健康检查。keepalived的TCP_CHECK可以检测端口是否存活，但有些场景下，端口活着不代表服务正常，比如处理线程全部阻塞、数据库连接池连不上等。这种情况下TCP_CHECK照样通过，但流量打过来就会502。

我的建议是配合HTTP_GET或外部监控来自定义更精细的健康检查。比如在后端放一个简单的健康检查URL，返回状态码200才算通过，如果接口响应超过3秒，keepalived会把它摘除，恢复后自动加回。这种机制在运维大流量集群时非常有用，能避免很多"后端半死"导致的上层故障。

6.3 VIP的HA与整体架构拓扑

生产环境中，均衡器建议至少两台，一主一备。VIP通过keepalived的VRRP协议在主机和备机之间漂移。注意，VIP的漂移本身不依赖TUN模式，它只是IP层面的高可用。切换后，新的主均衡器会接管IPVS规则，后端完全无感知。

TUN模式的高可用还有一个比DR模式舒服的地方：由于后端不需要和均衡器在同一二层网络，主备均衡器完全可以在不同的机房或网段，VIP通过VRRP跨三层宣告（配合单播VRRP），物理故障隔离能力更强。当然，跨机房的主备切换延迟会略高，但对中小规模的容灾场景已经很实用。

7. 三种模式混用与最终选型建议

7.1 能否三种模式混用

很多人问过一个问题：TUN模式和DR模式能不能在一个集群里混用？答案是：能，但不建议新手一开始就这么干。

IPVS本身支持每个后端real server单独指定转发模式，所以可以在同一个VIP下，把一部分后端配成DR、一部分配成TUN。这种混用场景通常出现在业务迁移期：部分机器在同一交换机下用DR，效率高；另一部分机器在远端机房只能用TUN。实际操作时，你只需要在ipvsadm命令中对不同后端分别使用-g（DR模式）和-i（TUN模式）即可。

但请务必记得，混用不同模式的机器不能有相同的VIP广播行为。DR模式后端和TUN模式后端对ARP的处理方式不一样，配置错了会互相干扰。我一般只在迁移窗口期临时混用，稳定后尽量统一到一种模式，降低运维脑负担。

7.2 按业务规模推荐选型路径

如果你是一个刚开始做负载均衡的团队，我建议按下面的路径思考：

• 后端机器在同一个交换机下，流量百万级QPS以内，优先考虑DR模式，因为它性能最好，配置相对简单。
• 后端跨网段、跨机房，或者需要快速横向扩展，直接上TUN模式。不要犹豫，这就是它的主场。
• 后端机器数量少且没有性能要求，可以考虑NAT模式，比如企业内部管理系统，几十个用户那种。

关于LVS和Nginx/HAProxy的对比，我多说一句：LVS工作在四层，性能极高，但不识别应用层内容；Nginx/HAProxy可以做到七层路由、灰度发布、路径转发。实际架构中，最合理的组合往往是LVS做入口流量调度，后端的Nginx集群做七层处理，各干各的。TUN模式作为LVS大流量入口的承载，价值就在这。

7.3 我自己的最终选择建议

就我目前遇到的多数场景而言，TUN模式确实不是最常用的，DR模式在日常运维中出场率更高。但如果你做的业务带有流媒体、大文件下载、跨地域容灾等特点，TUN模式几乎就是唯一选项。

有一点我想劝大家：不要因为TUN配置比DR多几个步骤就绕开它，多花半小时把IPIP隧道原理搞清楚，后面排查问题能省下好几个小时。我见过太多人等到线上流量打过来才临时抱佛脚，那时候踩坑的成本可就大了。

8. 写在最后：一点实操心得与扩展方向

从第一次配置TUN模式时被rp_filter狠狠教育，到后来能熟练规划跨机房的视频集群，我对这个模式最大的体会就是：LVS的三种模式没有绝对的优劣，只有适不适合当前网络拓扑。TUN模式牺牲了一定的封装CPU开销，换来了跨越二层的自由，这笔账在大规模分布式场景下非常划算。

最后分享一个小技巧：在排查TUN模式故障时，我习惯在均衡器上用ipvsadm -L -n --rate看每秒转发速率，在后端上用tcpdump -i tunl0 -n看隧道解包后的流量，两边一对比，问题出在发送端、网络中间还是后端接收，基本一目了然。这套组合拳帮我定位过好几次线上疑难杂症。

如果你正准备搭建LVS-TUN集群，建议先从最小三节点开始，跑通后再加节点、加调度算法、加高可用，一步一步来，千万别一上来就追求大规模。把隧道封包流程在脑子里跑通一遍，再动手配，你会发现整个集群就像一台精密的调度机器，每个包都按你设计好的路径走。