Patrick McHardy wrote:
Pablo Neira Ayuso wrote:
Patrick McHardy wrote:
ip maddr add 01:00:5e:00:01:01 dev eth1
ip maddr add 01:00:5e:00:01:02 dev eth2
arptables -I OUTPUT -o eth1 --h-length 6 \
-j mangle --mangle-mac-s 01:00:5e:00:01:01
arptables -I INPUT -i eth1 --h-length 6 \
--destination-mac 01:00:5e:00:01:01 \
-j mangle --mangle-mac-d 00:zz:yy:xx:5a:27
Mhh, is the saving of one or two characters really worth these
deviations from the kind-of established naming scheme? Its hard
to remember all these minor differences in my opinion.
Hm, you mean the name "mangle" or the name of the option
"--mangle-mac-d"? This is what we currently have in kernel mainline
and arptables userspace, it's not my fault :). I can send you a patch
to fix it with a consistent naming without breaking backward
compatibility both in kernel and user-space.
Great, I wasn't aware that this already existed in userspace :)
Yes, it's hosted by the ebtables projects. That tool really need some
care. It works but I don't know if it's actively maintained. Probably we
can offer hosting for it in git.netfilter.org. I'll investigate this.
In the case of TCP connections, pickup facility has to be disabled
to avoid marking TCP ACK packets coming in the reply direction as
valid.
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
I'm not sure I understand this. You *don't* want to mark them
as valid, and you need to disable pickup for this?
If TCP pickup is enabled, one TCP ACK packet coming in the reply
direction enters TCP ESTABLISHED state. Since that's a valid
state-transition, the cluster match will consider that this is part of
a connection that this node is handling since it's a valid
state-transition. The cluster match does not mark packets that trigger
invalid state transitions.
Why use conntrack at all? Shouldn't the cluster match simply
filter out all packets not for this cluster and thats it?
You stated it needs conntrack to get a constant tuple, but I
don't see why the conntrack tuple would differ from the data
that you can gather from the packet headers.
No, source NAT connections would have different headers. A -> B for
original, and B -> FW for reply direction. Thus, I cannot apply the same
hashing for packets going in the original and the reply direction.
Moreover, if this is packet-based, think also about possible asymmetric
filtering: original traffic direction filtered by node 1 but reply
traffic filtered by node 2. That will not work for a stateful firewall.
echo +2 > /proc/sys/net/netfilter/cluster/$PROC_NAME
Does this provide anything you can't do by replacing the rule
itself?
Yes, the nodes in the cluster are identifies by an ID, the rule allows
you to specify one ID. Say you have two cluster nodes, one with ID 1,
and the other with ID 2. If the cluster node with ID 1 goes down, you
can echo +1 to node with ID 2 so that it will handle packets going to
node with ID 1 and ID 2. Of course, you need conntrackd to allow node
ID 2 recover the filtering.
I see. That kind of makes sense, but if you're running a
synchronization daemon anyways, you might as well renumber
all nodes so you still have proper balancing, right?
Indeed, the daemon may also add a new rule for the node that has gone
down but that results in another extra hash operation to mark it or not
(one extra hash per rule) :(.
--
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
