|
Hello,
According to LVS how-to, chapter 17.2, the path of an incoming packet
should be:
PREROUTING -> LOCAL_IN -> POSTROUTING
But from what I can see, the path is more like
PREROUTING -> LOCAL_IN -> LOCAL_OUT -> POSTROUTING
I think the documentation is correct, but I would need to check the code
first.
The context;
The director is connected on the LAN, 10.64.0.0/24, on its eth1 interface.
Behind it, the real servers are on 192.168.76.2 on a 802.1q tagged
vlan 3 and connected to the redirector on its eth0.3 interface.
So we have 10.64.0.0/24--->(VIP)eth1|LVS|eth0(DIP)--->192.168.76.0/24
10.64.0.16 is configured as an alias on the eth1 interface of the
redirector, and the ssh port of this address is redirected to the ssh port
of 192.168.76.2:
Ipvsadm rules:
-A -t 10.64.0.16:ssh -s rr
-a -t 10.64.0.16:ssh -r 192.168.76.2:ssh -m -w 1
Ok.
Iptables rules:
Default policy fro all chains: ACCEPT
For all tables? How do you have LVS-NAT working then?
-A INPUT -d 10.64.0.16 -i eth1 -j LOG --log-prefix "INPUT ipvsadm
" --log-level 6
-A OUTPUT -o eth0.+ -j LOG --log-prefix "OUTPUT ipvsadm
" --log-level 6
For future make that '... -o eth0 ...' since no interface with the name
eth0.+ exists (yes, I know what regex patterns are). To be completely
sure of how your packets traverse the netfilter stack without reading
the source code, I would add a LOG rule for all chains of the filter and
nat table.
If from the 10.64.0.0/24 lan I ssh to 10.64.0.16 packets go through the
OUTPUT chain as you can see in my log:
OUTPUT ipvsadm IN= OUT=eth0.3 SRC=10.64.0.81 DST=192.168.76.2 LEN=60
TOS=0x00 PREC=0x00 TTL=64 ID=3850 DF PROTO=TCP SPT=49851 DPT=22
WINDOW=5840 RES=0x00 SYN URGP=0
OUTPUT ipvsadm IN= OUT=eth0.3 SRC=10.64.0.81 DST=192.168.76.2 LEN=52
TOS=0x00 PREC=0x00 TTL=64 ID=3851 DF PROTO=TCP SPT=49851 DPT=22
WINDOW=5840 RES=0x00 ACK URGP=0
OUTPUT ipvsadm IN= OUT=eth0.3 SRC=10.64.0.81 DST=192.168.76.2 LEN=52
TOS=0x00 PREC=0x00 TTL=64 ID=3852 DF PROTO=TCP SPT=49851 DPT=22
WINDOW=5840 RES=0x00 ACK URGP=0
Looks rather normal.
If I connect from another lan not directly connected to the director,
the packets go through INPUT and OUTPUT.
INPUT ipvsadm IN=eth1 OUT= MAC=00:0a:5e:3d:82:0f:00:e0:1e:7f:98:61:08:00
SRC=A.B.C.D DST=10.64.0.16 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=55012
DF PROTO=TCP SPT=49852 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
OUTPUT ipvsadm IN= OUT=eth0.3 SRC=A.B.C.D DST=192.168.76.2 LEN=60
TOS=0x00 PREC=0x00 TTL=63 ID=55012 DF PROTO=TCP SPT=49852 DPT=22
WINDOW=5840 RES=0x00 SYN URGP=0
INPUT ipvsadm IN=eth1 OUT= MAC=00:0a:5e:3d:82:0f:00:e0:1e:7f:98:61:08:00
SRC=200.9.208.76 DST=A.B.C.D LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=55013
DF PROTO=TCP SPT=49852 DPT=22 WINDOW=5840 RES=0x00 ACK URGP=0
OUTPUT ipvsadm IN= OUT=eth0.3 SRC=A.B.C.D DST=192.168.76.2 LEN=52
TOS=0x00 PREC=0x00 TTL=63 ID=55013 DF PROTO=TCP SPT=49852 DPT=22
WINDOW=5840 RES=0x00 ACK URGP=0
:) Indeed, confusing. I don't know what's up with your setup but try my
suggestion of adding a LOG statement for those tables and chains and no
IP and try it again. It should be clear.
HTH and best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
| 