LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: ip_masq_ftp nat passive

To: Jeremy Kusnetz <JKusnetz@xxxxxxxx>
Subject: Re: ip_masq_ftp nat passive
Cc: "'lvs-users@xxxxxxxxxxxxxxxxxxxxxx'" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Thu, 24 May 2001 01:48:22 +0000 (GMT)
        Hello,

On Wed, 23 May 2001, Jeremy Kusnetz wrote:

> Here are the IP chains I'm setting up:
>
> echo "1" > /proc/sys/net/ipv4/ip_forward
> ipchains -F
> ipchains -A forward -j MASQ -s 10.75.0.0/16 -d 0.0.0.0/0

        right

> I tried setting up ipchains like your script does, but I got connection
> refused errors when trying to ftp, so I put it back the way I originally had
> it.  I tried this:
>
> ipchains -A forward -p tcp -j MASQ -s 10.75.0.9 ftp -d 0.0.0.0/0
> ipchains -A forward -p tcp -j MASQ -s 10.75.32.9 ftp -d 0.0.0.0/0
> ipchains -A forward -p tcp -j MASQ -s 10.75.64.9 ftp -d 0.0.0.0/0

        wrong

> Can I do a global like I have above, or do I have to do each service for
> each realserver?  If so, what is wrong with the above?

        global




        OK, follow the mini-troubleshooting-check-it-yourself Layer
4 NAT HOWTO:

Q.1 Can the real server ping client?

        rs# ping -n client

A.1 Yes => good
A.2 No => bad

        ipchains -A forward -s RIP -j MASQ


Q.2 Traceroute to client goes through LVS box and reaches the client?

        traceroute -n -s RIP CLIENT_IP

A.1 Yes => good
A.2 No => bad

        same ipchains command as in Q.1


Q.3 Is the traffic forwarded from the LVS box, in both directions?

        For all interfaces on director:
        tcpdump -ln host CLIENT_IP

        The right sequence, i.e. the IP addresses and ports on each
        step (the reversed for the in->out direction are not shown):

        CLIENT
           | CIP:CPORT -> VIP:VPORT
           |            ||
           |            \/
 out       | CIP:CPORT -> VIP:VPORT
 ||     LVS box
 \/        | CIP:CPORT -> RIP:RPORT
 in        |            ||
           |            \/
           | CIP:CPORT -> RIP:RPORT
           +
        REAL SERVER

A.1 Yes, in both directions => good (for Layer 4, probably not for L7)
A.2 The packets from the real server are dropped => bad:

        - rp_filter protection on the incoming interface, probably
        hit from local client
        - firewall rules drop the replies

A.3 The packets from the real servers leave the director unchanged

        - missing -j MASQ ipchains rule in the LVS box

A.4 All packets from the client are dropped

        - the requests are received on wrong interface with rp_filter
        protection
        - firewall rules drop the requests

A.5 The client connections are refused or are served from service
in the LVS box

        - client and LVS are on same host => not valid
        - the packets are not marked from the firewall and don't hit
        firewall mark based virtual service

Q.4 Is the traffic replied from the real server?

        For the outgoing interface on real server:

        tcpdump -ln host CLIENT_IP

A.1 Yes, SYN+ACK => good
A.2 TCP RST => bad, No listening real service
A.3 ICMP message => bad, Blocked from Firewall/No listening service
A.4 The same request packet leaves the real server => missing accept
        rules or RIP is not defined
A.5 No reply => real server problem:

        - the rp_filter protection drops the packets
        - the firewall drops the request packets
        - the firewall drops the replies

A.6 Replies goes through another device or don't go to the LVS
box =? bad

        - the route to the client is direct and so don't pass the LVS
        box, for example:

                - client on the LAN
                - client and real server on same host

        - wrong route to the LVS box is used => use another

The result: we need these outputs:

rs# tcpdump -ln host CIP
rs# traceroute -n -s RIP CIP
lvs# tcpdump -ln host CIP
client# tcpdump -ln host CIP


For more deep problems use tcpdump -len, i.e. sometimes the link layer
addresses help a bit.


For FTP:

        LVS-NAT in Linux 2.2 requires:

        - modprobe ip_masq_ftp (before 2.2.19)
        - modprobe ip_masq_ftp in_ports=21 (2.2.19+)

        LVS-NAT in Linux 2.4 requires:

        - ip_vs_ftp

        LVS-DR/TUN require persistent flag


        FTP reports with debug mode enabled are useful:

        # ftp
        ftp> debug
        ftp> open my.virtual.ftp.service
        ftp> ...
        ftp> dir
        ftp> passive
        ftp> dir


Regards

--
Julian Anastasov <ja@xxxxxx>



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