做过跨机房负载均衡的同行，应该都体会过那个经典的两难：后端业务服务器和调度器不在同一个二层网络，NAT模式回程流量全压在一个节点上，业务量一大就顶不住；DR模式倒是性能好，可它要求调度器和真实服务器必须在同一个物理网段，跨地域部署根本玩不转。我这里的答案是LVS TUN模式，用IP隧道把请求封装后再转发，既绕开了二层限制，又保留了“响应不回流”的高吞吐优势。这篇文章不整虚的，直接把原理拆开讲，再附上一套能照抄的部署记录和排障心得，适合正在评估负载均衡方案、或者已经在TUN模式下踩坑的运维和架构师。
1. TUN模式的核心原理：隧道如何把请求“快递”到后端
1.1 一次请求的完整旅程
先看一条请求在TUN模式下是怎么走的。客户端发了一个访问VIP的TCP SYN包，先到达调度器。调度器收到这个包之后，并不是像NAT模式那样改写目标地址转发出去，也不像DR模式那样直接改MAC地址，而是把这个完整的IP报文当成载荷，在外面再套一层新的IP头。这个新IP头的源地址是调度器的地址，目的地址是后端真实服务器（简称RS）的地址，协议号是4（IPIP封装）。然后这个“大包”通过物理网络被发到RS。
RS收到这个外层包后，内核里的IPIP隧道模块会自动把外层头剥掉，还原出最开始那个目的IP为VIP的原始报文，交给上层协议栈处理。业务进程看到的就是一个本地VIP的请求，正常处理完后直接以VIP作为源地址回包给客户端。关键在于，回包压根不再经过调度器，而是走RS自己的物理出口直连客户端。整个过程里，调度器只负责“收件和转寄”，RS负责“拆封和处理后回复”。
看到这里你应该明白了，这个模式的核心就是把网络请求的门牌号换成了“隧道地址”：调度器不需要知道业务细节，只需要把信封投递到正确的外层地址；RS解封后看到的内层VIP还是自己的，处理逻辑和本机收包没有任何区别。
1.2 为什么要封装：网络栈视角的解读
DR模式之所以不能在跨网段用，是因为它靠改写MAC地址来实现负载均衡，而MAC地址只在同一个广播域内有效，跨了路由器，二层信息就被丢弃了。TUN模式把这个问题彻底绕开：我不管你是哪个网段，只要我的外层IP包能通过路由到达你，隧道就能工作。
从内核网络栈看，IPIP隧道其实是把一套完整的IPv4报文塞进了另一个IPv4报文的“payload”区域。收包一侧的协议栈在识别到协议号为4时，会创建一个虚拟的隧道接口（通常是tunl0），然后把这个包交给tunl0去解封装。对上层应用来说，这些步骤是透明的。
这里有个不少人容易忽略的点：隧道封装后，整包长度会比原始报文多20字节（如果只套一层IPv4）。如果物理链路的MTU是1500，那么隧道内的原始报文最大只能到1480，否则就必须分片。这个特性在后面排查“大包不通、小包通”时会非常关键，先记住这个二十字节。
1.3 流量不对称：TUN模式最大的架构特点
TUN模式最值得关注的是它的“流量不对称”架构：请求流量只经过调度器，响应流量直接从RS返回给客户端。这样做的好处非常明显，调度器的带宽瓶颈被完全打破了。比如一个视频下载业务，请求可能只有几十字节，响应却是几兆，NAT模式下所有下行流量都要从调度器走一遍，调度器很快会变成瓶颈；TUN模式里调度器只需要承担海量小请求的转发，压力极小。
但这也带来了一个隐性要求：RS必须能直接和客户端通信。换句话说，RS需要拥有一个客户端可达的地址，并且回包时不能依赖调度器代为转发。跨机房部署时，这通常意味着RS本身要具备公网出口能力，或者通过自己的路由把回包发出去。很多人在测试环境里发现TUN模式“不好用”，往往就是RS没有合适的回程路由，回包丢了或者从错误的网卡发出去了。
2. 三种LVS模式对比：TUN到底赢在哪、输在哪
2.1 三种模式的典型拓扑
LVS的三种IP负载均衡模式，本质区别在于“调度器介入到哪一层”。
NAT模式是三层改写：调度器把请求的目标IP从VIP改成某个RS的内网IP，同时把源IP改成自己的内网IP，回包再从调度器改回去。这个模式下调度器必须位于客户端和RS之间，并且承担全部流量，带宽压力最大。优点是RS可以躲在私网里，不需要暴露任何公网地址。
DR模式是二层改写：调度器把请求包的目的MAC地址改成RS的MAC地址，网络里靠ARP广播让调度器和RS都响应VIP。这个模式改的是二层，所以性能极好，调度器只转请求不转响应。代价是调度器和RS必须处于同一广播域，而且RS的VIP不能对外回复ARP（否则就抢了调度器的活）。
TUN模式是三层隧道：调度器对原报文做IPIP封装后直接发给RS，依靠隧道的不受限特性，RS可以分布在任意可路由的网段。请求经过调度器，响应直连客户端。代价是每个包都要多一层IP头，封装解封装会吃一点CPU。
2.2 一张表看懂差异
我把几个核心维度放在一张表里，方便你对照选型。
| 对比维度 | NAT模式 | DR模式 | TUN模式 |
|---|---|---|---|
| 请求处理方式 | 改目标IP和源IP | 改目标MAC | IPIP封装 |
| 响应路径 | 必须经过调度器 | RS直连客户端 | RS直连客户端 |
| 二层依赖 | 无，靠路由 | 必须同一广播域 | 无，靠路由 |
| RS操作系统要求 | 任意支持IPVS的系统 | 需抑制ARP | 需支持IPIP隧道 |
| 调度器压力 | 最高，全量流量 | 低，仅请求 | 较低，请求+封装开销 |
| 额外开销 | NAT改写，开销极小 | 无额外包开销 | 每包多20字节 |
| 典型场景 | 小规模、RS无公网 | 同机房高性能 | 跨机房/混合云 |
单看这张表，TUN似乎是大而全的方案：能跨网段、响应又不回流，为什么不普遍采用呢？因为隧道封装带来的额外开销和系统复杂度是实际存在的。每个包多二十字节，对高PPS场景来说是实打实的带宽损耗，CPU还要承担封装解封装的运算。同机房、纯内网、性能优先的场合，我仍然会首选DR。
2.3 TUN最匹配的部署场景
根据我自己和同行交流的经验，TUN模式最适用的场景有几个。
一个是跨地域机房容灾。比如核心机房在上海，灾备机房在杭州，两边做服务发现，流量在本地网关层按权重分配。由于两个机房不在同一二层，DR没法做，NAT又会把调度器压垮，TUN就是为该场景设计的。
另一个是混合云场景。自建机房和公有云VPC里的实例组同一个负载均衡集群，公有云那边往往没法和你共享二层广播域，但只要网络能互通，TUN的隧道就可以工作。这时RS分布在云上和本地，调度器在本地，两边通过专线或公网隧道互通。
还有一个容易忽略的场景是“RS端口复用省公网IP”。调度器把到VIP的流量封装投递给RS的公网地址，RS和RS之间甚至可以跑在不同运营商网络中，只要有路由就行，这比DR在地址规划上灵活很多。
3. LVS TUN集群搭建全流程实录
3.1 集群规划与内核模块检查
建议你先规划一个最小集群：一台调度器（Director）、两台RS，系统都选同一主版本Linux内核（标准发行版内核即可，不需要特殊编译）。VIP假设为192.0.2.100，调度器内网地址192.0.2.10，RS1的地址192.0.2.11，RS2的地址192.0.2.12，为了方便先都放在同一网段，后面验证跨网段再把RS放到别的子网也不影响。
在动手前，先检查调度器和RS上是否加载了IPIP隧道模块。
modprobe ipip lsmod | grep ipip如果lsmod里能查到ipip，说明内核支持。再看一下系统里有没有生成tunl0接口：
ip link show tunl0早期内核可能需要手动加载模块，现代发行版一般会自动加载。如果你看到“Operation not permitted”之类的错误，先确认是否在容器环境里，容器缺权限会加载失败，TUN模式建议在物理机或具备完整内核权限的虚拟机里做。
3.2 调度器端配置
调度器上需要做的事情比较简洁：先让内核允许IP转发，然后安装ipvsadm管理工具，再配置虚拟服务和RS列表。
IP转发用sysctl打开：
sysctl -w net.ipv4.ip_forward=1 echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.confLVS规则的配置，注意RS的转发方式要指定为隧道模式（-i参数）：
ipvsadm -A -t 192.0.2.100:80 -s rr ipvsadm -a -t 192.0.2.100:80 -r 192.0.2.11:80 -i ipvsadm -a -t 192.0.2.100:80 -r 192.0.2.12:80 -i ipvsadm -L -n解释一下这三条的含义：第一条创建一个TCP 80端口的虚拟服务，调度算法是轮询；后两条添加两个真实服务器，-i是tunnel模式的标识；最后一条查看当前规则。如果输出里weight显示为1，转发模式显示TUN，说明配置成功。
调度器上还需要确认一条关键的路由：调度器能通过内网路由把封装后的外层包送到RS的地址。如果需要走特定网关，建议补一条静态路由：
ip route add 192.0.2.0/24 via 192.0.2.1 dev eth0这里有一个常被忽略的细节：调度器本身不需要在tunl0上配置VIP，因为调度器只是做一个“封装再投递”的中间动作，不像DR模式需要一个接口替VIP广播。理解了这一点，就不容易搞混。
3.3 真实服务器端的关键配置
RS上的配置是整个TUN模式里最容易出问题的地方，但逻辑其实也清晰：让系统有一个tunl0隧道接口，把VIP配上这个接口，再保证回包从tunl0走、源地址取VIP。
先看一遍在RS上推荐执行的完整步骤：
modprobe ipip ip link set tunl0 up ip addr add 192.0.2.100/32 dev tunl0 cat >> /etc/sysctl.conf <<'EOF' net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.tunl0.arp_ignore = 1 net.ipv4.conf.tunl0.arp_announce = 2 EOF sysctl -p ip route add 192.0.2.100/32 dev tunl0第一组命令是加载隧道模块、启动tunl0、把VIP配置成tunl0上的主机地址。第二组sysctl参数的意思是：本机在收到对VIP的ARP请求时不要响应（arp_ignore=1），向外发ARP通告时尽量用网卡主IP而不是VIP（arp_announce=2）。如果你在公网上的RS不希望自己暴露VIP的ARP响应，这两个参数是必须的，否则VIP会被局域网里的其他设备当成普通主机来通信，造成混乱。
最后那条路由尤其关键：它把目标为VIP的流量都引导进tunl0接口。为什么要这样？因为业务进程回包时，源地址是VIP，目的地址是客户端。系统查询路由表，发现VIP在tunl0上，回包就从tunl0发出，且源地址会被内核依据“本地地址优先”原则选取为VIP。如果没有这条路由，回包可能会从物理网卡发出，源地址被改成RS的物理地址，客户端就会因为源地址不对而丢弃连接。
如果你的RS有多块网卡，我建议把tunl0上的arp配置再细化到每个物理接口，但用all通配符覆盖全部接口是最省心的做法，实测不会有什么副作用。
3.4 启动服务与业务验证
RS上的Web服务监听在80端口即可回归正常。这里要强调的是，业务进程必须监听VIP地址或所有地址，不能只监听RS的物理IP，否则解封装出来的报文送到本地协议栈后，没人接收，连接自然建立不起来。
启动好服务后，在客户端用curl访问VIP验证：
curl -I http://192.0.2.100/如果能正常返回HTTP头，说明调度器已经成功把请求轮询到了某一台RS，并且回包也成功到达了客户端。想看具体是哪个RS处理的，可以在RS的Web日志里查访问来源IP：来源会是客户端的IP，而不是调度器的IP，这是TUN模式区别于NAT模式的标志之一。
想要更精确地确认流量细节，建议在调度器和RS上分别抓包。调度器上应该能看到一个外层目的地址为RS、协议号为4的封装包；RS上应该能看到先出现一个外层包、随后出现一个内层目的为VIP的包。抓包命令参考：
# 调度器上，过滤到RS地址的流量 tcpdump -nni eth0 host 192.0.2.11 -c 100 # RS上，观察隧道接口进出的流量 tcpdump -nni tunl0 host 192.0.2.100 -c 100看到内外两层IP结构，就说明封装链路是通的。
4. 高频故障与调优方法：这些坑我替你们踩过了
4.1 回包源地址不对导致连接建立失败
这是TUN模式最容易翻车的问题，症状表现为：客户端访问VIP时TCP握手超时，但抓包发现调度器和RS都有数据流动。
我排障时遇到过类似情况，当时在RS上抓包发现，入站方向能看到封装好的请求，业务也正常响应了，但出站包是从RS的物理网卡出去的，源IP写的是RS的物理地址，而不是VIP。客户端收到这种包，发现源地址和自己请求的VIP不一致，直接丢掉，于是表现为“请求到了后端但客户端永远连不上”。
造成这个问题的原因也很直接：要么VIP没配在tunl0上，要么缺少指向tunl0的VIP路由，导致系统认为VIP不属于本机，回包时自然用不上它。修复方法就是严格按上面3.3节的顺序把VIP和路由配好，测试中配完后问题就消失了。
4.2 反向路径过滤把业务包丢了
内核默认的rp_filter（反向路径过滤）在我测试跨网段RS时给我上了一课：RS在物理网卡收到了封装包，解封后内层报文被交给tunl0，按常规理解这个包应该直接进入协议栈，但如果RS开启了strict模式的反向路径过滤，内核会检查这个内层包的源地址是否可达，发现源IP（也就是调度器的内网IP）不应该从tunl0方向进来（因为通往调度器的路由实际走的是物理网卡），就会把它当成“非法伪造包”丢掉。
排查方法很简单，先看当前值：
sysctl net.ipv4.conf.all.rp_filter sysctl net.ipv4.conf.eth0.rp_filter如果显示1（strict），建议改成0或2（loose）。改成0表示关闭检查，改成2表示只要源地址从任意接口可达就放行。在跨网段场景，建议直接改成0，避免逻辑上顾此失彼：
sysctl -w net.ipv4.conf.all.rp_filter=0 echo "net.ipv4.conf.all.rp_filter = 0" >> /etc/sysctl.conf改完后立刻生效，不需要重启网络栈。这个改动同时要写到所有相关物理接口的配置里，我图省事直接用了all。
4.3 MTU导致的“大包不通小包通”
前面提到隧道封装多20字节，这个特性在公网链路里会放大成明显的故障：小包（比如HTTP头）能通，大包（比如大文件下载）卡住。原因是客户端发出的请求或响应包如果恰好达到物理网卡的MTU大小，封装后变成1520字节，超出了标准MTU 1500，路由器就会丢弃或要求分片。
解决思路有两个。第一个是降低隧道链路的最大报文长度，把调度器和RS的物理接口MTU下调到1480，给隧道留出20字节的空间：
ip link set eth0 mtu 1480第二个思路是配合PMTUD（路径MTU发现），依赖ICMP告知发送方减小报文长度。但公网环境里ICMP经常被运营商丢弃，所以最稳妥的做法还是直接调MTU。我在跨机房场景用的都是1480，实测大包传输稳定。
4.4 与keepalived集成时的注意事项
生产环境中，调度器通常用keepalived做高可用，检测后端健康状态。TUN模式配合keepalived并没有额外的特殊性，但有一个点需要提醒：keepalived的real_server健康检查默认走的是TCP探测或HTTP探测，而探测源地址是调度器的物理IP，走到RS的物理IP。这个探测不涉及隧道的VIP转发，因此只要RS的业务端口对调度器可达即可，不需要让RS对探测IP也配置VIP。
不过keepalived里绑定RS的方式要和ipvsadm保持一致，传输方式要设置成TUN，否则keepalived会按默认的Gateway模式（DR）去生成规则，导致流量路径和预期不符。具体配置片段大致如下：
virtual_server 192.0.2.100 80 { delay_loop 5 lb_algo rr lb_kind TUN protocol TCP real_server 192.0.2.11 80 { TCP_CHECK { connect_timeout 3 } } real_server 192.0.2.12 80 { TCP_CHECK { connect_timeout 3 } } }lb_kind写TUN就能保证keepalived生成规则时采用tunnel模式。
4.5 问题排查速查表
总结一下我在TUN模式排障过程中最常用到的检查顺序，按从外到内的思路罗列成表，遇到问题时可以一行行对照验证。
| 现象 | 优先级 | 检查点 | 处理方式 |
|---|---|---|---|
| VIP完全不通 | 1 | 调度器规则 | ipvsadm -L -n确认转发模式为TUN |
| VIP完全不通 | 2 | 隧道模块 | 调度器与RS均确认ipip已加载 |
| 握手超时但后端有响应 | 1 | 回包源地址 | 确认VIP已配在tunl0上，且有指向tunl0的路由 |
| 握手超时且后端无响应 | 1 | rp_filter | RS上关闭反向路径过滤 |
| 大包不通小包通 | 1 | MTU | 网卡MTU调整为1480或更小 |
| 调度器无转发 | 1 | ip_forward | 确认net.ipv4.ip_forward=1 |
| VIP只能被部分网段访问 | 2 | RS回程网关 | 确认RS有到客户端的路由，且优先走tunl0所在路由表 |
这张表不能包治百病，但能帮你把80%的“TUN模式不通”问题收敛到三四个根因里，剩下的通常就是防火墙策略或者安全组设置，按流量路径逐段放行即可。
最后再分享一个我自己的实操习惯：凡是涉及隧道的集群，我都会在RS上写一个初始化脚本，把tunl0、VIP、路由、rp_filter、MTU所有配置一次性固化下来。这样新扩一台RS时，跑一遍脚本就能加入集群，不用靠备忘录一条条敲。这个习惯帮我避免过好几次“上线前漏配路由”的低级事故，建议你也照着做一个，比任何文档都好用。
