|
Am 06.02.2008 um 12:20 schrieb Graeme Fowler:
> Hi again
>
> On Wed, 2008-02-06 at 11:36 +0100, Andreas Altenburg wrote:
> <snip>
>> With this config, the real-server uses the director as a gateway
>> (would bei LVS-NAT, right?).
>
> Aha! This is the sneaky bit. With -NAT, all responses must go via the
> director.
> With -DR, the realservers must have a route to the clients. There is
> *nothing* saying that the route to the clients can't go back through
> the
> director!
>
>> Now I would like the real server not to
>> use LVS-NAT but answer the requests directly to the clients. So I
>> guess this would be correct:
> <snip>
>
> No. That tries to put the default route on the loopback interface,
> which
> is never going to work - all the packets will go in the bitbucket.
>
> Your first configuration should work, as long as the director is
> configured to permit response traffic from the VIP to enter its'
> "internal" interface and leave via the public one.
This is what i tried. First, I tried using masquerading on the
director but facing several problems with a soap-server on the real-
server. So I am looking for another possibility. I also tried SNAT,
but without success. In all these cases I have to use MASQ in the
director.cf instead of gate (LVS-NAT). Maybe I am missing something
here.
>
>
> Alternatively, you could have:
>
> # The loopback network interface
> auto lo
> iface lo inet loopback
> address 213.203.208.20
> netmask 255.255.255.255
> broadcast 213.203.208.20
> up sysctl -p
>
> auto eth0
> iface eth0 inet static
> address 10.0.0.5
> netmask 255.255.255.0
> network 10.0.0.0
> broadcast 10.0.0.255
> gateway 10.0.0.1
>
> auto eth1
> iface eth1 inet static
> address 172.16.10.5
> netmask 255.255.255.0
> network 172.16.10.0
> broadcast 172.16.10.255
>
> Then have a second, external gateway at 10.0.0.1 (or some other
> address)
> which allows traffic to flow out from the VIP. You could even make
> this
> a public IP, and firewall the nuts off it - it should only ever source
> outbound traffic, has no need to accept inbound, and therefore can be
> hidden via whatever means necessary. I understand that this is the
> very
> thing you're trying to avoid, but it works for very many other people!
>
OK, that means, I have to put an iptabls rule that will deny all
incming traffic but allow all outgoing traffic, right?
|
