负载均衡之-LVS （三）： LVS的TUN模式

TUN 模式

除了直接修改请求数据包的目标 MAC 地址，做一次 MAC 地址欺骗之外，还有没有其他方式能够将响应数据包由真实服务器直接返回给客户端呢？看看 VPN 是怎么能够支持你远程办公的吧～

我们已经讨论过，如果真实服务器直接将响应数据包返回给客户端，那么真实服务器必须有一个 “隐藏” 的 VIP，即配置在 lo 网卡上并且不允许此 VIP 通过 ARP 协议对外通告。

红色表示发出的数据包 绿色表示返回的数据包 黄色表示负载均衡器修改的内容 虚线表示经过 N 个下一跳，即可以不在同一局域网内 实线表示只能 “跳跃一次”，即必须在同一局域网内

1. 当计算机发出一个请求的数据包到达负载均衡器后，负载均衡器不改变源数据包，而是在源数据包上新增一层 IP 首部 { 分发 IP、端口号、MAC 地址 } ➡️ { 真实服务器 IP、端口号、MAC 地址 }
2. 真实服务器收到请求的数据包后，将最外层封装的 IP 首部去掉，发现还有一层 IP 首部，并且目标 IP 地址能够和 lo 上的地址匹配，于是收下请求数据包，并交由对应的上层应用处理
3. 处理完成后，将响应数据包直接返回给客户端。此时在真实服务器上查看 TCP 连接为：VIP ➡️ CIP

• 总结一下 TUN 模式的特点：

1. 不改变请求数据包，而是在请求数据包上新增一层 IP 首部信息。因此负载均衡器不能对端口进行转发，但可以和真实服务器不在同一局域网内，且真实服务器需要支持能够解析两层 IP 首部信息，即需要支持“IP Tunneling”或“IP Encapsulation”协议
2. 真实服务器中的 VIP，只能被自己 “看见”，其他设备不可知。因此 VIP 必须绑定在真实服务器的 lo 网卡上，并且不允许将此网卡信息经过 ARP 协议对外通告
3. 请求的数据包经过负载均衡器后，直接由真实服务器返回给客户端，响应数据包不需要再经过负载均衡器

在 DR 和 TUN 模式中，负载均衡器只转发了请求数据包，响应数据包不经过负载均衡器，而是直接返回给客户端。解决了在通常情况下响应数据包比请求数据包大，如果请求和响应数据包都经过负载均衡器，在高并发下可能成为系统瓶颈的问题。

根据我们的推导过程，可以轻易地得出各种模式的特点和它们要解决的问题。

• NAT 模式，通过修改数据包的「目标 IP 地址」和 「源 IP 地址」，将请求负载到多台真实服务器，是四层负载均衡模式中最基础的负载方式。因为它是对 IP 地址层面的修改，作用在网络层，所以可以对端口进行映射。真实服务器返回的响应数据包必须经过负载均衡器，所以要求真实服务器的默认网关是负载均衡器。
• FULLNAT 模式，是对 NAT 模式的一种演进。通过同时修改「源 IP 地址」和「目标 IP 地址」，突破 NAT 模式中真实服务器的默认网关必须是负载均衡器的限制。但是由于同时修改了「源 IP 地址」和「目标 IP 地址」，真实服务器建立的真实连接和客户端毫无关系，所以会丢失客户端的信息。
• DR 模式，是对 NAT 模式的另一种演进。由于真实请求中响应数据包比请求数据包大很多的特点，在高并发下会成为系统的瓶颈，于是将响应数据包直接由真实服务器返回给客户端。使用 MAC 地址欺骗来达到此目的，作用于数据链路层，所以不能对端口映射。并且在真实服务器上，必须有一个仅自己可见的 “隐藏” VIP。在网络中，真实的 VIP 绑定在负载均衡器上，用来接收客户端的真实请求数据包。而 “隐藏” 的 VIP 绑定在真实服务器的 lo 接口上，用来欺骗自己可以正常接收目标地址是 VIP 的数据包。所以真实服务器和负载均衡器必须在同一局域网中。
• TUN 模式，是对 DR 模式的一种演进。突破 DR 模式中真实服务器和负载均衡器必须在同一局域网中的限制。TUN 模式不会对源数据包进行修改，而是在源数据包上额外新增一条 IP 首部信息，所以不能对端口映射，且要求真实服务器必须能够卸载掉两层 IP 首部信息。

回顾之前的小思考题： 为什么在说真实服务器能够正常接收负载均衡器转发的数据包的必要条件时，没有带上 MAC 地址？

在网络通信部分介绍 ARP 协议和下一跳机制时，我们提到数据包在网络中的转发和快递传送中的驿站类似，每一次数据包的发送，会不断地找到 “下一个目的地” 的 MAC 地址。所以，但凡涉及到物理端口的变迁，都涉及到源 MAC 地址的变化，这个变化是 IP 通信的特性，而并不是负载均衡的特点。