在 2014-4-30，19:56，Anders Henke <anders.he...@1und1.de> 写道：
> There are multiple issues with this.
> -IP-address changes
> -possible port changes
>
>
> The client initiates a connection from Client-IP A to Director-VIP B:
>
> A->B, using a random source port number to destination port 80.
>
> The director rewrites the IP packet as if it had been sent
> from Client A to Realserver C and sends it to the realserver:
> A->C, using the client's source port number to destination port 80.
>
> If the realserver would reply to those director-NATed packet,
> the reply would look like this:
>
> C->A, from port 80 to client's source port
At this time,if C could reply directly to A
,not through director ,then what is the result?
After I configure well Lvs in NAT mode,
I find it deal with client's request so slowly, can not find the reason.
> The client in turn knows it did create a connection from A to B,
> but doesn't know about a connection from A to C and so can't
> match those reply packets with "the other" connection. Well,
> their destination port is known to be in use with a different connection,
> so why should A assume this to be valid?
>
> The reply packets are being dropped as being invalid.
>
>
>
> Depending on your configuration, your director may also change
> the destination port, e.g. from 80 to 8080:
> A->C, using the client's source port number to destination port 8080
>
> ... and so the realserver's reply would look like this:
>
> C->A, from port 8080 to client's source port
>
> The client in turn knows it did create a connection from A to B.
> Any replies from C won't match that connection and so are being dropped.
> Neither IP address nor port number do even closely match a known connection,
> there's no way for the client to match them.
>
> In both cases, any firewall protecting A will perform similar
> checks and drop the reply packets, as they are not related to a known
> outgoing connection.
>
> By routing and "un-NAT'ing" the reply packet via the director, the
> director will rewrite the packet from 'C->A' to 'B->A' and rewrite
> any port changes as well to meet the expectations of A (or any
> firewall in between director and A).
>
>
> In Direct Routing mode, the IP packet isn't changed at all, just
> the ethernet destination MAC address ("outside" of the IP packet)
> is changed. In Tunneling mode, the incoming IP packet is encapsulated and
> isn't changed as well.
>
> That's why in Direct Routing and Tunneling mode, any replies will be sent
> bypassing your director and your director will only see "incoming" packets.
>
> And that's also the reason why in NAT mode, both incoming and outgoing
> bandwith are limited by the director, while in DR/TUN mode, the director
> only limits the incoming bandwith. Beside this, the extra complexity of
> performing NAT for incoming and outgoing packets does also affect the
> overall performance of the director.
>
>
> Best,
>
> Anders
>
>
>
> On 30.04.2014, net.study....@gmail.com wrote:
>> The real server received packet's source ip is client ip , why not it reply
>> directly to client if there is router available route?
>>
>> 在 2014-4-29，22:43，Anders Henke <anders.he...@1und1.de> 写道：
>>
>>> On 29.04.2014, net.study....@gmail.com wrote:
>>>> In nat mode,does director do dnat and snat packets for all request packets?
>>>
>>> In NAT mode, the director does perform destination nat on request packets,
>>> so your realserver does still see the correct "source" ip address.
>>>
>>> However, replies then need to be sent via the director as well, so the
>>> director can reverse the changed destination IP address and the client
>>> does see the reply packet from the "expected" IP address/port.
> --
> 1&1 Internet AG Expert Systems Architect (IT Operations)
> Brauerstrasse 50 v://49.721.91374.0
> D-76135 Karlsruhe f://49.721.91374.225
>
> Amtsgericht Montabaur HRB 6484
> Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann,
> Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek,
> Jan Oetjen, Christian Würst
> Aufsichtsratsvorsitzender: Michael Scheeren
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org
Send requests to lvs-users-requ...@linuxvirtualserver.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
