On 02/27/2018 10:56 PM, zrm wrote: > It's not that I'm trying to create a high availability gateway, it's > that I'm trying to create a daemon that processes Port Control Protocol > requests. The protocol is specifically designed to do this, I'm just > trying to implement it. Properly implemented the PEER request used to restore a previous dynamic mapping (e.g. RFC6887 section 10.4) overrides or circumvents what "Would have happened" in the dynamic path. Therefore you _never_ want to know what treatment a "hypothetical packet" "would have had". For example your rules may well use random port mapping, or conflicting port mapping, so the peer request of this type should _coerce_ the new mapping to duplicate the old "as early in the NAT flow as possible". So during the first run the NT mapping happens naturally. Then the gateway dips out of service. Then the gateway comes back. Then the authorized actor (client) coerces the old mapping. One of the best ways to do this would be to have some sets. One consulted at the head of the SNAT and DNAT sections of the postrooting and prerooting chains or hooked nft chains. In prerouting you DNAT the incoming (public-to-private) packets and in postrouting you SNAT the outgoing (private-to-public) packets. Whichever rule gets hit first by "a real packet" will then create the necessary connection tracking information. --- In practice, however, there is a non-trivial chance that that one or both endpoints will already know that the old session is broken. They will have gotten various error responses while the gateway was down, or in the interval between the restart and the PEER event. Having a rational back-off-and-restart built into the protocol is _way_ more useful than implementing PEER service for this purpose. This is part of why most of PCP is just kind of laying there on the floor instead of being part of every distro. This is the ugly race that page 38 items i and ii are all on about, and so you've got way more kernel hacking to do to really, properly restart a link this way. --- ASIDE: yes I was thinking about writing a PCP deamon myself, mostly to deal with some of the uPNP nonsense my playstation 4 does. --- Basically once you really look at section 11 you'll see that the MAP operation already needs a pair of rules in the nat prerouting and postrouting chains/tables. Section 10's four modalities are just use cases for section 11. If your protocol and server and client don't know how to ask "what do I look like to you" as part of doing their average work, then they aren't going to have the information necessary to reconnect anyway. So PCP clients already need to do a lot of work. It's generally better if they semantically agree on a restart state and then manually restart, rather than trying to recreate a previous wire-line state mid-stride. On the opposite side, some protocols like SIP really could do with robust MAP operation, even if they then want to then just reconnect with new ports/addresses after a short outage. --Rob. -- 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
