Allow modifying keepalive packets drop probability

[mrsobakin]

Adds new option --keepalive-drop-chance, which allows users to modify keepalive drop probability.

For applications where it is important to maintain a constant connection with a client located behind a NAT, disabling keepalive packet dropping is a must-have. Since I had to add a new option anyway, instead of just disabling/enabling keepalive dropping, I've added an option to modify the drop probability, thus allowing fine-tuning this parameter for specific use cases.

The rationale behind the lack of an always-drop option is that you can simply disable PersistentKeepalive in wireguard config if you need such behavior.

[infinet]

Thanks for the PR!

I am more inclined to add a -mode option, where the mode can be a combination of flags such that, mode = flag1 | flag2 | flag3 .... Let's assume flag1 is 0x01 means do not drop keepalive packet.

• if user want drop all keepalive, then disable PersistentKeepalive
• if user do not want drop any keepalive packet, then set --mode 0x01
• otherwise user can set PersistentKeepalive to a duration, while taking consideration of only 20% keepalive packet can pass. Therefor this disable drop keepalive option may not be necessary, since user can set a short PersistentKeepalive duration to keep NAT happy.

[mrsobakin]

I've thought of adjusting the PersistentKeepalive too, however it sounds more hacky and janky than just adjusting the probability directly. Really, it's a shame that linux network stack does not provide any functionality to delay packets, so we can't add jitter to keepalive duration.

As for the --mode option: I don't really think that adding it would benefit us in any way, especially since we only have one mode. Also, while storing them in a bit field internally is a good idea, taking bit field as a parameter would just reduce readability and make the parameter values less obvious. Adding separate options doesn't cost much neither in code complexity, nor in performance, but vastly improves the user experience.

Returning to the PersistentKeepalive vs probability debate: in my opinion, the ability to adjust the probability should be kept for two reasons:

1. Firstly, with it, wireguard won't need to send the unnecessary packets that will be dropped anyway, thus reducing (yes, by an extremely small margin, but still) load on the CPU and the network stack.

2. Secondly, it simply allows more precise tuning. While it's true that any average duration can be achieved with just adjustment of PersistentKeepalive, allowing the adjustment of drop probability enables us to fine tune the "randomness profile" even further.\ \ For example, we can make so that no keepalive packets are closer than 35 seconds apart, but the NAT port binding lifetime of, say, 120 seconds is satisfied on average (with PersistentKeepalive=35, p=0.7). With the PersistentKeepalive alone, we don't have ability to prevent "bursts" of keepalives, which, depending on the DPI, may taint an entire channel, blocking it for some time.