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? _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
