LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Connection synchronization questions

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: Connection synchronization questions
Cc: Martijn@xxxxxxxxxxxxxxxxx
Cc: "Grendelman <martijn"@grendelman.net
From: Horms <horms@xxxxxxxxxxxx>
Date: Fri, 25 Aug 2006 17:40:39 +0900 (JST)
On Wed, 19 Jul 2006 16:33:20 +0200, Martijn Grendelman wrote:
> Hi,
> 
> I have just enabled the LVS connection sync daemon, but some things 
> about the way it works aren't entirely clear to me.
> 
> There is an active LVS, running ipvs_syncmaster and a backup LVS, 
> running ipvs_syncbackup. I feel I should mention the machines run pretty 
> old kernels (2.4-not-latest). I use the local node feature, i.e. both 
> machines are also real servers.
> 
> On both machines, I see the UDP multicast traffic I expect:
> 
> 16:19:16.876496 IP tweety.sipo.nl.55286 > 224.0.0.81.8848: UDP, length: 28
> 16:19:25.875012 IP tweety.sipo.nl.55286 > 224.0.0.81.8848: UDP, length: 28
> 
> (tweety.sipo.nl being the master).
> 
> Now, knowing nothing about multicast in general, my question is: what 
> are the security implications of this kind of traffic? The servers are 
> on a shared switch. Are other machines on the LAN able to pick up any 
> sensitive data from my load balancers? How could I secure this?

The data is completely unsecured. Anyone who joins the multicast
group (opens a socket) can get the packets. Though they probably
aren't that interesting. What is intersting is that they can also
inject packets, to say flood the connection table with entries.
I've never crafted an attack, but I'm pretty sure the scope is ample.

I worked on some code a few years ago to move part of the
synchronisation into user-space, and secure it using a signature
and a shared secret. Now that crypto-api is in the kernel (and has
been for years) it should be easy enough to move this code into
the kernel, which is a less invasive change.

I wonder if there is any interest in this, as there certainly
wasn't when I worked on it before.

> And I have another question.
> 
> On the master, I see this:
> 
> martijn@tweety:~> rr ipvsadm -L -n
> IP Virtual Server version 1.0.10 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
>   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
> TCP  212.204.230.98:80 sh
>   -> 212.204.230.91:80            Route   200    10         19
>   -> 212.204.230.96:80            Local   200    3          18
> 
> On the backup LVS, I see:
> 
> martijn@daffy:~> rr ipvsadm -L -n
> IP Virtual Server version 1.0.12 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
>   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
> TCP  212.204.230.98:80 sh
>   -> 212.204.230.91:80            Local   200    10         16
>   -> 212.204.230.96:80            Route   200    0          0
> 
> The number of active connections pointing to the second server (which is 
> the active LVS) is 0 on the backup machine. I would expect it to be 3, 
> just like on the master.
> 
> Does that have something to do with the fact that Forward == Local? Or 
> is there something I am missing?
> 
> And what about the number of inactive connections on the backup? I 
> thought only ESTABLISHED connections are synchronized. When does a 
> connection become 'inactive' on the backup? When it is no longer active 
> on the master?

I don't think that the counters are updated to take into account
synchronised connections. Which kind of makes things less
confusing in some way. Try looking at ipvsadm -Lcn to see the
synchronised connection entries.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Connection synchronization questions, Horms <=