|
Hi,
Vinnie wrote:
Sorry it took me so long to post a reply, been pretty busy lately...
Copy that.
http://www.lvwnet.com/vince/files/ipvs/linux-2.4.19-ipvs-1.0.7-antefacto.patch.tar.bz2
Hmmm, a quick glance shows me that this might have problems with
o SMP (skb sneaking without releasing lock)
o wonder if this is still working in 2.4.22 and later after all those
SKB linearizing going on in netfilter
o the patch seriously breaks the POM mechanism plus semantics.
o it should really use the ctnetlink framework for what it tries to do.
Feel free to look it over and pick it apart.
http://www.lvwnet.com/vince/linux/Keepalived-LVS-NAT-Director-ProxyArp-Firewall-HOWTO.html
Wow, quite good!
Well I haven't tried to crash the firewall/Director or anything, but to
sum it up, the firewall box is doing its job now just as well as it was
before I started dinking around with LVS/IPVS. It is letting traffic
come IN that I have IPVS virtual services for, and letting it be
FORWARDED to the Real Servers. It's not getting in the way of IPVS
connections in progress, nor does it appear to be letting traffic
through which is NOT related to connections already in progress.
Well, did the antefacto patch change anything which wasn't possible before
according to your description?
Guys, I hope you _do_ realize that not even netfilter has a properly
working connection tracking. Without the tcp-window-tracking patch,
netfilter allows you to send arbitrary packets through the stack. It's
a well-known fact and even the netfilter homepage at some point
mentioned it.
Point taken. But that's not an IPVS or Antefacto problem.
No definitely not, but I still do not see what you gain with it. But it could be
me being stupid again. I have a long history of misunderstanding things for long
periods. If it wouldn't be for all the nice people on this list, I'd still be as
dumb as a potato.
No, I can't say that I have. Perhaps you would be willing to put some
of that expertise you have to work?
If I see the real benefit I might.
I am aware of that. But the point about all of this (and the reason
that the folks who actually wrote the Antefacto patch did so) is that
IPVS works independently of netfilter's connection tracking. So
Netfilter doesn't have a CLUE about all those connections going on (or
not going on) to IPVS-based services and RealServers.
Fair enough.
But if you want your LVS Director to also be your main firewall, that
means you have to be able to tell your firewall box, in ways that you
can communicate your wishes with iptables commands, what kind of traffic
you want to allow to go in/out of your LVS. But that's pretty hard to
do since IPVS unmodified doesn't bother to let netfilter in on the loop
of what it's doing.
As long as the rule is before the hook of LVS you can do packet filtering, not
stateful though, but as I said, it wouldn't be any different to what you already
had.
The antefacto patch allows netfilter and IPVS to communicate about all
that traffic going through your LVS, so that at the iptables ruleset
level, it is possible to write rules that work for your LVS.
Ok. I start to see why it is interesting for some people to have this patch,
especially if it's a combined node, LVS + packet filter.
If netfilter's connection tracking is broken, then it's broken -- IPVS,
Antefacto, or not.
It's not broken, it just might not do what most people assume it should.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
