|
Oops, make that:
Incoming:
iptables -t nat -A PREROUTING -d <Public IP> -i $EXT_INTERFACE -j DNAT
--to-destination <VIP>
Outgoing:
iptables -t nat -A POSTROUTING -s <VIP> -o $EXT_INTERFACE -j SNAT
--to-source <Public IP>
David Mitchell
On 12/19/06, David M <northridgeaustin@xxxxxxxxx> wrote:
Rob:
Thank you for the recommendation.
I hope that I understand you correctly. You are running pf on a
separate firewall, right (and not on the LVS-DR)? "px.py.pz.1" are
the public IPs, right?
Since we are a mostly Linux shop, I would have to try to see if I could
make this work using iptables (rather than pf). I guess that the iptables
rules for a separate firewall would look something like this:
Incoming:
iptables -t nat -A PREROUTING -d <Public IP> -i $EXT_INTERFACE -j DNAT
--to-destination <VIP>
Outgoing:
iptables -t nat -A POSTROUTING -s <Public IP> -o $EXT_INTERFACE -j SNAT
--to-source <VIP>
Having a separate firewall makes sense. Do you think that this is how
most people are using LVS, i.e., with a separate firewall?
David Mitchell
On 12/15/06, Rob <ipvsuser@xxxxxxxxxxxxxxxx> wrote:
>
> > Our setup is currently working. I was just wondering if there is a
> better
> > way to do this.
>
> Well, the way I set up things up is different (possibly better) -
> My goal is to make it easy to config/manage/troubleshoot, secure, fast
> and
> low load on the director(s):
>
> * I use OpenBSD and pf to separate public and private IP spaces
> * Use LVS-DR for all the lvs work (not sure if you can do this or if you
> need
> to use nat for some other reason)
>
> By separating the NATing from the load balancing it seems to simplify
> the
> configuration of both and I feel it is easier to write pf rules than
> iptables (YMMV).
>
> In pf for each of the 30 email servers you need 2 rules:
> Outgoing:
> nat pass on $ext_if inet proto tcp from 172.16.1.1 to port 25 ->
> px.py.pz.1
> Incoming:
> rdr pass on $ext_if inet proto tcp from any to px.py.pz.1 port 25 ->
> 172.16.1.1 port 25
>
> The above will send incoming connections to the correct VIP and keep the
> outgoing
> connections/replies coming from the correct public IP.
>
> For the LVS config:
> -A -t 172.16.1.1:25 -s nq
> -a -t 172.16.1.1:25 -r 172.16.1.101:25 -g -w 100
> -a -t 172.16.1.1:25 -r 172.16.1.102:25 -g -w 100
> -a -t 172.16.1.1:25 -r 172.16.1.103:25 -g -w 100
>
> No special routing set up on the director or real servers, all machines
> have the
> OpenBSD firewall as their gateway. Low load on the director since it is
> DR.
>
> Then to cheat on the arp issue, I hardcode the MAC Address of the
> director into the
> arp table on the OpenBSD firewall for each of the VIPs
> (and run arpwatch and set the Linux machines arp sysconfig params)
>
> One of the cool things you can do with a set up like this is use the
> excellent table handling in pf,
> I have about 85,000 ips that I know are spammers and I don't want them
> using any resources on my
> MTA boxes so I redirect all of them to OpenBSD's spamd which tarpits
> them at extremely low cost:
>
> table <spammers> persist file "/etc/spammers.txt" {}
> rdr pass on $ext_if inet proto tcp from {<spammers>} to any port 25 ->
> 127.0.0.1 port 8027
>
> This means that the MTA boxes can service real mail more quickly since
> slots are not
> being used by spammers.
>
> I do similar things for bogons http://www.cymru.com/Bogons/ and ssh
> brute force attackers.
> I haven't found a reasonable way to work with any sizable tables in
> iptables.
>
> pf and lvs - "Two great tastes that taste great together..."
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
