LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS-NAT: configure emergency http server on director

To: Joseph Mack <mack.joseph@xxxxxxx>
Subject: Re: LVS-NAT: configure emergency http server on director
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, Roberto Nibali <ratz@xxxxxx>, Alois Treindl <alois@xxxxxxxx>, Joseph Mack <mack.joseph@xxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Mon, 4 Jun 2001 14:52:12 +0300 (EEST)
        Hello,

On Mon, 4 Jun 2001, Joseph Mack wrote:

> > Alois Treindl wrote:
> >
> > > Yes, but the should come back to the client as if coming from VIP:80,
> > > my question is: who takes care of the remapping of the ports?
>
> Does anyone know how the packets get back?
>
> If I have 2 boxes (not part of an LVS) and on the server box
> I run
>
> $ipchains -A input -j REDIRECT telnet serverIP 81 -p tcp
>
> then I can telnet to port 81 on the server box and have a normal
> telnet session.
>
> I thought with REDIRECT that the packet with dest-port=81
> was delivered to the listener on serverIP:telnet. How does the
> telnetd know to return a packet with source-port=telnet?

        This is handled from the protocol, TCP in this case:

        grep redirport net/ipv4/*.c

        The higher layer (telnet in this case) can obtain the two dest
addr/ports by using getsockname(). In 2.4 this is handled additionally
by using getsockopt(...SO_ORIGINAL_DST...)

        The netfilter mailing list contains examples on this issue.
You can search for "getsockname":

http://marc.theaimsgroup.com/?l=netfilter&r=1&w=2

> I watched with tcpdump on the server here and all I see is a normal
> exchange of packets with dest-port=81
>
> Joe
>
> --
> Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
> contractor to the National Environmental Supercomputer Center,
> mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA


Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>