On 11/05/2011 01:32, richardvo...@gmail.com wrote:
>> Note that it's the nf_mark we will be setting. But:
>> get/setsockopt(fd, SOL_SOCKET, SO_MARK, ...)
> That allows you to set a mark for your outgoing packets, and find out
> what mark is in effect on outgoing packets.
>
> There's still a large piece of the puzzle missing, namely finding out
> what mark is carried by incoming requests, since this determines that
> mark that goes on the forwarded query (when it cannot be answered from
> cache).
This is where "conntrack" comes in. Please have a look back at my
previous email where I try and show the interaction between iptables and
conntrack?
Just a quick summary, but the chain is:
- "Something" marks packets with an nf_mark (from the client to dnsmasq
it will be iptables, from dnsmasq to the upstream it will be dnsmasq
copying the original mark across to the new connection)
- Conntrack reads the nf_mark and remembers it (lets call it a
conntrack_mark now)
- When the UDP (or TCP) response comes back, conntrack matches the
packet and applies the nf_conntrack mark to the packet, this is then
used to restore the iptables nf_mark
So roughly you need to mark just one packet at the start of the
connection and conntrack can then be used to bootstrap that up to a mark
on every packet both in and out from there on. Obviously you don't
*have* to use conntrack if it's not useful for a particular connection
(iptables has a "do not track" rule also). Also conntrack has limits
and it basically tracks tcp, udp, icmp "connections", plus a small
number of other protocols such as ftp where it has enough of a protocol
parser to mark the related data connections
*I* have the problem or marking up the connection from the client to
dnsmasq, the problem we are trying to solve is how to copy that mark
onto the outgoing connection from dnsmasq (so it appears like a straight
through connection)
Here is an example of conntrack logging the start and end of a dns query:
May 9 22:23:40 localhost [NEW] ORIG: SRC=10.141.36.76 DST=8.8.4.4
PROTO=UDP SPT=25630 DPT=53 PKTS=0 BYTES=0 , REPLY: SRC=8.8.4.4
DST=10.141.36.76 PROTO=UDP SPT=53 DPT=25630 PKTS=0 BYTES=0
May 9 22:24:10 localhost [DESTROY] ORIG: SRC=10.141.36.76 DST=8.8.4.4
PROTO=UDP SPT=25630 DPT=53 PKTS=1 BYTES=61 , REPLY: SRC=8.8.4.4
DST=10.141.36.76 PROTO=UDP SPT=53 DPT=25630 PKTS=1 BYTES=206
Here is a more detailed view of what you can get from conntrack:
===>PACKET BOUNDARY
orig.ip.saddr=76.36.141.10
orig.ip.daddr=4.4.8.8
orig.ip.protocol=17
orig.l4.sport=19210
orig.l4.dport=53
orig.raw.pktlen=61
orig.raw.pktcount=1
reply.ip.saddr=4.4.8.8
reply.ip.daddr=76.36.141.10
reply.ip.protocol=17
reply.l4.sport=53
reply.l4.dport=19210
reply.raw.pktlen=206
reply.raw.pktcount=1
ct.mark=0
ct.id=3482237484
ct.event=4
flow.start.sec=1304979130
flow.start.usec=875286
flow.end.sec=1304979160
flow.end.usec=946109
oob.family=2
oob.protocol=0
ct=default
===>PACKET BOUNDARY
If you install conntrack_tools on your linux machine, ping something, do
a few dns queries, etc and then run:
conntrack -L
You should see some useful stuff?
> Otherwise the mark could be calculated somehow from the
> client address, but this is very unlikely to yield a generally useful
> solution.
We can only do that for the leg from the client to dnsmasq, after that
we loose information about the original request. Hence the need to copy
the packet mark across to the connection from dnsmasq to upstream dns server
Thanks
Ed W
