On 10/05/2011 09:53, Simon Kelley wrote:
> There's two stages to think about. One: a requestor sends a UDP request
> to dnsmasq. All of these are received by dnsmasq through the same
> listening socket, or a best through a very few sockets.
I'm not 100% sure, but given that dnsmasq can ensure that every reply
packet is correctly tagged with the correct mark, I don't think it will
matter whether conntrack works correctly for client -> dnsmasq
> We need some way
> of getting the conntrack information associated with individual packets,
> not sockets. Is that possible?
Just to be clear - I believe that applications apply firewall "marks",
which are confusingly different to conntrack marks
The process is something like:
- iptables (or dnsmasq) applies a firewall "mark" to a packet
- this is copied up to the connection tracking "mark"
- on return packets from outside we can request that conntrack --restore
the firewall mark based on the "connection tracking" state
I am learning this as well so I hope I got that perfectly correct...
So, I believe we only test for and apply firewall marks...
setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
(Quick check, but probably call them nf_mark and conntrack_mark for clarity)
> Two: the request gets sent upstream.
> There is _normally_ a new socket for each request (for source-port
> randomisation), so that's fine. The exceptions to this probably don't
> matter (source-port randomisation configured off, very heavy load where
> sockets are re-used to avoid resource use growing without bound.)
This works for me.
What I'm not 100% sure of is whether anything special is required to
change the conntrack_mark during a connection? ie can you apply an
nf_mark at the start of a connection, that gets copied up to be a
conntrack mark, then what happens if you switch the nf_mark during the
connection?
This will only occur it seems under heavy stress, but the two options
are either: a) it works fine if the connection flip flops it's nf_mark
b) we should set the nf_mark to zero, which should be picked up as
unmarked traffic by simple iptables rules. I really have no idea until
I get to try it... Suggest a) seems best at this stage, to put a stake
in the ground...
> Given the abilty to read the conntrack mark for an incoming request, and
> set the conntrack mark for a socket-to-upstream, the rest is trivial in
> implement.
Note that it's the nf_mark we will be setting. But:
get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
I hope this makes implementation feasible?
Oh, I found this page with some examples on firewall marks:
http://home.regit.org/netfilter-en/netfilter-connmark/
Also see any discussion on "policy routing" - generally firewall marks
are used for routing decisions. You can use iptables to mark packets in
a certain way, then conntrack takes care of perpetuating that mark
through time, finally you can route or account based on that mark. Cool
huh.
For testing I guess apply a mark based on IP address of the test client
machine, then see if you can do something trivial with filtering the
output of dnsmasq using the output mark? (I guess I need to supply
iptables rules for that, but I'm not fluent enough to crack them out
without testing first...)
Thanks for looking into this
Ed W
