VMware Virtual machine configuration Lvs/nat mode encounters a pit.

These two days in the study of the load balance of LVS, first start with the simplest Lvs/nat mode.

After the final configuration, you can ping each other and have direct access to the Web services provided by the real server, and the firewall is turned off.

But through the access to the LVS server can not access the real server, the use of tcpdump and iftop monitoring software to see a bit, found the handshake problem!

Let's talk about some configuration information for testing the Lvs/nat mode.

Verified PC's Network:

Extranet IP:xxx.xxx.xxx.xxx This is a public IP that the operator dynamically assigns to me.

Intranet ip:192.168.123.1 Use Windows's [local link/broadband connection] to share the Internet access to this virtual router so that the virtual machine can access the Internet.

Intranet ip:192.168.100.1

[Virtual machine] LVS Server:

Extranet IP, vip:192.168.123.100

Intranet IP, dip:192.168.100.10

[Virtual machine] Real server:

External network ip:192.168.123.101

Intranet ip:192.168.100.11 Gateway 192.168.100.10

First of all, why would I want to do this? The reason for this configuration, the new CentOS 7 installed with the virtual machine, because the direct use of the virtual machine is not convenient, I need to copy and so on some features, So that 192.168.123.x network segment is to allow my Windows SecureCRT software to establish SSH link through fixed IP, so that I can easily configure the virtual machine above the Linux server, so I configured for two servers a 192.168.123.X of ground Access.

Well, one of the ideal processes should be this:

Client access [192.168.123.100], LVS server forwarding [192.168.100.11], Real server return [192.168.100.10], LVS server return [192.168.123.1]- > Client.

But the pit appears, we know that the Lvs/nat mode itself requires a real server to do some configuration, is the above 192.168.100.X network segment, to the real server this gateway address set to LVS dip. The real server can then send things to the LVS server, and the LVS server will be able to continue forwarding back to the client.

In Lvs/nat mode, the LVS itself does not modify the source address of the package, because the real server needs the IP address of each client, so naturally it cannot be modified.

Well, with the above understanding, I believe you should guess the problem is that the real server itself has 192.168.123.123 IP address. So the data that has been processed is sent directly to the 192.168.123.1! As follows:

Client access [192.168.123.100], LVS server forwarding [192.168.100.11]- Real server return [192.168.123.1] -Client does not recognize this return.

The solution is to switch off the 192.168.123.101 network card on the real server, and the real server will send the packet to 192.168.100.10, which is the gateway address we set.

In fact, this problem is that the routing configuration is not in place, using the default route may be the case!

All kinds of coincidence [just I need to control the virtual machine through SSH, just as I have configured the external network IP for each virtual server, just this IP in the same network segment], resulting in this big pit!

VMware Virtual machine configuration Lvs/nat mode encounters a pit.