|
ok so let's say we have:
director: 199.199.199.2
vip: 199.199.199.3
real server 1: 199.199.199.4
real server 2: 199.199.199.5
subnetting: normal class C, /24 block, netmask 255.255.255.0
router: 199.199.199.1, no special firewall action going on, etc.
in a case like this, the ipvsadm commands can be specified with -g and
direct routing can be used, as 199.199.199.4 and 199.199.199.5 can send
directly back to some client machine on another network, assuming there
are no other interferences.
but let's say we want the real servers on an internal network, such as:
director: 199.199.199.2 and 199.168.199.1
vip: 199.199.199.3
real server 1: 199.168.199.2 (whatever)
real server 2: 199.168.199.3 (whatever)
subnetting: normal class C, /24 block, netmask 255.255.255.0 (for both
networks)
router: 199.199.199.1, no special firewall action going on, etc.
in a case like this, one would normally think to use nat instead of direct
routing, and the responses from the real servers would go back through the
director again and be translated back to the original source address or
what not, blah blah, standard nat stuff.
my question is: can direct routing be used in a circumstance like this?
say, a separate machine to be the gateway for 199.168.199/24 and forward
packets, or masquerade? something like:
director: 199.199.199.2 (eth0?) and 199.168.199.4 (eth1?) (shrug)
vip: 199.199.199.3
real server 1: 199.168.199.2 (whatever)
real server 2: 199.168.199.3 (whatever)
subnetting: normal class C, /24 block, netmask 255.255.255.0 (for both
networks)
router: 199.199.199.1, no special firewall action going on, etc.
internal network's gateway: 199.168.199.1 (ethX?) and 199.199.199.4 (ethY?)
(shrug)
the director would be setup with ipvsadm -g commands for direct routing,
and the gateway on the real servers would be configured as that "internal
network's gateway", 199.168.199.1, which would presumably be setup as a
[linux] machine to forward packets from 199.168.199/24 back out to the
real world (via masquerading?).
would this work? what kind of problems would be involved? any thoughts
on the matter or suggestions would be greatly appreciated, as always.
-tcl.
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
