Mailing List Archive

identd on VS-DR
This is an old topic, which has been handled by turning off
identd requests on real-servers. I'm wondering if there might
be a work around.

Explanation of problem:

With a VS-NAT lvs, services running under identd (eg sendmail), or
under tcpwrappers successfully make requests to the LVS client's authd.

There is no solution for VS-DR at the moment. The auth client on
the real-server initiates the connection from the VIP. There is
no way for a packet from VIP:high port to get a reply through the LVS.

1. the incoming packet from the client on the internet is destined for a
non-LVS'ed high port

2. the incoming packet is not a connect request.

3. the incoming packet is not associated with an established connection.

The reply from the LVS client will be dropped.

Attempt at solution:

If the request could come from the RIP on the real-server instead
of the VIP, then the request could be nat'ed out.

Is there any way to make a connect request from VIP:high_port
on the real-server come from RIP:high_port, and for the replies
to RIP:high_port to be changed to VIP:high_port?

Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA
Re: identd on VS-DR [ In reply to ]
Hello,

On Wed, 24 Jan 2001, Joseph Mack wrote:

> This is an old topic, which has been handled by turning off
> identd requests on real-servers. I'm wondering if there might
> be a work around.
>
> Explanation of problem:
>
> With a VS-NAT lvs, services running under identd (eg sendmail), or
> under tcpwrappers successfully make requests to the LVS client's authd.
>
> There is no solution for VS-DR at the moment. The auth client on
> the real-server initiates the connection from the VIP. There is
> no way for a packet from VIP:high port to get a reply through the LVS.
>
> 1. the incoming packet from the client on the internet is destined for a
> non-LVS'ed high port
>
> 2. the incoming packet is not a connect request.
>
> 3. the incoming packet is not associated with an established connection.
>
> The reply from the LVS client will be dropped.
>
> Attempt at solution:
>
> If the request could come from the RIP on the real-server instead
> of the VIP, then the request could be nat'ed out.

For me, the RFC1413 is clear. You can not request information
for another IP address.

3. RESTRICTIONS

Queries are permitted only for fully specified connections. The
query contains the local/foreign port pair -- the local/foreign
address pair used to fully specify the connection is taken from the
local and foreign address of query connection. This means a user on
address A may only query the server on address B about connections
between A and B.

So, we can not query for VIP:VPORT-CIP:CPORT from RIP. I don't
see a solution. The main restriction in the DR/TUN setups where the VIPs
are shared is: only one host can initiate connections with a shared
address - the director in our setup. If the real servers initiate
connections they can autoselect source ports for the IDENT requests
that are busy in the director. May be some form of NAT in the real
server is required that will translate the VIP to some unused valid
RIP2 and will pass the connection to the director for masquerading.
The trick is that only the VIP must be changed to RIP2 but preserving
the port value. It is assumed that there are no ports used for RIP2.
Why we send the request through the director. Because we need a valid
free port for the VIP address and the director is the only authority
for this port.

How to change saddr=VIP to RIP2? May be with netfilter?
May be with dumb nat? We can investigate this if the above idea is
correct.

> Is there any way to make a connect request from VIP:high_port
> on the real-server come from RIP:high_port, and for the replies
> to RIP:high_port to be changed to VIP:high_port?
>
> Joe
> --
> Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
> contractor to the National Environmental Supercomputer Center,
> mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA


Regards

--
Julian Anastasov <ja@ssi.bg>
Re: identd on VS-DR [ In reply to ]
Julian Anastasov wrote:

> So, we can not query for VIP:VPORT-CIP:CPORT from RIP. I don't
> see a solution. The main restriction in the DR/TUN setups where the VIPs
> are shared is: only one host can initiate connections with a shared
> address - the director in our setup. If the real servers initiate
> connections they can autoselect source ports for the IDENT requests
> that are busy in the director. May be some form of NAT in the real
> server is required that will translate the VIP to some unused valid
> RIP2 and will pass the connection to the director for masquerading.
> The trick is that only the VIP must be changed to RIP2 but preserving
> the port value. It is assumed that there are no ports used for RIP2.
> Why we send the request through the director. Because we need a valid
> free port for the VIP address and the director is the only authority
> for this port.
>
> How to change saddr=VIP to RIP2? May be with netfilter?
> May be with dumb nat? We can investigate this if the above idea is
> correct.

Seems OK to me and this is what I was wondering. If you can port forward, it
would
seem possible to IP forward. I don't know how you can NAT within
one box and I don't know how to get netfilter to change packets with
saddr=vip:high_port to rip:high_port for outbound and to do the reverse
for inbound packets.

Joe


--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA