Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux Virtual Server: Users

[lvs-users] Real server refuses packets originated from itself and redirected by LVS

 

 

Linux Virtual Server users RSS feed   Index | Next | Previous | View Threaded


Ondrej.Rajmon at cuzk

Nov 5, 2009, 8:27 AM

Post #1 of 6 (247 views)
Permalink
[lvs-users] Real server refuses packets originated from itself and redirected by LVS

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.

More info:

- IP addresses in packet are OK (src=<IP RS1>, dest=<VIP>)

- MAC addr in packet are OK (LB swap src and dest MACs as expected)

- iptables are empty except the NAT-prerouting (VIP=10.1.14.19 , RS1=10.1.14.13)

# iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
LOG tcp -- 10.1.14.13 0.0.0.0/0 LOG flags 0 level 7 prefix `testnat-src'
REDIRECT tcp -- 0.0.0.0/0 10.1.14.19 tcp dpt:80

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination




Ondrej


_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users


horms at verge

Nov 5, 2009, 4:19 PM

Post #2 of 6 (235 views)
Permalink
Re: [lvs-users] Real server refuses packets originated from itself and redirected by LVS [In reply to]

On Thu, Nov 05, 2009 at 05:27:00PM +0100, Ondrej.Rajmon[at]cuzk.cz 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[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users


Ondrej.Rajmon at cuzk

Nov 6, 2009, 2:27 AM

Post #3 of 6 (233 views)
Permalink
Re: [lvs-users] Real server refuses packets originated from itself and redirected by LVS [In reply to]

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[at]linuxvirtualserver.org [mailto:lvs-users-bounces[at]linuxvirtualserver.org] On Behalf Of Simon Horman
Sent: Friday, November 06, 2009 1:20 AM
To: Rajmon, Ondøej
Cc: lvs-users[at]linuxvirtualserver.org
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[at]cuzk.cz 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[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
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[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users


siim at p6drad-teel

Nov 6, 2009, 2:37 AM

Post #4 of 6 (232 views)
Permalink
Re: [lvs-users] Real server refuses packets originated from itself and redirected by LVS [In reply to]

Hi

Ondrej.Rajmon[at]cuzk.cz wrote:
> 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?

Is the rp_filter sysctl on by any chance?

Siim

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users


Ondrej.Rajmon at cuzk

Nov 6, 2009, 2:55 AM

Post #5 of 6 (233 views)
Permalink
Re: [lvs-users] Real server refuses packets originated from itself and redirected by LVS [In reply to]

Yes, right now it is on. But I have tested both states on/off. As I wrote in my last post - as far as I understand http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html , the rp_filter is related to my problem, but don't solve it.

Ondrej

-----Original Message-----
From: lvs-users-bounces[at]linuxvirtualserver.org [mailto:lvs-users-bounces[at]linuxvirtualserver.org] On Behalf Of Siim Poder
Sent: Friday, November 06, 2009 11:37 AM
To: LinuxVirtualServer.org users mailing list.
Subject: Re: [lvs-users] Real server refuses packets originated from itself and redirected by LVS

Hi

Ondrej.Rajmon[at]cuzk.cz wrote:
> 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?

Is the rp_filter sysctl on by any chance?

Siim

_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
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[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users


ct at swin

Nov 8, 2009, 4:54 PM

Post #6 of 6 (211 views)
Permalink
Re: [lvs-users] Real server refuses packets originated from itself and redirected by LVS [In reply to]

On Fri, 6 Nov 2009, Simon Horman wrote:

> 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.


iptables -t nat -I OUTPUT -p tcp -d $VIP --dport 80 -j DNAT --to-destination $IP:80

where $IP = primary IP address of real server


I use LVS-DR with the VIP only configured on the LVS director and iptables
rules on the real servers. The iptables rule above is what I use to allow the
real server to connect 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[at]LinuxVirtualServer.org
Send requests to lvs-users-request[at]LinuxVirtualServer.org
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

Linux Virtual Server users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.