企业官网建设流程全解析

1. 为什么还要聊LVS和NAT模式

干了这么多年运维，每次带新人或者跟同行交流，只要话题一碰到四层负载均衡，LVS就绕不开。很多人第一次接触LVS，看到那一堆术语——DS、RS、VIP、DIP、RIP，再加上三种模式（NAT、DR、TUN），直接就被劝退了。但说实话，如果你只是想快速搭一套能用的四层负载均衡，NAT模式是最容易上手、对网络环境要求最低的一种。它不需要改后端服务器的默认网关，不需要在RS上做复杂的ARP抑制，甚至不需要后端服务器和负载均衡器在同一个二层网络里。你只要有一台能通外网、能通内网的Linux机器，就能把整套东西跑起来。

这篇文章就是围绕LVS的NAT模式来展开的。我会从整体设计思路讲起，把为什么选NAT、NAT模式的数据包流转逻辑、ipvsadm的核心参数、后端Real Server的配置要点，一直到完整的实操步骤和排错经验，全部拆开揉碎讲一遍。适合那些刚接触四层负载均衡、想快速搭一套实验环境验证效果的运维新手，也适合那些以前只用过Nginx七层代理、想往四层下沉一步的开发者。看完之后你至少能做到：自己规划IP、自己配LVS、自己加后端、自己验证效果，出了问题知道从哪几个方向去查。

2. LVS NAT模式整体设计与思路拆解

2.1 为什么选NAT模式而不是DR或TUN

LVS的三种模式里，DR模式性能最好，因为响应包直接由RS返回给客户端，不经过Director。但DR模式有个硬性要求：Director和RS必须在同一个物理二层网络里，而且RS上要配置VIP到lo接口并做ARP抑制。TUN模式更麻烦，需要RS支持IP隧道，网络环境要允许协议号4的IPIP包通过。相比之下，NAT模式虽然性能不如前两者，但它的网络要求最低——Director只要能和RS通信就行，RS的网关指向Director即可。对于实验环境、内部测试环境、或者后端服务器数量不多的小型生产环境，NAT模式完全够用。

我个人的经验是，如果你第一次搭LVS，直接上DR模式很容易在ARP抑制那一步卡住，因为不同发行版、不同内核版本对arp_ignore和arp_announce的处理有细微差异。NAT模式就没这些坑，你只要把网络层配通，剩下的就是ipvsadm几条命令的事。

2.2 NAT模式的数据包流转逻辑

NAT模式的核心就一句话：客户端请求到Director，Director做DNAT把目标地址改成某台RS的地址，RS处理完把响应包回给Director，Director再做SNAT把源地址改成VIP，最后返回给客户端。整个过程客户端只知道VIP，不知道后面有多少台RS。

这里有个关键点：RS的默认网关必须指向Director的内网IP（DIP）。因为RS收到的请求包源地址是客户端地址，如果RS的默认网关不是Director，它就会尝试直接把响应包发给客户端，但客户端根本不认识RS的地址，这个包就丢了。所以NAT模式下，Director实际上是RS的网关，所有回包都必须经过Director。

2.3 整体架构规划

我一般做实验会用三台虚拟机，规划如下：

VIP和DIP在不同网段，这样NAT的DNAT和SNAT逻辑更清晰。如果你只有一个网段，也可以做，但实验效果没那么直观。

3. 核心细节解析与实操要点

3.1 ipvsadm核心参数拆解

ipvsadm是LVS的管理工具，命令不多，但每个参数的含义要搞清楚。最常用的几条：

• -A：添加一个虚拟服务，后面跟VIP和端口，-s指定调度算法
• -a：添加一台Real Server，-r指定RS地址，-m表示NAT模式
• -l：列出当前规则
• -n：不解析域名，直接显示IP
• -C：清空所有规则
• -Z：清零计数器

调度算法我一般用wrr（加权轮询）或者rr（轮询）。如果后端机器配置不一样，用wrr给高配机器更大权重。lc（最少连接）在长连接场景下更合适，但实验环境用rr就够了。

3.2 后端Real Server的配置要点

NAT模式下RS的配置极其简单，但有两个地方必须注意：

第一，RS的默认网关必须指向DIP。这是NAT模式的硬性要求，不配的话回包出不去。第二，RS上不需要安装任何LVS相关的软件，它就是一个普通的Web服务器，跑个Nginx或者Apache就行。

提示：如果你在RS上看到请求的源IP是客户端真实IP，那是正常的，因为Director做的是DNAT，没有改源地址。但响应包回Director的时候，Director会做SNAT，所以客户端看到的响应源IP是VIP。

3.3 内核参数转发设置

Director上必须开启IP转发，否则内核不会把包从一个网卡转到另一个网卡。命令是：

echo 1 > /proc/sys/net/ipv4/ip_forward

永久生效的话写到/etc/sysctl.conf里：

net.ipv4.ip_forward = 1

然后sysctl -p加载。这个参数不开启，LVS规则配了也没用，包根本不会转发。

4. 完整实操过程与核心环节实现

4.1 环境准备与网络配置

先在三台机器上把网络配好。Director有两块网卡，ens33对应VIP网段，ens34对应DIP网段。RS各一块网卡，网关指向DIP。

Director网络配置示例：

# ens33 配置VIP nmcli con mod ens33 ipv4.addresses 192.168.100.100/24 nmcli con mod ens33 ipv4.method manual nmcli con up ens33 # ens34 配置DIP nmcli con mod ens34 ipv4.addresses 10.0.0.1/24 nmcli con mod ens34 ipv4.method manual nmcli con up ens34

RS网络配置示例（以rs-web-01为例）：

nmcli con mod ens33 ipv4.addresses 10.0.0.11/24 nmcli con mod ens33 ipv4.gateway 10.0.0.1 nmcli con mod ens33 ipv4.method manual nmcli con up ens33

配完之后互相ping一下，确保Director能ping通RS，RS能ping通DIP。

4.2 Director上安装和配置LVS

安装ipvsadm：

yum install -y ipvsadm # 或者 Ubuntu/Debian apt install -y ipvsadm

开启IP转发：

echo 1 > /proc/sys/net/ipv4/ip_forward

添加虚拟服务和Real Server：

# 添加虚拟服务，VIP 192.168.100.100:80，调度算法轮询 ipvsadm -A -t 192.168.100.100:80 -s rr # 添加两台RS，NAT模式 ipvsadm -a -t 192.168.100.100:80 -r 10.0.0.11:80 -m ipvsadm -a -t 192.168.100.100:80 -r 10.0.0.12:80 -m # 查看规则 ipvsadm -ln

正常输出应该是这样的：

IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.100.100:80 rr -> 10.0.0.11:80 Masq 1 0 0 -> 10.0.0.12:80 Masq 1 0 0

Masq就是NAT模式的标记，看到这个说明规则加对了。

4.3 后端RS部署Web服务

两台RS上各装一个Nginx，写一个简单的测试页面：

yum install -y nginx echo "This is RS1 - 10.0.0.11" > /usr/share/nginx/html/index.html systemctl start nginx systemctl enable nginx

RS2同理，页面内容改成RS2的标识。这样访问的时候能直观看到请求被分发到了哪台机器。

4.4 验证负载均衡效果

在客户端机器上（或者直接在Director上用curl访问VIP）：

curl http://192.168.100.100

多执行几次，应该能看到RS1和RS2的页面交替出现。如果只出现一台，检查另一台RS的Nginx是否正常、网关是否指向DIP。

查看连接分发情况：

ipvsadm -ln --stats

这个命令会显示每台RS的活跃连接数和总连接数，能直观看到分发是否均匀。

5. 常见问题与排查技巧实录

5.1 访问VIP不通或超时

这是最常见的问题，排查顺序如下：

我踩过最坑的一次是RS上开了firewalld，80端口没放行，Director转发过去的包直接被RS的防火墙丢了。后来养成习惯，实验环境先把防火墙关了或者放行相关端口。

5.2 只有一台RS能响应

如果发现所有请求都打到同一台RS上，先检查另一台RS的Nginx是否正常。如果Nginx正常，再看ipvsadm -ln里那台RS的Weight是不是0。有时候手误把权重设成0了，流量就不会往那台机器分。

还有一种情况是调度算法用了wrr，但两台机器权重不一样，流量分配不均。实验环境建议先用rr，确认分发正常后再调权重。

5.3 客户端看到的源IP不对

NAT模式下，RS看到的源IP是客户端真实IP，但客户端看到的响应源IP是VIP。如果你在RS的访问日志里看到的是客户端IP，那是正常的。如果你希望RS看到的是Director的DIP，那需要做Full NAT，但LVS原生不支持Full NAT，需要额外打补丁或者用其他方案。

5.4 持久连接问题

有些应用需要同一个客户端的请求始终打到同一台RS上，比如带Session的Web应用。LVS支持持久连接，用-p参数：

ipvsadm -A -t 192.168.100.100:80 -s rr -p 300

-p 300表示300秒内同一个客户端IP的请求都打到同一台RS。这个在实验环境里很好验证，加完之后再curl，会发现一段时间内始终返回同一台RS的页面。

注意：持久连接会影响负载均衡效果，如果客户端IP集中（比如都在一个NAT后面），会导致流量倾斜。生产环境要结合实际情况决定是否开启。

6. 实操心得与进阶建议

6.1 实验环境搭建的几个小技巧

我一般会用Vagrant或者Docker来快速起实验环境。如果用虚拟机，建议Director至少给2G内存，RS给1G就够了。网络模式用Host-Only或者自定义NAT网络，避免和宿主机网段冲突。

另外，实验前先把所有机器的防火墙和SELinux关掉，能省掉至少一半的排错时间。命令：

systemctl stop firewalld setenforce 0

生产环境当然不能这么干，但实验环境先跑通再说。

6.2 从NAT模式往DR模式迁移的思路

如果你NAT模式跑通了，想试试DR模式，核心改动就三点：Director和RS要在同一网段；RS上要把VIP配到lo接口；RS要做ARP抑制。ipvsadm的命令从-m改成-g。其他逻辑基本一样。所以NAT模式是很好的入门跳板，先把LVS的基本概念和命令熟悉了，再往高性能模式迁移就顺理成章。

6.3 监控和日常维护

生产环境用LVS，至少要监控两个东西：Director上的连接分发是否均匀，以及RS的健康状态。LVS本身不带健康检查，需要配合keepalived或者自己写脚本。实验环境可以手动ipvsadm -ln --stats看看，生产环境一定要上自动健康检查，否则一台RS挂了，流量还会往上面打，客户端就会遇到间歇性502。

我个人在实际操作中的体会是，LVS NAT模式虽然简单，但它是理解四层负载均衡最好的切入点。你把NAT模式的数据包流转搞清楚了，再去理解DR和TUN就非常容易。而且NAT模式在很多内部系统里仍然在用，并不是说它性能差就完全被淘汰了。关键还是看场景，适合的才是最好的。