|
I am attempting to setup LVS using NAT on a linux (kernel 2.2.19) box.
I'm using the ipvs 1.0.8 patch, which applied cleanly, and ipvsadm 1.15
(bundled with the ipvs patch) I believe I've gotten everything required
into the kernel, although perhaps I'm missing something - I found I had
to manually load the modules for load balacing [ip_vs_rr.o]. This is
along with using the configure script and the rc.lvs_nat that it
generated.
I have an idea what ONE of my problems is, but I don't know if it
explains the current block I have or not. Perhaps somebody here would
know...
Basically I am trying to forward telnet on the VIP 192.168.1.19 to the
RIP 192.168.0.23. My ip-chains and ipvsadm outputs are:
-----
[root@lvstest /root]# ipchains-save
:input ACCEPT
:forward ACCEPT
:output ACCEPT
Saving `forward'.
-A forward -s 192.168.0.23/255.255.255.255 23:23 -d 0.0.0.0/0.0.0.0 -p 6 -j MASQ
-A forward -s 192.168.0.23/255.255.255.255 1025:65535 -d 0.0.0.0/0.0.0.0 -p 6
-j MASQ
[root@lvstest /root]# ipvsadm -Ln
IP Virtual Server version 1.0.8 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.19:23 rr
-> 192.168.0.23:23 Masq 1 0 0
-----
I have a CIP 192.168.1.102 from which I am attempting to telnet to the
VIP. It just hangs there, during which time that connection is listed
in the ipchains masq table and the ipvsadm table as an inactive
connection. (or by the time I find it, anyway):
-----
IP Virtual Server version 1.0.8 (size=4096)
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.19:23 rr
-> 192.168.0.23:23 Masq 1 0 1
IP masquerading entries
prot expire source destination ports
TCP 00:55.67 192.168.0.23 192.168.1.102 telnet (23) -> 4787
-----
I have telnet wide open on the RIP box, and a netstat on it during this
procedure shows...
-----
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.0.23:23 192.168.0.19:1026 ESTABLISHED
-----
[The DIP is 192.168.0.19.]
The only thing I can think of that might be the problem is that.. The
RIP doesn't have its default GW set to the DIP. This is because the DIP
is just a gateway to another test network, and the RIP still needs to go
through the ordinarily default GW to get to the outside world.
Do the RIPs need their default GW to be the DIP?
Otherwise I'm kinda clueless, but perhaps I am missing something
obvious. I keep going back and forth between the howto, the LVS-NAT
working principle doc and the mini-howto. I'm open to suggestions of
"RTFM", especially if you can help me figure out which section I should
be looking at.
Thanks!
Abbe DeMoss
|
