On Tue, 27 Feb 2018 17:22:28 -0500 zrm <zrm@xxxxxxxxxxxxxxx> wrote: > 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. I can only think of one way to do this: use the 'high availability' feature. You have two gateways; one is the master, the other is the slave. The maser tells the slave everything it does; the slave sets its state to match the master. If the master fails, the slave takes over (changes its MAC and IP addresses to that of the master) and becomes master. With some effort, you might be able to have a gateway that is the only master and a userspace program that is sort-of a slave. If the master rolls, the slave will wait for the master to return, then reset the master's state(s). But it might be easier to just use a proper master/slave setup. N -- 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
