Le 28/09/2017 à 17:09, Will Sewell a écrit :
Because conntrack has to process packets in both directions, and the
packet header fields in the reply direction may not be obtained just by
swapping the fields in the original direction.
Thanks. That makes sense. I still have some confusion however: in the
case where the original/reply connection information is not equal, how
does the connection tracking system ensure that both hash tuples are
embedded in the same conntrack struct (nf_conn)? Let's say an original
packet arrives with some new original direction connection
information. I'm assuming conntrack will allocate a new nf_conn struct
with just the original hash tuple embedded. When a packet arrives from
the reply direction, how does conntrack find the correct nf_conn to
embed it in? From what I can tell the orifginal connection information
is required to look this up.
I don't know the detail of conntrack data structures, but conntrack
watches packets in two places :
- when the packet enters netfilter (PREROUTING or OUTPUT)
- when the packet leaves netfilter (POSTROUTING or INPUT)
When the first original packet enters netfilter, its characteristics are
used to define the original tuple.
When the packet leaves netfilter after being transformed, its
characteristics are used to define the reply tuple matching expected
reply packets.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
