企业官网建设流程全解析

搞过负载均衡的兄弟，对LVS应该都不陌生，生产环境里NAT和DR是被用得最多的两种模式。但TUN模式——这个经常被文档一笔带过、实际又能解决大问题的方案，我今天想拿出来单独聊聊。LVS TUN模式的核心思路是把客户端的请求包通过IP隧道（IP in IP）封装后转发给后端真实服务器，真实服务器处理完后直接把响应回给客户端，调度器完全不碰响应流量。它最大的价值在于：调度器和真实服务器可以跨网段部署，甚至跨机房、跨地域，这是DR模式做不到的。如果你正在规划一个多机房负载均衡集群，或者被TUN模式的"玄学现象"折磨过，这篇内容应该能帮到你。

1. 先搞清楚TUN模式在LVS家族里是什么定位

1.1 三种模式的本质区别

LVS总共提供三种转发模式：NAT、DR、TUN。很多人一开始学的时候，会觉得TUN模式和DR模式长得差不多——都是"请求进调度器、响应不回来"，但两者的实现机制完全不是一回事。

NAT模式最简单粗暴：调度器把请求的目的IP从VIP改成真实服务器的IP，转发过去，真实服务器处理完把响应交回调度器，调度器再把源IP改回VIP，还给客户端。这个模式下调度器是所有流量的必经之路，一来一回都是它扛，吞吐量上限就在调度器的网卡和转发性能上。

DR模式呢，靠的是改写MAC地址。调度器收到请求后，把包的目的MAC改成真实服务器的MAC，原封不动扔到二层网络里。真实服务器看到目的IP是VIP，自己正好绑着VIP，就把包收下处理，响应直接回给客户端。因为响应不经过调度器，所以性能比NAT高很多。但代价就是：调度器和真实服务器必须在同一个二层网络里，否则改MAC这招就废了。

TUN模式则完全不同，它靠的是IP隧道封装。调度器收到请求后，不改变原来的IP包内容，而是在这个包外面再套一层新的IP头：外层源地址是调度器自己的IP，外层目的地址是真实服务器的IP，IP头里的协议号是4（IPIP）。真实服务器收到后把外层包头剥掉，看到里面的目的IP还是VIP，而自己也绑着VIP，于是交给上层应用处理。响应同样绕开调度器直接回给客户端。

三种模式放到一起对比，定位就很清楚了：

这个表基本概括了TUN模式的取舍：它能突破DR模式的二层限制，代价是每个包都多出一层封装头，MTU变小，且对系统内核有额外的要求。

1.2 TUN模式的适用场景与取舍

TUN模式最适合的场景，就是"真实服务器不在调度器旁边"的情况。

举几个典型的例子：调度器在北京机房，真实服务器分布在华东、华南的多个机房；或者几个业务节点在不同的内网网段，之间靠路由器打通。这种拓扑下DR模式的二层限制就完全行不通，而你又不希望响应流量都回调度器绕一圈，NAT模式天然不合适。TUN模式就成了唯一能满足"跨网络部署+响应不回调度器"这两个条件的LVS架构。

另一个很适合的场景是UDP类业务，比如DNS、视频流、语音包。这类服务有个特点：请求包很小，响应包可能很大。如果用NAT模式，大响应全走调度器，调度器网卡很容易被打满。TUN模式下大流量直接从真实服务器出网，调度器只负责转发那些小请求包，压力小一个量级。

但TUN模式也不是免费的午餐。它要求所有真实服务器的内核支持IPIP协议，还要做不少初始化配置；每个包多20字节的隧道头，意味着传输效率略低于DR；而且很多云厂商的VPC网络直接屏蔽协议号4的包，在公有云上往往根本跑不起来。所以选型时一定要先确认底层网络是否放行IPIP流量，再做打算。

2. TUN模式的数据流转与核心原理

2.1 请求方向：从客户端到真实服务器的封装过程

理解TUN模式，把请求方向的包流转过程吃透是关键。我画过很多次这个流程，每次讲给别人听都从这一段开始。

第一步，客户端发起请求。假设客户端要去访问VIP（192.168.100.100）上的80端口，发出的TCP SYN包目的IP是VIP，源IP是客户端自己的IP，MAC地址则是网关或VIP所在网段解析出来的地址。这个包经过网络路由，最终到达调度器。

第二步，调度器收包后交给LVS框架处理。LVS在内核里通过Netfilter钩子拦截到达VIP的包，查一下ipvsadm配置的服务表和转发规则，决定这个包要交给哪台真实服务器。假如调度规则是轮询或者加权最小连接，这次选中的是IP为192.168.200.11的真实服务器。

第三步，调度器执行隧道封装。这一步是TUN模式的心脏。LVS在原始IP包前面再加一个IP头，变成"外层头+内层原始包"的结构。外层头的源地址是调度器自己的IP（比如192.168.0.10），目的地址是真实服务器的IP（192.168.200.11），协议号填4（表示IP-in-IP封装）。封装完成后，包从调度器的网卡发出，通过路由器转发到真实服务器的网段。

第四步，真实服务器收到这个外层包，内核里的IPIP隧道模块（tunl0）负责拆包，剥离外层IP头，还原出原始请求包，目的IP依然是VIP。因为我们在真实服务器上已经把VIP绑到了lo接口上，内核一查路由表，发现VIP是自己的地址，就把这个包交给上层应用处理。

这里有个容易绕晕的点：内层包的目的IP一直是VIP，从头到尾没有被改过。真实服务器之所以能收到并处理这个包，不是因为包的目的IP写了它的内网IP，而是因为隧道封装让包"物理上"送到了它的网卡，解封装后目的IP又恰好是它绑定在lo上的VIP。这个设计非常优雅，也意味着真实服务器和调度器之间不需要任何IP地址映射。

2.2 响应方向：为什么可以不经过调度器

TUN模式最大的爽点就在响应方向。因为内层请求包的目的IP是VIP，真实服务器上的应用（比如Nginx）处理时，看到的客户端连接是"客户端IP -> VIP"。它回包时，源IP自然写的是VIP，目的IP是客户端IP，然后按照自己的默认路由把包从eth0发出去。

这个响应包不需要回调度器，直接从真实服务器的出网口走正常路由回到客户端。客户端拿到包一看，源IP正是它请求的VIP，完全感知不到背后有三台服务器、还跨了两个机房。

所以整个集群的流量分布是这样的：入方向的请求流量全部打到调度器，调度器封装后转发给各真实服务器；出方向的响应流量则零散分散在各真实服务器的出口上。调度器的负载只和请求包数量、请求包大小有关，跟响应包大小完全无关。

这带来的一个直接收益是：调度器不需要为响应带宽买单。我曾经遇到过一个图片服务，请求很小，响应动辄几百KB，用NAT模式时调度器的出口带宽天天打满，换了TUN模式之后调度器负载直接降了七八成，真实服务器各自出网，带宽压力分散开，问题立刻解决。

另外一个需要注意的点：TUN模式之所以响应能直连客户端，隐含的前提是真实服务器有自己独立的出网路径。如果真实服务器的默认网关恰好指向调度器，那响应包还是会先走到调度器再出去，虽然源IP还是VIP、功能上没问题，但调度器又背上了出流量，TUN的优势就打了折扣。所以我建议在规划网络时，尽量让真实服务器的出口走自己的公网网关或专线，不要让调度器成为它们的默认网关。

3. 环境规划与配置实战

3.1 网络拓扑与IP规划

在动手配置前，先把架构和IP规划说清楚。下面这套是我在生产环境里验证过多次的标准TUN模式拓扑，调度器和真实服务器分属不同网段，中间靠三层路由打通。

客户端 (Internet) | | 请求 VIP: 192.168.100.100:80 v 调度器 Director eth0: 10.0.0.10/24 VIP: 192.168.100.100/32 绑在 eth0 | | IPIP隧道封装，外层目的 = 真实服务器IP v RealServer1 (eth0: 192.168.200.11/24, lo: 192.168.100.100/32) RealServer2 (eth0: 192.168.200.12/24, lo: 192.168.100.100/32) | | 响应直连客户端 v 客户端收到源IP=VIP的响应

IP角色分配表大概是这样的：

这个规划里有几个细节我要专门说。第一，VIP在真实服务器上一定要用32位掩码绑到lo上，千万别配成24位。如果配成192.168.100.100/24，内核会认为整个192.168.100.0/24网段都在本地，生成一条直连路由，后面各种路由混乱和ARP问题就全来了。第二，调度器的VIP可以直接绑在eth0上，因为TUN模式需要调度器对外回应VIP的ARP请求，绑在物理网卡上最直接。

3.2 调度器配置步骤

调度器端的配置分四步，每一步都有对应的坑，我按顺序过一遍。

第一步，开启IP转发。调度器要把请求转发给真实服务器，这个开关必须开：

echo 1 > /proc/sys/net/ipv4/ip_forward # 如果想永久生效，写到 /etc/sysctl.conf # net.ipv4.ip_forward = 1

第二步，加载IPIP内核模块。传统做法是：

modprobe ipip

加载完毕检查一下tunl0接口是否创建成功：

ip link show tunl0

这里有个版本差异提醒：在较老的内核上，加载ipip模块会直接生成默认的tunl0隧道接口；在部分新版本内核上，tunl0可能不会自动创建，需要你手动加：

ip tunnel add tunl0 mode ipip local 10.0.0.10 dev eth0 ip link set tunl0 up

具体以你系统上ip link show tunl0的输出为准，没有这个接口就手动建。tunl0的含义是"所有发到这个隧道接口的包，都按普通IPIP隧道处理"，调度器封装时靠它来发。

第三步，配置VIP：

ip addr add 192.168.100.100/32 dev eth0 ip addr show eth0

配置完成后，从调度器本机ping一下VIP，能通说明地址绑好了。注意VIP的掩码也建议用/32，避免生成额外的网段路由干扰转发逻辑。

第四步，配置LVS规则。用ipvsadm添加服务和真实服务器，关键参数是-i，这个选项代表TUN模式，和DR模式的-g、NAT模式的-m有本质区别：

ipvsadm -A -t 192.168.100.100:80 -s wlc ipvsadm -a -t 192.168.100.100:80 -r 192.168.200.11 -i ipvsadm -a -t 192.168.100.100:80 -r 192.168.200.12 -i ipvsadm -L -n

最后一条命令可以看到类似这样的输出：

IP Virtual Server version 1.2.1 Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Forward Weight ActiveConn InActConn TCP 192.168.100.100:80 wlc -> 192.168.200.11:80 Tunnel 1 0 0 -> 192.168.200.12:80 Tunnel 1 0 0

Forward那一列显示Tunnel，就说明转发模式对了。这里有个非常常见的翻车点：有人想把DR模式改成TUN模式，图省事直接在原有规则上用ipvsadm -E去编辑，但转发模式这个属性不是通过编辑服务改的，必须先删掉真实服务器再用-i重加。我习惯的做法是干脆全部删掉重新配，几秒钟的事，不会留下残留状态。

配置完把规则持久化一下，避免重启丢失：

ipvsadm-save > /etc/sysconfig/ipvsadm # systemd 发行版可以启用 ipvsadm 服务 systemctl enable ipvsadm

3.3 真实服务器配置步骤

真实服务器的配置稍多一点，但每一条都有明确的必要性。完整跑一遍：

第一步，加载IPIP模块并启用tunl0：

modprobe ipip ip link set tunl0 up

第二步，把VIP绑定到lo接口。注意掩码必须是255.255.255.255（/32）：

ip addr add 192.168.100.100/32 dev lo ip addr show lo

这里也可以写成ifconfig lo:0 192.168.100.100 netmask 255.255.255.255 up，两种方式效果一样，ip route命令更现代一些，建议用ip系列。

第三步，抑制ARP响应。这是TUN模式最容易出事的地方。如果不做这个操作，真实服务器绑上VIP之后，因为默认的arp_ignore是0，它会对所有网卡上传来的VIP地址ARP请求都回应，等于公开宣告"我也持有这个VIP"，会和调度器抢答，客户端的流量就开始随机串门，整个集群直接乱套。

标准做法是：

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

再针对tunl0放宽成默认值，保证隧道本身不受ARP抑制影响：

echo 0 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore echo 0 > /proc/sys/net/ipv4/conf/tunl0/arp_announce

arp_ignore=1的意思是：只回应那些"目标IP地址配置在本接口上"的ARP请求。VIP现在只绑在lo上，eth0收到的ARP请求里如果目标IP是VIP，内核发现VIP不在eth0上，于是不回应，这样VIP的ARP响应就只有调度器会发。arp_announce=2则是限制ARP通告时源IP的选取规则，避免内核挑一个"看起来不对"的源地址（比如把VIP当源地址通告出去）造成客户端缓存错乱。

这里我想说一个实际踩过的坑：如果只用sysctl -w net.ipv4.conf.all.arp_ignore=1，而不单独设置具体接口，某些内核版本里all和具体接口的值取的是最小值，可能出现抑制不彻底的情况。保险起见，除了设置all，还要对实际对外的物理网卡（比如eth0）单独设置：

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

第四步，检查路由。真实服务器需要有一条能到达客户端网络的出向路由，通常默认路由就够用：

ip route show # 应存在 default via 网关 dev eth0 之类的路由

至此，真实服务器的核心配置完成。整个配置过程中，tunl0、VIP on lo、ARP抑制这三件事缺一不可。tunl0负责接收隧道包，VIP on lo保证解封装后内核肯收包，ARP抑制防止真实服务器和调度器抢ARP应答，任何一个没做对，线上都会出现"时好时坏"的诡异故障。

4. 配置验证与压测要点

4.1 验证链路是否打通

配置完成后，不要急着把流量切过去，先按从下到上的顺序做链路验证。这个顺序能帮你把问题缩小到某个具体环节，而不是乱成一团。

第一步验证隧道连通性。在真实服务器上ping调度器的IP，在调度器上ping真实服务器的IP，确认基础三层网络是通的。这一步如果都不通，说明路由或防火墙就有问题，后面不用看了。

第二步验证IPIP封装能跨网段送达。在调度器上用ping命令带上特殊选项，直接往真实服务器的IP发IPIP封装的报文：

ping -c 3 -W 1 192.168.200.11

ping本身只能验证ICMP协议，不能验证IPIP隧道的转发。更准确的验证方式是在真实服务器上用tcpdump抓tunl0上的包，同时在调度器上发起一个指向VIP的HTTP请求，观察真实服务器tunl0上是否出现解封装后的TCP包：

# 真实服务器上执行 tcpdump -i tunl0 -nn port 80

然后再从某个客户端发起访问VIP的请求。如果tunl0上有包出现，说明隧道链路已经打通。

第三步验证应用响应。在真实服务器上确认Web服务正常监听，比如Nginx监听0.0.0.0:80或VIP:80。这里有个小细节：如果Nginx只监听了真实服务器的内网IP，那么即使隧道打通、内核收了包，应用层也会因为连接地址不匹配而拒绝处理。所以TUN模式下的应用服务一定要监听在0.0.0.0或者VIP上。

第四步做全链路验证。在客户端机器上curl一下VIP地址，能正常返回内容的话，基本链路就算通了。再用ipvsadm -L -n --stats查看调度器统计信息：

ipvsadm -L -n --stats

正常情况下的输出里，InOctets（入方向字节）会持续增长，而OutOctets（出方向字节）基本不动。这组数据就是我判断"响应是否真的绕过调度器"的黄金指标。如果发现OutOctets跟着InOctets一起涨，说明真实服务器的响应又绕回调度器了，通常就是前面说的"真实服务器默认网关指向了调度器"导致的。

4.2 压测中重点关注的东西

链路通了之后，建议做一轮短压测，重点不是刷一个好看的QPS数字，而是确认以下三件事。

第一，连接是否均匀分布。用ipvsadm -L -n --stats观察ActiveConn在各真实服务器之间的分布。如果配的是wlc算法，连接数应该大致按权重分配。如果所有连接都堆在某一台机器上，先检查是不是这台机器响应慢导致连接一直挂着，再检查权重配没配错，用ipvsadm -E调整。

第二，调度器出口带宽是否稳得住。TUN模式下调度器只发请求包，压力很小，但也不能完全不管。压测时在调度器上跑一个sar -n DEV 1或者iftop，确认eth0的出口流量远小于总业务响应流量，这就说明TUN模式的核心价值体现出来了。如果出口流量还是很大，优先怀疑响应绕回调度器的问题，而不是傻乎乎地给调度器扩带宽。

第三，客户端侧做丢包统计。因为IPIP协议在有些网络设备上会被特殊对待，压测时在客户端ping VIP，观察丢包率和延迟抖动。如果出现高延迟但没丢包，大概率是MTU问题；如果出现周期性丢包，要看中间设备是不是对协议号4的包有安全策略。

压测我一般用的工具是wrk或者ab，命令不复杂，关键是看上面这三个维度的数据，而不是单纯追求一个分数。负载均衡链路只要这三个指标正常，业务侧一般就稳了。

5. 常见问题与排错实录

5.1 请求进来没响应

这是TUN模式被问得最多的现象：调度器规则配好了，VIP也能ping通，但从客户端访问VIP就是转圈，或者连接直接超时。

按我自己的排查习惯，第一步是在真实服务器上抓tunl0的包。如果tunl0上根本没流量，问题大概率出在调度器到真实服务器的封装或路由环节。先确认调度器上tunl0存在且是UP状态：

ip link show tunl0

再确认调度器能ping通真实服务器。能ping通但隧道没数据，十有八九是ipvsadm里转发模式配错了，ipvsadm -L -n里Forward列显示的应该是Tunnel，而不是Route（DR模式）或Masq（NAT模式）。

如果tunl0上能看到包，但应用就是没响应，问题在解封装之后的环节。重点检查真实服务器上VIP是否绑在lo上、掩码是否为/32。次一级的检查点是：应用有没有监听在0.0.0.0或VIP上。

还有一个容易被忽略的环节是防火墙。真实服务器上如果开了iptables，且INPUT链默认DROP，那IPIP解封装后的包可能被防火墙拦掉。测试时可以先临时flush规则：

iptables -F

但要注意，这只是定位手段，真实环境里应该精确放行协议号4的隧道流量，而不是清空规则：

iptables -I INPUT -p 4 -s 10.0.0.10 -j ACCEPT

5.2 ARP冲突与地址双响

前面提到过ARP抑制配置，实际操作中最大的麻烦是：配置漏掉了，或者配置值不对，导致同一网段里有多个设备回应VIP的ARP请求。

典型症状是：客户端访问VIP时好时坏，时延忽高忽低，或者有些客户端直接被引导到真实服务器上，而真实服务器如果不做响应转发的话，这些请求就石沉大海。

排查方法很直接，在客户端或者调度器所在网段抓ARP包：

tcpdump -i eth0 -nn arp

如果看到VIP的ARP请求有多个IP在应答，或者应答的MAC地址不是调度器网卡的MAC，那就说明有真实服务器"泄密"了。回到那台真实服务器上，检查cat /proc/sys/net/ipv4/conf/eth0/arp_ignore，值应该至少是1。

我个人的经验是：ARP抑制的配置要在做系统初始化的时候就固化到/etc/sysctl.conf里，不要等出了问题再手动敲命令。因为手动敲的命令重启就没了，而初始化脚本里写清楚之后，以后每扩容一台真实服务器，照着同步就行，不会漏。

5.3 MTU引发的黑洞问题

IPIP封装给每个包增加20字节的外层IP头，这意味着物理链路MTU为1500的情况下，隧道内的有效负载MTU只有1480。如果业务使用的是TCP，再算上TCP/IP头开销，实际TCP MSS会从标准的1460变成1440左右。

如果应用或者中间设备没有感知这个变化，发送大于1440字节的包时就会出问题。常见表现是：小请求正常，大响应卡死，或者网页加载到一半就停住。

排查MTU问题有个经典方法，在客户端用ping加"禁止分片"标志测试：

ping -M do -s 1472 192.168.100.100

如果1472字节能通（1472为ICMP数据长度，加上20字节IP头正好是1492），再往上加到1473（对应1493的IP包）就超时，基本可以断定是路径上某个节点的MTU限制了。

解决办法有几个方向。第一，在应用层调整MSS，比如iptables的MSS钳制：

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

第二，在隧道接口上设置合理的MTU，让内核主动分片或通知发送端调整。第三，如果网络都在自己掌控范围内，可以把所有链路MTU统一调成1450或者1480，给隧道头留出余量。不管选哪种，都要在压测阶段就验证大包传输，别等到上生产再被这个坑绊一跤。

5.4 一些容易被忽略的细节

有几个小问题，我几乎每次搭TUN集群都会遇到，单独列出来给各位提个醒。

调度器自己也别在VIP上监听服务。如果调度器上装了Nginx，监听0.0.0.0:80，那VIP:80的请求会先被本地内核直接交给Nginx处理，LVS根本接不到这个包，转发规则全部失效。生产上建议调度器保持干净，只做转发，不要混跑业务应用。

IP隧道协议被中间网络设备过滤。协议号4的IP-in-IP报文，在不少路由策略、安全组、云厂商VPC里是被默认丢弃的。如果你跨机房部署，业务方反馈访问不通，而两边的服务器TCP/IP本身都正常，先查中间网络策略是否放行协议4。

tunl0接口状态莫名DOWN。某些发行版的内核或者网络管理工具（比如NetworkManager）可能会在重启后把tunl0的状态重置，导致隧道静默失效。建议把tunl0的UP状态和LVS规则一起写进启动脚本，重启后自动恢复，不要依赖手动维护。

6. 使用心得与调优建议

6.1 调度算法与持久性的选择

TUN模式下调度算法选哪个，和模式本身关系不大，主要看业务特点。一般HTTP这类短连接服务，wlc（加权最少连接）是我用得最多的算法，它在各节点性能不均衡时能自动把新连接分给负载低的机器。如果各节点配置完全一样，业务又是无状态的，rr（轮询）也完全够用。

需要特别提一下持久性（persistence）配置。有些业务要求同一个客户端的请求始终打到同一台真实服务器上，比如带本地Session的Web应用。这时候在服务上加持久时间：

ipvsadm -E -t 192.168.100.100:80 -p 600 -s wlc

持久时间600秒，表示10分钟内同一个源IP的请求都发给同一台真实服务器。但要注意，持久性是个双刃剑：它会让负载均衡的"均衡"效果被削弱，如果某个客户端发起大量连接，这些连接会全堆在一台机器上。所以能用Session共享方案解决的话，尽量少用持久性。

6.2 什么情况不建议用TUN模式

虽然我把TUN模式讲得天花乱坠，但它确实有明确的"不适用"清单。

第一，所有真实服务器都在同一个二层网络、且不需要跨机房的场景，用DR模式。DR模式没有20字节的隧道开销，性能更好，配置也更简单，没有理由非要用TUN。

第二，真实服务器没有独立出网能力的场景。前文反复说过，TUN模式的核心收益是响应绕开调度器，如果真实服务器只能靠调度器当网关出网，那就等于把已经打开的"捷径"又关了，还白白多付了隧道开销。

第三，底层网络不支持或者禁止IPIP协议的场景。很多公有云VPC默认不允许协议号4的流量，你费劲配完，数据包在路上就被云网关丢了，这种情况老老实实买云负载均衡或者用DR模式（如果VPC支持）。

第四，调度器和真实服务器之间网络质量很差的场景。IPIP隧道对包的往返延迟没有额外加成，跨地域专线如果本身延迟和丢包就高，隧道只会放大问题，不会改善。

6.3 我的最后一条建议

如果你正打算在生产环境上TUN模式，我强烈建议先在测试环境完整跑一遍"配置->压测->故障注入"的流程。不是说这个模式复杂到学不会，而是它涉及调度器、真实服务器、网络设备三层协同，任何一个环节的配置遗漏，在线上都会表现为"间歇性故障"，这种问题排查起来非常费精神。把ARP抑制、MTU、隧道状态这些点提前踩一遍，等到真正切流量的时候，你就会发现TUN模式其实比想象中稳定得多。我自己用了这么多年，只要初始化脚本和环境检查做得规范，TUN集群一旦跑起来几乎不需要额外干预。