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