LVS（Linux Virtual Server）是章文嵩博士开发的四层负载均衡方案，在内核层面实现流量分发，性能远超Nginx、HAProxy等应用层软件。LVS一共有三种工作模式：NAT、DR和Tunnel。其中Tunnel模式（IP隧道模式）通过IP-IP封装技术转发报文，既保留了DR模式的高性能，又支持后端服务器跨网段部署，是很多跨机房集群的首选方案。本文将以CentOS为例，从原理到实操，完整演示Tunnel模式的搭建过程。
一、Tunnel模式的工作原理
Tunnel模式的核心是IP隧道技术。Director收到客户端请求后，不修改报文内容，而是在原有IP报文外面再封装一层新的IP头，新IP头的目的地址指向某台RealServer，然后通过网络发送出去。这个过程类似于把一封信装进另一个信封再寄出去，原始信件（客户端请求报文）的内容和地址标签都保持不变。
RealServer收到这个经过封装的报文后，内核会解开外层IP头，发现内部报文的目的IP是VIP，而VIP恰好配置在自己的tunl0虚拟网卡上，于是正常接收并处理这个请求。处理完成后，RealServer直接以自己的IP作为源地址把响应发回客户端，响应流量完全不经过Director。这种“请求走隧道、响应直达客户端”的机制，让Director只承受入站流量压力，出站流量由后端分担，因此整体吞吐量非常高。
与DR模式相比，Tunnel模式最大的优势在于网络拓扑灵活性。DR模式要求Director和RealServer必须在同一个物理网段（通过MAC地址转发），而Tunnel模式走的是IP层封装，只要Director和RealServer之间IP路由可达，哪怕服务器分布在不同机房、不同城市，都能正常工作。代价是每个报文要多加一层IP头（20字节），会稍微增加带宽开销和CPU处理负担。
二、实验环境准备与Director配置
先准备三台CentOS机器：一台Director（IP为192.168.10.10）、两台RealServer（IP为192.168.10.21和192.168.10.22），VIP统一设定为192.168.10.100。三台机器都关闭防火墙和SELinux，避免实验过程中被安全策略干扰。
在Director上安装ipvsadm工具，并加载ip_ip模块：
systemctl stop firewalld setenforce 0 yum install -y ipvsadm modprobe ipip lsmod | grep ipip
然后在Director上配置VIP并添加转发规则。Tunnel模式下Director的VIP配置在物理网卡（或别名网卡）上，转发规则使用-i参数指定隧道模式：
# 在物理网卡上绑定VIP ip addr add 192.168.10.100/32 dev eth0 # 添加虚拟服务，调度算法使用轮询 ipvsadm -A -t 192.168.10.100:80 -s rr # 添加两台RealServer，-i表示Tunnel模式 ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.21 -i ipvsadm -a -t 192.168.10.100:80 -r 192.168.10.22 -i # 查看规则 ipvsadm -Ln
这里需要注意两点：一是VIP建议用/32掩码配置，避免影响主网段的路由；二是-i参数绝不能漏掉，如果写成-g就变成DR模式、-m则是NAT模式，模式不匹配会导致后端无法收到正确报文。调度算法rr表示纯轮询，生产环境更常用wlc（加权最小连接），可以根据RealServer的硬件差异分配不同权重，例如给性能强的机器加-w 3参数。
三、RealServer配置与ARP抑制
RealServer的配置是Tunnel模式成败的关键，主要做三件事：加载ipip模块、创建tunl0网卡并绑定VIP、设置ARP相关内核参数。
两台RealServer执行相同的操作：
systemctl stop firewalld setenforce 0 # 加载IP隧道模块 modprobe ipip # 创建并配置tunl0虚拟网卡，VIP绑定在这里 ip link set tunl0 up 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 # 关闭反向路径过滤，这一步在Tunnel模式中必不可少 echo 0 > /proc/sys/net/ipv4/conf/tunl0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
几个参数的含义值得深入理解。arp_ignore设为1表示只响应目标IP和接收接口匹配的ARP请求，避免RealServer对VIP的ARP广播做出回应；arp_announce设为2表示通告地址时始终使用最合适的本地地址。如果这两个参数没设置，局域网内多台机器同时宣告VIP的MAC地址，会导致ARP表混乱，流量被随机引到某台RealServer上，完全绕开Director。
rp_filter（反向路径校验）是新手最容易踩的坑。默认值为1时，内核会检查收到的报文源地址是否可以从接收接口反向路由回去。Tunnel模式的报文经过封装，RealServer解开后看到的源IP是客户端地址，与接收路径不符，校验失败的报文会被直接丢弃。所以必须把tunl0和all的rp_filter都设为0。不少人配置完发现后端机器能收到报文但不回应，十有八九就是这个参数没改。
参数永久生效可以写入/etc/sysctl.conf：
net.ipv4.conf.tunl0.arp_ignore = 1 net.ipv4.conf.tunl0.arp_announce = 2 net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.tunl0.rp_filter = 0 net.ipv4.conf.all.rp_filter = 0
最后在两台RealServer上分别启动测试用的Web服务，比如用不同内容区分节点：
echo "RealServer 1" > /var/www/html/index.html systemctl start httpd
四、验证测试与常见问题排查
在客户端（可以用任意能访问VIP的机器）反复请求VIP，观察返回内容：
curl http://192.168.10.100 curl http://192.168.10.100 curl http://192.168.10.100
如果配置正确，两次请求会交替返回RealServer 1和RealServer 2的内容。同时在Director上执行ipvsadm -Ln --stats，可以看到两台后端服务器的连接数都在增长，说明调度生效。也可以用watch ipvsadm -Ln动态观察ActiveConn和InActConn数值的变化。
如果测试不通，建议按以下顺序排查。第一步在Director上执行tcpdump -i eth0 host 192.168.10.21 and port 80抓包，确认封装后的报文已经发出；第二步在RealServer上执行tcpdump -i tunl0，确认隧道报文被解开并交给了tunl0网卡。如果Director发出但RealServer收不到，检查中间网络设备是否放行了IP协议号4（IPIP协议）的报文，部分云厂商的安全组或硬件防火墙默认只放行TCP/UDP，会拦截IPIP报文。
如果RealServer收到了报文但不回包，重点检查三处：rp_filter是否为0、VIP是否正确绑定在tunl0上、Web服务是否监听在0.0.0.0而非仅监听物理网卡IP。另外要记住Tunnel模式要求RealServer的内核支持IP隧道，CentOS 7及以上版本的默认内核都没问题，但如果使用某些裁剪过的定制内核，需要确认CONFIG_NET_IPGRE和CONFIG_IP_TUNNEL相关选项已开启。
五、三种模式的选型建议
Tunnel模式并非万能，实际选型要结合网络条件。NAT模式配置最简单，后端可以跨网段，但响应流量都要回经Director，Director容易成为带宽瓶颈，适合小型集群；DR模式性能最好、报文不做封装，但要求所有节点在同一二层网络；Tunnel模式介于两者之间，性能略低于DR却支持跨网段，非常适合后端分布在不同机房、通过公网或专线互联的场景。
还有一个运维层面的建议：Tunnel模式的Director本身仍是单点，生产环境应配合Keepalived实现主备Director容灾，Keepalived原生支持LVS配置管理，还能对RealServer做健康检查，自动摘除故障节点。将ipvsadm手工配置迁移到Keepalived配置文件后，整套负载均衡系统才真正具备生产可用的可靠性。
LVS Tunnel模式CentOS负载均衡IP隧道修改时间：2026-09-12 19:04:37