On 02/27/2018 05:39 PM, Neal P. Murphy wrote:
On Tue, 27 Feb 2018 17:22:28 -0500
zrm <zrm@xxxxxxxxxxxxxxx> wrote:
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
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.
See https://tools.ietf.org/html/rfc6887#section-14
--
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
