An in-kernel "route changed" notification were great, because then we
could delete all MASQUERAD-ed entries where --update-source-address
flag is set.
If we could register to receive routing changed events for SNAT source
addresses, that would be great (more efficient) but if the mechanism
does not yet exist, it would be much more difficult to create.
I suppose that if we just deleted them all on any routing change, then
that would solve the immediate problem for us. It would be ideal if
incoming packets could still be directed to the correct internal
source, but dropping them is a smaller problem than continuing to send
out invalid packets and keeping a broken entry alive forever.
I'm probably completely missing the point, but:
- Route changes such as you describe will be triggered by some user
space event.
- Lets generically call that "dhcpcd" for the sake of a label
- These userspace events should all be capable of some kind of "hook" on
change
- This userspace hook can zap the relevant conntrack entries
The pros/conns seem to be that:
- one more piece of userspace to maintain
- but there is now integration between the userspace routing decisions
and the decision to zap certain conntrack entries
For example in my situation I dynamically tweak ipsets and an IP
dropping into an IPset causes routing decisions to be made for just that
user. When we add a user to an ipset we also zap previous conntrack
entries relating to that user.
I'm not sure that I can see any way for the kernel to know when it
should adjust conntrack entries in my situation?
Cheers
Ed W
--
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
