在 LVS 的三种典型工作模式中，NAT 模式因为所有进出流量都要经过 Director，容易成为带宽瓶颈；DR 模式虽然性能出色，但要求真实服务器与调度器位于同一个二层网络。当真实服务器分布在不同的机房或网段时，TUN 模式就成了折中且高效的选择。它借助 IP 隧道封装技术，让 Director 只需把请求报文封装后转发给后端服务器，响应流量由真实服务器直接返回客户端，既绕开了 NAT 的带宽压力，又突破了 DR 模式的同网段限制。
TUN 模式的工作原理与报文封装流程
TUN 模式的核心是 IP 隧道（IP Tunneling）技术。Director 在收到客户端发来的请求报文后，不会修改原始报文的内容，而是在原有 IP 报文外面再封装一层新的 IP 头。外层 IP 头的源地址是 Director 的 IP，目标地址是选中的某台真实服务器 RIP。真实服务器收到这个封装报文后，内核会解开封装，取出内层原始报文交给上层应用处理。
这个设计的关键在于：内层报文的目标地址仍然是集群的 VIP。因此真实服务器必须在本地配置一个 tunl0 隧道接口并绑定 VIP，这样内核在解包后才会认为这个报文是发给自己的。处理完成后，响应报文直接以 VIP 为源地址、客户端 IP 为目标地址发出，完全不经过 Director，这就是所谓的异步转发或半连接模式。
与 DR 模式相比，TUN 模式不再依赖修改 MAC 地址实现转发，所以真实服务器不需要和 Director 在同一个物理网络中，只要彼此之间 IP 可达即可。这带来了跨机房部署的可能性，但代价是每个报文都要增加 20 字节左右的外层 IP 头开销，且所有真实服务器必须支持 IP 隧道协议（Linux 内核默认支持 ipip 模块）。
环境准备与 Director 端配置
假设我们搭建一个小型测试集群：Director 的 IP 为 192.168.10.10，VIP 为 192.168.10.100，两台真实服务器 RIP 分别为 192.168.20.21 和 192.168.20.22。开始配置前，先在 Director 上确认 ipvs 模块已加载，并安装 ipvsadm 管理工具。
# 检查内核是否支持 IPVS grep -i ipvs /boot/config-$(uname -r) # 安装管理工具（CentOS/RHEL） yum install -y ipvsadm # 加载 ipip 隧道模块 modprobe ipip lsmod | grep ipip
确认模块就绪后，先在 Director 上绑定 VIP。TUN 模式下 Director 不需要配置 tunl0 接口，VIP 可以直接配置在物理网卡上，也可以配置在回环接口上，这里以网卡绑定为例：
# 在物理网卡上添加 VIP ip addr add 192.168.10.100/32 dev eth0 # 开启转发功能 echo 1 > /proc/sys/net/ipv4/ip_forward
接下来使用 ipvsadm 创建集群服务并添加真实服务器。注意 TUN 模式对应的转发标记是 -i（ipip 隧道），这是与 DR 模式 -g、NAT 模式 -m 最重要的区别：
# 创建虚拟服务，使用轮询调度算法 ipvsadm -A -t 192.168.10.100:80 -s rr # 添加真实服务器，-i 表示 TUN 模式 ipvsadm -a -t 192.168.10.100:80 -r 192.168.20.21:80 -i ipvsadm -a -t 192.168.10.100:80 -r 192.168.20.22:80 -i # 查看规则 ipvsadm -Ln
如果希望规则重启后依然生效，可以执行 ipvsadm -Sn > /etc/sysconfig/ipvsadm 保存配置，并通过 systemctl enable ipvsadm 设置开机加载。
RealServer 端配置与 ARP 抑制
真实服务器端的配置是 TUN 模式搭建中最容易出错的环节。每台真实服务器都需要创建 tunl0 隧道接口，把 VIP 绑定上去，并正确设置 ARP 抑制参数。如果不做 ARP 抑制，VIP 会通过 ARP 广播暴露出去，可能与 Director 发生地址冲突，导致流量被错误引到真实服务器。
# 创建并激活 tunl0 接口 modprobe ipip ip link set tunl0 up # 在 tunl0 上绑定 VIP ip addr add 192.168.10.100/32 dev tunl0 # ARP 抑制：不响应、不通告 VIP 的 ARP 请求 echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
这里有两个参数需要理解清楚。arp_ignore 设为 1 表示只有目标 IP 正好配置在本机接收报文的网卡上时才回应 ARP 请求；arp_announce 设为 2 表示本机在对外发起通信时，只使用网卡上真实配置的地址作为源，避免把 VIP 通告出去。两者配合，才能保证 VIP 只由 Director 对外应答。
另一个常见问题是报文校验失败。由于隧道封装后报文的源地址会被做反向路径校验，建议同时在所有真实服务器上关闭 rp_filter 严格校验，否则内核可能把来自 Director 的封装报文直接丢弃：
echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
配置完成后可以在真实服务器上通过 tcpdump -i tunl0 -nn 观察是否收到封装报文，验证隧道是否畅通。
常见故障排查与模式选型建议
搭建完成后如果访问失败，可以按以下顺序排查。第一步在 Director 上执行 ipvsadm -Lnc 查看连接状态，如果大量连接停留在 SYN 状态，说明请求已经转发出去但响应没有回来，问题大概率出在真实服务器端：要么 tunl0 没绑定 VIP，要么 rp_filter 把报文丢了。第二步检查防火墙规则，确保 Director 与真实服务器之间的 IP Protocol 4（IP-in-IP）流量没有被 iptables 或 firewalld 拦截。第三步确认真实服务器上的后端服务确实监听在 VIP 的端口上，必要时用 curl 127.0.0.1 先验证本地服务正常。
从架构选型角度，三种模式各有适用场景：NAT 模式配置最简单，真实服务器无需任何特殊设置，适合小型内网环境；DR 模式性能最好，没有隧道开销，但要求所有节点同处一个二层广播域；TUN 模式则在性能与灵活性之间取得平衡，特别适合真实服务器跨网段、跨机房部署的场景，比如异地多活架构中把流量分发到不同机房的 Web 集群。
需要注意的是，TUN 模式下真实服务器的操作系统必须支持 IP 隧道协议，Windows 服务器默认无法直接作为 TUN 模式的后端节点。此外，如果中间网络存在安全设备对 IP-in-IP 协议做了限制，隧道流量也可能被丢弃，此时需要在网络层面放行 Protocol 4，或者考虑改用 FULLNAT 等其他方案。掌握这些细节后，TUN 模式完全可以成为跨机房负载均衡的可靠基础。