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