搞过负载均衡的兄弟对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外层目的地址是真实服务器的IPIP头里的协议号是4IPIP。真实服务器收到后把外层包头剥掉看到里面的目的IP还是VIP而自己也绑着VIP于是交给上层应用处理。响应同样绕开调度器直接回给客户端。三种模式放到一起对比定位就很清楚了特性NAT模式DR模式TUN模式调度器处理流量进出都经过只进不出只进不出真实服务器要求无特殊要求需绑定VIP抑制ARP需绑定VIP支持IPIP隧道网络位置可跨网段必须同二层可跨网段可跨机房性能瓶颈调度器双向压力较低较低额外开销无无每个包多20字节外层头这个表基本概括了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模式把请求方向的包流转过程吃透是关键。我画过很多次这个流程每次讲给别人听都从这一段开始。第一步客户端发起请求。假设客户端要去访问VIP192.168.100.100上的80端口发出的TCP SYN包目的IP是VIP源IP是客户端自己的IPMAC地址则是网关或VIP所在网段解析出来的地址。这个包经过网络路由最终到达调度器。第二步调度器收包后交给LVS框架处理。LVS在内核里通过Netfilter钩子拦截到达VIP的包查一下ipvsadm配置的服务表和转发规则决定这个包要交给哪台真实服务器。假如调度规则是轮询或者加权最小连接这次选中的是IP为192.168.200.11的真实服务器。第三步调度器执行隧道封装。这一步是TUN模式的心脏。LVS在原始IP包前面再加一个IP头变成外层头内层原始包的结构。外层头的源地址是调度器自己的IP比如192.168.0.10目的地址是真实服务器的IP192.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 客户端收到源IPVIP的响应IP角色分配表大概是这样的角色网卡IP地址用途调度器eth010.0.0.10/24内置IP隧道外层源地址调度器eth0别名192.168.100.100/32VIP对外提供服务真实服务器1eth0192.168.200.11/24内置IP接收隧道包真实服务器1lo192.168.100.100/32VIP保证内核收下解封装后的包真实服务器2eth0192.168.200.12/24内置IP接收隧道包真实服务器2lo192.168.100.100/32VIP保证内核收下解封装后的包这个规划里有几个细节我要专门说。第一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隧道处理调度器封装时靠它来发。第三步配置VIPip 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 0Forward那一列显示Tunnel就说明转发模式对了。这里有个非常常见的翻车点有人想把DR模式改成TUN模式图省事直接在原有规则上用ipvsadm -E去编辑但转发模式这个属性不是通过编辑服务改的必须先删掉真实服务器再用-i重加。我习惯的做法是干脆全部删掉重新配几秒钟的事不会留下残留状态。配置完把规则持久化一下避免重启丢失ipvsadm-save /etc/sysconfig/ipvsadm # systemd 发行版可以启用 ipvsadm 服务 systemctl enable ipvsadm3.3 真实服务器配置步骤真实服务器的配置稍多一点但每一条都有明确的必要性。完整跑一遍第一步加载IPIP模块并启用tunl0modprobe ipip ip link set tunl0 up第二步把VIP绑定到lo接口。注意掩码必须是255.255.255.255/32ip 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_announcearp_ignore1的意思是只回应那些目标IP地址配置在本接口上的ARP请求。VIP现在只绑在lo上eth0收到的ARP请求里如果目标IP是VIP内核发现VIP不在eth0上于是不回应这样VIP的ARP响应就只有调度器会发。arp_announce2则是限制ARP通告时源IP的选取规则避免内核挑一个看起来不对的源地址比如把VIP当源地址通告出去造成客户端缓存错乱。这里我想说一个实际踩过的坑如果只用sysctl -w net.ipv4.conf.all.arp_ignore1而不单独设置具体接口某些内核版本里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.11ping本身只能验证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而不是RouteDR模式或MasqNAT模式。如果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 ACCEPT5.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集群一旦跑起来几乎不需要额外干预。