|
> Nathan Polonski wrote:
> >The only way for packets to get from the real-servers to
> >outside is to be de-NAT'ed by the director
> >according to the tables which set up the LVS. Services not under
> >the control of LVS can be routed normally.
>
> So are you saying that when I have this up and running, the IP masquerading
> command,
> "ipchains -A forward -j MASQ -s 192.168.xxx.xxx/24 -d 0.0.0.0"
> will provide the necessary info for de-NAT'ing?
This is the way I setup my VS-NAT till recently and is
OK for a test setup and may even be OK for production.
This will de-NAT (or reverse NAT, no-one has a good name for it yet)
_all_ ports(services) from _all_ real-servers to the outside world,
whether there is a corresponding entry for that service on that
real-server in ipvsadm or not.
If you were LVS'ing ftp and http, then you only need
to de-NAT ftp and http from the real-servers that are running them.
My script (on the LVS website, it doesn't handle director failover)
does the following on the director, making an entry for each real-server
and each service one at at time.
#to handle the services on real-server1
ipchains -A forward -p tcp -j MASQ -s name_real-server1 ftp -d 0.0.0.0/0
ipchains -A forward -p tcp -j MASQ -s name_real-server1 http -d 0.0.0.0/0
#to handle the services on real-server2
#if real-server2 only had ftp then you'd run this line only
ipchains -A forward -p tcp -j MASQ -s name_real-server2 ftp -d 0.0.0.0/0
#but not a line for real-server2 with http.
If you wanted to telnet directly to/from the realservers (independantly
of the LVS) you would be hosed in your case.
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
