|
Hi,
thanks for hint. I did some experiments with:
/proc/sys/net/ipv4/conf/bond0/rp_filter
/proc/sys/net/ipv4/conf/bond0/accept_source_route
/proc/sys/net/ipv4/conf/bond0/log_martians
1) after activating log_martians, nothing is actually logged - so probably the
packets are not considered to be martians (in accordance with RFC 1812 5.3.7)
2) I don't really understand a term "source routed packages" in:
accept_source_route - Should source routed packages be accepted or declined.
The default is dependent on the kernel configuration. It's 'yes' for routers
and 'no' for hosts.
(http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html)
Nevertheless, switching a value of the "accept_source_route" has no impact
to my problem
3) I think, rp_filter is the place that relates to my problem. At
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html is written:
"rp_filter - Integer value determines if a source validation should be made.
1 means yes, 0 means no. Disabled by default, but local/broadcast address
spoofing is always on. If you set this to 1 on a router that is the only
connection for a network to the net, it will prevent spoofing attacks against
your internal networks (external addresses can still be spoofed), without the
need for additional firewall rules."
So, if I understand the text, the "local address" means the address of my
interface => packets with source address the same as the input interface have
are always droped. I just thought, such filtering is performed within the frame
of routing but it seems, it is done at the very beginning of the kernel network
stack. Anyway, changing this value has no impact to my problem.
4) I have made one more test - when I sent the SYN packet from RS1, I changed
it's source address using NAT-postrouting. The packet was normally accepted by
RS1 and processed as expected. So the problem is positively in the source
address.
5) about local routing - I am going to test the model, where clients on RSs
will connect localy. But I don't want to try to reroute VIP (I feel it as very
difficult and gritty, although probably not infeasible). I plan to set VIP
hostname as alias to 127.0.0.1 using /etc/hosts at RSs. We will see ...
If somebody knew more, please write it.
Thanks
-----Original Message-----
From: lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Simon Horman
Sent: Friday, November 06, 2009 1:20 AM
To: Rajmon, Ondřej
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [lvs-users] Real server refuses packets originated from itself and
redirected by LVS
On Thu, Nov 05, 2009 at 05:27:00PM +0100, Ondrej.Rajmon@xxxxxxx wrote:
> Hello,
> maybe my question is generally about a Linux network subsystem but
> nevertheless, it is related to LVS. My systems are RHEL5 and I have
> configured a load balancer-LVS (LB) and 2 real servers (RS1, RS2) with
> Apache. I use DR configuration described in RedHat documentation, so the
> VIP is configured just on LB. The real servers have just their real IPs
> configured and an acceptance of balanced packets is accomplished by an
> iptables rule with target REDIRECT:
>
> iptables -t nat -A PREROUTING -p tcp -d <VIP> --dport 80 -j REDIRECT
>
> When connecting clients are external hosts, it works well. But when the
> client is on one of that real servers, it works just partialy. For example:
>
> - a client on RS1 connects to VIP -> LB redirects it to RS2 => it
> works fine
>
> - a client on RS1 connects to VIP -> LB redirects it to RS1 => it
> doesn't work
>
> When RS1 connects to itself thru VIP, TCP connection is not established.
> Using tcpdump I can see that the SYN packet leaves an RS1's interface and
> immediately arrives back as it's redirected by LB. So it looks well and
> correctly. But when watching NAT-prerouting table, the packet doesn't
> appear there. It seems as the packet get lost somewhere between an input
> interface and the prerouting hook. I don't understand ... Can anybody
> explain that behaviour?
>
> I know this is not the standard usage of the LVS and I have read HOWTO -
> LVS clients on Realservers. But the HOWTO discusses different model,
> where real servers have configured VIP on there interfaces so the solved
> problems are different. What I want is to understand what happens in the
> system.
Hi,
as I understand it generally real-servers connecting to a LVS-DR
virtual-services of which it is a member is thought to not work.
Though your approach of using iptables does seem to get quite
close to something that works. I wonder if the problem that you are
seeing is that the real-server is rejecting the packet received from
the director as a martian (that is, a packet from itself). There
are some martian controls in /proc, perhaps you could experiment with
these?
I also wonder if a different approach could work. Assuming that
the connection from the real-server doesn't need to be load-balanced,
I wonder if an iptables rule could be constructed such that
the real-server just directly connects to itself when accessing the VIP.
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
