lvs-dr集群之vip与dip/rip不在同一网段的实验环境设计及配置实现

前言

在学习了lvs集群后，看到lvs-dr集群能够实现vip与dip/rip不在同一网段的模式部署，为了加深对lvs的理解，因此尝试设计实现了一下。在设计配置前，我在网上找了很很多资料，也尝试过按照相应的资料来部署验证，但是最终结果还是无法验证成功。后来我参考网络上的资料，按照自己的思路调整了下拓扑，就成功把结果验证出来了。

工作原理

在修改后的拓扑中，lvs-dr的数据流向大致为如下：客户端请求VIP，router会将请求转发给director。为了保证第一个接受请求报文的是director，需要在Real Server上修改Arp响应的机制，确保网络中只有director会响应VIP的arp请求。随后当director检查请求报文，发现其请求的是一组集群服务的时候，其会根据ipvsadm设置的调度算法将请求转发给Real Server。此过程中，director不会更改数据报文中的IP地址信息，仅仅修改报文中的源目mac信息。当请求报文根据director修改的源目mac信息到达Real Server后，Real Server会对请求报文进行响应。此时Real Server 发送源地址为VIP，目标地址为client Ip，源mac为Real Server 的mac地址，目标地址为client或网关的mac地址的响应报文。最后路由器将接受到的响应报文转发给client终端，完成通信。

实际上中，在发起请求报文之前，还需要进行三次握手的协商，如下面抓包的前三条记录，到了第四条记录才是真正的数据传输。

[root@client ~]# tcpdump -i eno16777736 -nn -e port 80
13:22:28.360656 00:0c:29:6d:1a:7d > 00:0c:29:21:59:d7, ethertype IPv4 (0x0800), length 74: 188.88.88.10.49672 > 172.16.0.8.80: Flags [S], seq 448411585, win 29200, options [mss 1460,sackOK,TS val 22310691 ecr 0,nop,wscale 7], length 0
13:22:28.364284 00:0c:29:21:59:d7 > 00:0c:29:6d:1a:7d, ethertype IPv4 (0x0800), length 74: 172.16.0.8.80 > 188.88.88.10.49672: Flags [S.], seq 3569473399, ack 448411586, win 28960, options [mss 1460,sackOK,TS val 13371774 ecr 22310691,nop,wscale 7], length 0
13:22:28.364346 00:0c:29:6d:1a:7d > 00:0c:29:21:59:d7, ethertype IPv4 (0x0800), length 66: 188.88.88.10.49672 > 172.16.0.8.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 22310696 ecr 13371774], length 0
13:22:28.365675 00:0c:29:6d:1a:7d > 00:0c:29:21:59:d7, ethertype IPv4 (0x0800), length 140: 188.88.88.10.49672 > 172.16.0.8.80: Flags [P.], seq 1:75, ack 1, win 229, options [nop,nop,TS val 22310697 ecr 13371774], length 74
13:22:28.367973 00:0c:29:21:59:d7 > 00:0c:29:6d:1a:7d, ethertype IPv4 (0x0800), length 66: 172.16.0.8.80 > 188.88.88.10.49672: Flags [.], ack 75, win 227, options [nop,nop,TS val 13371778 ecr 22310697], length 0
13:22:28.369291 00:0c:29:21:59:d7 > 00:0c:29:6d:1a:7d, ethertype IPv4 (0x0800), length 340: 172.16.0.8.80 > 188.88.88.10.49672: Flags [P.], seq 1:275, ack 75, win 227, options [nop,nop,TS val 13371780 ecr 22310697], length 274
13:22:28.369309 00:0c:29:6d:1a:7d > 00:0c:29:21:59:d7, ethertype IPv4 (0x0800), length 66: 188.88.88.10.49672 > 172.16.0.8.80: Flags [.], ack 275, win 237, options [nop,nop,TS val 22310701 ecr 13371780], length 0
13:22:28.369757 00:0c:29:6d:1a:7d > 00:0c:29:21:59:d7, ethertype IPv4 (0x0800), length 66: 188.88.88.10.49672 > 172.16.0.8.80: Flags [F.], seq 75, ack 275, win 237, options [nop,nop,TS val 22310701 ecr 13371780], length 0
13:22:28.371169 00:0c:29:21:59:d7 > 00:0c:29:6d:1a:7d, ethertype IPv4 (0x0800), length 66: 172.16.0.8.80 > 188.88.88.10.49672: Flags [F.], seq 275, ack 76, win 227, options [nop,nop,TS val 13371782 ecr 22310701], length 0
13:22:28.371185 00:0c:29:6d:1a:7d > 00:0c:29:21:59:d7, ethertype IPv4 (0x0800), length 66: 188.88.88.10.49672 > 172.16.0.8.80: Flags [.], ack 276, win 237, options [nop,nop,TS val 22310703 ecr 13371782], length 0

而在拓扑图a中，我在client抓包中发现，客户端并没有跟请求的server 三次握手协商成功，如下所示：

[root@client ~]# tcpdump -i