On 02/27/2018 05:00 PM, Arturo Borrero Gonzalez wrote:
On 27 February 2018 at 22:56, zrm <zrm@xxxxxxxxxxxxxxx> wrote:
On 02/27/2018 04:15 PM, Arturo Borrero Gonzalez wrote:
On 26 February 2018 at 17:21, zrm <zrm@xxxxxxxxxxxxxxx> wrote:
Is there any way for a user process to query whether a hypothetical
packet
would be accepted or rejected given the current rules and state?
I know the transport protocol, source and destination, in-interface etc.
I
want to ask the kernel if a packet with those parameters would be
forwarded
or dropped.
The specific thing I'm trying to do is to create a conntrack entry but
only
if such a packet would have created it. I know how to create the
conntrack
entry, the question is how to evaluate the condition first.
I'm trying to avoid having to evaluate the rules manually, which is very
complicated and likely to result in bugs. And I'm not even sure how to
get
certain information to do that, like whether a packet would currently
match
the conntrack RELATED state.
Is there some API to query this information? I imagine that could be
useful
for debugging as well.
No such feature exists currently. You could try creating the packet by
hand (scapy?) and injecting it to the stack to see where it goes.
I had considered that, the trouble is then it actually *sends* the packet,
which could confuse the other endpoint if it gets an empty UDP packet
instead of one with a specific payload, or the forged packet is missing some
expected options or TCP flags that the one the real source will send in five
milliseconds would have etc.
I also sometimes have to do specific source address or port translation and
the forged packet could create the "wrong" conntrack entry which could also
affect the verdict.
I suspect ultimately the only proper way to do this is going to be with
support from a kernel module, but I've never done one of those before.
Wait, why you don't let the entry to be created by the conntrack engine itself?
So this is for the Port Control Protocol (RFC6887) PEER operation. The
client can specify what the external IP address and port should be. The
main reason is so the client can help the NAT device recreate its state
after it was reset.
The client uses PEER to learn the external IP and port the gateway
assigned to its connections, then the gateway gets rebooted for any
reason (or replaced outright) and sends out multicast announcements to
alert all the clients that it was reset, so the clients can send new
PEER requests to tell the gateway how their connections were being
translated before they get disconnected.
If you let the conntrack engine choose the port then it could choose a
different one and drop the active connection.
--
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
