|
Well, now I am kinda confused, becasue I did what Joe said (thx Joe!!) and
now the thing is working!!??
So, just to clarify, what exaclty is the "masquerading?" (I will RTFM in the
meantime.)
My setup is:
client - 192.168.168.5
director - 192.168.168.2
real - 192.168.168.3
I did as described by joe's e-mail and my previous postings, and this works,
i.e., when I browse to 192.168.168.2, I get the 192.168.168.3 website. If I
try to browse 192.168.168.3 directly, it hangs.
Perhaps I misunderstood - Please clarify.
Ivan
----- Original Message -----
From: "Julian Anastasov" <ja@xxxxxx>
To: "Joseph Mack" <mack@xxxxxxxxxxx>
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, January 18, 2001 5:46 PM
Subject: Re: Setting up a one network VS-NAT LVS
>
> Hello,
>
> On Thu, 18 Jan 2001, Joseph Mack wrote:
>
> > >From the next version of the HOWTO. Comments gladly accepted.
> >
> > Joe
> >
> > 7.1.2 One network VS-NAT
> >
> > The disadvantage of the 2 network VS-NAT is that the real-servers
> > are not able to connect to machines in the network of the VIP.
> > You couldn't make a VS-NAT setup out of machines already on
> > your LAN, which were also required for other purposes to stay
> > on the LAN network.
> >
> > Here's a 1 network VS-NAT LVS.
> > ________
> > | |
> > | client |
> > |________|
> > CIP=192.168.1.254
> > |
> > (router)
> > |
> > __________ |
> > | | | VIP=192.168.1.110 (eth0:110)
> > | director |---| DIP=192.168.1.1 (eth0)
> > |__________| | DIIP=192.168.1.9 (eth0:9)
> > |
> > |
> > ------------------------------------
> > | | |
> > | | |
> > RIP1=192.168.1.2 RIP2=192.168.1.3 RIP3=10.1.1.4 (all eth0)
> > _____________ _____________ _____________
> > | | | | | |
> > | real-server | | real-server | | real-server |
> > |_____________| |_____________| |_____________|
> >
>
> Joe, the setup with two different logical networks can work
> but when the client and the real server share same logical network
> the masquerading can't work.
>
> Here is a setup that I assume will work:
>
> 192.168.1.1 (DIP)
> 192.168.1.110 (VIP)
> 10.0.0.1 (DIP)
> Client 192.168.1.254 Director 10.0.0.2
> | | Real server
> One physical ---+-----------------------+-------------------+--- ...
> network, aka LAN
> Can be provided
> from switched
> or shared hub
>
>
> So, we have two logical networks: 192.168.1.0/24 and 10.0.0.0/24
> but over one physical connection (shared media).
>
> All NAT rules apply:
>
> - 10.0.0.1 is def gw in real server 10.0.0.2
> - both ends connect through the director
> - send_redirects are stopped in the director, so the client and the
> real server don't receive ICMP redirects and they both don't detect
> that they share same physical network.
>
> > realserver:/etc/lvs# netstat -r
> > Kernel IP routing table
> > Destination Gateway Genmask Flags MSS Window irtt
Iface
> > 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
> > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0
lo
> > 0.0.0.0 director 0.0.0.0 UG 0 0 0
eth0
> >
> > Note the route to 192.168.1.0/24. This allows the real-server to send
packets
> > to the client by just putting them out on eth0, where the client will
> > pick them up directly (without being demasqueraded) and the LVS will
> > not work.
>
> Yes, this is a direct connection. One of the both ends (the
> real server) connects directly to the client and the packets reach
> the client unmasqueraded avoiding the translation in the director.
>
> > Remove the route to 192.168.1.0/24.
> >
> > realserver:/etc/lvs#route del -net 192.168.1.0 netmask 255.255.255.0 dev
eth0
> >
> > This will leave you with
> >
> > realserver:/etc/lvs# netstat -r
> > Kernel IP routing table
> > Destination Gateway Genmask Flags MSS Window irtt
Iface
> > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0
lo
> > 0.0.0.0 director 0.0.0.0 UG 0 0 0
eth0
>
> Wow, if you don't have RIP how the LVS traffic is working :)
>
> >
> > The VS-NAT LVS now works. If LVS is forwarding telnet, you can
> > telnet from the client to the VIP and connect to the real-server.
>
> May be to another real server with RIP configured ?
>
> > You can ping from the client to the real-server.
> >
> > You can also connect _directly_ to services on the real-server not
> > being forwarded by LVS (in this case e.g. ftp).
>
> To which IP ? Hm, are the packets really accepted from the
> real server?
>
> >
> > You can no longer connect directly to the real-server for services
> > being forwarded by the LVS. Here telnet ports are not being rewritten
> > by the LVS (ie telnet->telnet).
> >
> > client:~# telnet realserver
> > Trying 192.168.1.11...
> > ^C
> >
> > (i.e. connection hangs)
>
> The theory is true here. What can happen is that when a packet
> reaches the real server and there is no RIP in the real server, the
> packet will be forwarded to the next hop: the director because it is
> a default gateway. May be the packet will loop until the IP TTL is
> expired or may be it will be dropped. But soon after the ARP entry in
> the director's cache is invalidated the traffic from LVS to the
> director will stop.
>
> >
> > Here's tcpdump on the director (which can see all packets).
> > The client initiates telnet. `netstat -a` on the client
> > shows a SYN_SENT from port 4121.
> >
> > director:/etc/lvs# tcpdump
> > tcpdump: listening on eth0
> > 16:37:04.655036 realserver.telnet > client.4121: S
354934654:354934654(0) ack 1183118745 win 32120 <mss 1460,sackOK,timestamp
111425176[|tcp]> (DF)
> > 16:37:04.655284 director > realserver: icmp: client tcp port 4 121
unreachable [tos 0xc0]
> >
> > (repeats every second until I kill telnet on client)
> >
> > I don't know why I don't see the connect request from
client->real-server.
>
> Because the director redirects the client via ICMP redirect
> directly to the real server. The real servers sends SYN+ACK through the
> director (showed in the tcpdump output) to the client. But the director
> does not have such connection entry (the initail SYN skipped the director
> after the ICMP redirect) and replies with PORT_UNREACH to the real
> server. This terminates the handshake in the real server.
>
> I assume the tcpdump will show ICMP redirects from the director
> to the client: "go to the real server directly". Are there such redirects?
>
> > The first packet I see is the ack from the real-server,
> > which will be forwarded via the director.
> > The director will rewrite the ack to be from the director.
>
> But there is no such LVS entry, PORT_UNREACH is replied.
>
> Joe, can you perform tests with two different Class C networks: one
> for the client, the external DIP and the VIP and one "internal" network
> for the NAT-ed real servers and the internal director DIP used as def
> gw in the real servers. Something like the above picture, with
> send_redirects=0. I assume this should work without any problems.
>
>
> Regards
>
> --
> Julian Anastasov <ja@xxxxxx>
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
