Does LVS NAT require load balancing with Iptables's Snat

Map First:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/71/63/wKioL1XNqkfRseXAAADBVngbyOg956.jpg "title=" Qq20150814163456.jpg "alt=" Wkiol1xnqkfrsexaaadbvngbyog956.jpg "/>

The Cisco router that this diagram is using. The fact is that you don't have to do snat.

However, LVs NAT is similar to this model, some people say that LVs NAT is a group of Dnat, and now I'm going to confirm

Does LVS need to open iptables Snat to help realserver convert the packets.

or LVS itself to transform the packet structure.

What you need to experiment:

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/71/66/wKiom1XNnm-z7HL8AACf9X1U3ZA388.jpg "title=" LVs Nat.jpg "alt=" Wkiom1xnnm-z7hl8aacf9x1u3za388.jpg "/>

Key items of LVS configuration I posted it, I used the keepalived configuration, easy to write and can host the survival monitoring

[[email protected] ~]# cat /proc/sys/net/ipv4/ip_forward 1[[email protected]  ~]# getenforce Disabled#keepalived  configuration [[email protected] ~]# cat /etc/ keepalived/keepalived.conf global_defs {   notification_email {      [email protected]   }   notification_email_from [ email protected]   router_id lvs_devel}vrrp_instance vi_1 {     state master    interface eth1    virtual_router _id 51    priority 100    advert_int 1     authentication {        auth_type PASS         auth_pass 1111    }     virtual_ipaddress {         192.168.2.180    }}virtual_server 192.168.2.180  80 {    delay_loop 6    lb_algo rr     lb_kind NAT    nat_mask 255.255.255.0     persistence_timeout 5    protocol tcp    real_server  192.168.156.128 80 {       weight 1        TCP_CHECK {              connect_timeout 3            nb_get_ Retry 3            delay_before_retry 3             connect_port 80         }    }    real_server 192.168.156.130 80 {        weight 10       TCP_CHECK {               connect_timeout 3             nb_get_retry 3             delay_before_retry 3             connect_port 80        }     }}

The above configuration is simple and the following is the beginning of validation.

First step: Close the default route in Web1 web2.

[Email protected] ~]# route Kernel IP routing tabledestination Gateway genmask Flags Metric Ref Us E Iface192.168.156.0 * 255.255.255.0 U 0 0 0 eth0link-local * 255.255 .0.0 U 1002 0 0 eth0

The iptable rule of the LVS host is set to empty (that is, do not turn on snat) or turn off iptables.

Accessing http://192.168.2.180 in a browser

will appear to have stuck where the card is not moving, we view

[Email protected] ~]# Ipvsadm-lncipvs connection Entriespro expire state source Virtual des Tinationtcp 00:55 syn_recv 192.168.2.18:57706 192.168.2.180:80 192.168.156.128:80tcp 00:52 NONE 192.168.2.18     : 0 192.168.2.180:80 192.168.156.128:80tcp 00:55 syn_recv 192.168.2.18:57707 192.168.2.180:80 192.168.156.128:80

Understanding the TCP three handshake of the classmates know that this is in the recv stage, is destination no reply, so in this state.

Let's analyze the flow of data packets.

PC 192.168.2.18

LVS 192.168.2.182 VIP 192.168.2.180

Realserver 192.168.156.128

Packet Start is sip:192.168.2.18 dip:192.168.2.180

Arrives LVs, LVs discovers is the VIP of the request, then converts the packet to sip:192.168.2.18 according to the rule dip:192.168.156.128

The readserver then receives the packet solution encapsulation. The final processing is completed and the package is sent back again, when the packet structure is sip:192.168.156.128 dip:192.168.2.18. Here's the problem, our routing table (see route above), The table entry does not have a route to the 192.168.2.0 network segment, when the packet is published and discarded directly. So there was syn_recv.

So if we can send this package to LVS, can we access it normally? below to verify

The second step: Open the default route in Web 1 web2, the route default gateway points to the LVS intranet port 192.168.156.148;

Note that the LVS still does not open iptables Snat

[[email protected] ~]# route kernel ip routing tabledestination      Gateway         Genmask          flags metric ref    use iface192.168.156.0    *                255.255.255.0   u     0      0         0 eth0link-local      *                255.255.0.0      U     1002   0         0 eth0default         192.168.156.148  0.0.0.0         ug    0      0         0 eth0

This time, or the above process to realserver back to the packet, sip:192.168.156.128 dip:192.168.2.18

At this point the routing table entry has a default route, and the packet is dropped directly to 192.168.156.148 (LVS).

Accessing http://192.168.2.180 in a browser

found that the site can now be visited normally.

In Web1 grab packet analysis, see the packet

15:27:31.154624 ip 192.168.2.18.56784 > 192.168.156.128.http: flags [.],  ack 1, win 16425, length 015:27:31.156401 IP 192.168.2.18.56784  > 192.168.156.128.http: Flags [P.], seq 1:458, ack 1, win  16425, length 45715:27:31.156478 ip 192.168.156.128.http > 192.168.2.18.56784 : flags [.], ack 458, win 490, length 015:27:31.157290 ip  192.168.156.128.http > 192.168.2.18.56784: flags [p.], seq 1:149, ack  458, win 490, length 14815:27:31.157415 IP 192.168.156.128.http >  192.168.2.18.56784: Flags [F.], seq 149, ack 458, win 490,  Length 015:27:31.157832 ip 192.168.2.18.56784 > 192.168.156.128.http: flags  [.], ack 150, win 16388, length 015:27:31.158295 ip 192.168.2.18.56784 >  192.168.156.128.http: flags [f.], seq 458, ack 150, win 16388,  Length 015:27:31.158311 ip 192.168.156.128.http > 192.168.2.18.56784: flags  [.], ack 459, win 490, length 0

The entire packet flow should be:

The packet begins with the sip:192.168.2.18 dip:192.168.2.180 arrives at the LVs, and LVs discovers the VIP that is requested, then converts the packet to a sip:192.168.2.18 dip according to the rules : 192.168.156.128 then Readserver received packet solution encapsulation. The final processing is completed and the package is sent back again, and the packet structure is sip:192.168.156.128 dip:192.168.2.18. Data packet to LVS after LVS to change data repair to sip:192.168.2.180 dip:192.168.2.18 at this time the customer opportunity to accept the packet. Because the request packet IP is right.

But at this time LVs did not open snat, that is, the conversion of the packet, do not need to rely on iptables, but the LVs themselves to complete. Similar to multiple groups of Dnat.

Personal Summary: Many of the forum's information are personal views, lack of rigor. Cisco and Linux are many things that are interlinked.

This article is from the "[email protected]" blog, please be sure to keep this source http://ribble.blog.51cto.com/3863110/1684677

Does LVS NAT require load balancing with Iptables's Snat