[WIP] ffh.exitnode: add MTU fix for QUIC

[CodeFetch]

This commit creates a dummy interface with the "bottleneck" MTU
among our VPN path (currently batadv - see issue #80).
Furthermore it creates an iptables DNAT rule which changes the
destination IP address of incoming QUIC (UDP 443) packets which
exceed the bottleneck MTU to a special IPv4 continuity address
which is part of the subnet of the dummy interface.
When an oversized QUIC packet arrives, it will thus be routed
to the dummy interface which in turn generates an ICMP destination
unreachable (fragmentation needed) packet as the packet does
not fit the MTU of the dummy interface.
The QUIC servers will react to the ICMP packet by changing the
PMTU of their UDP sockets according to the maximum MTU advertised
in the ICMP message, which is the dummy interface's MTU.

It has been tested on sn10. We now need to test if QUIC still works properly. There seems to be still an issue.

[1977er]

Can we (start) seperating the different functional blocks within ferm's 50-exitnode.conf? Adding more functions to this single file makes is hard to read over time.

[AiyionPrime]

Remember to get rid of all the commented out sections, or mark the PR as draft;
so that they don't accidentally become master code ;)

[CodeFetch]

@AiyionPrime I'll do... "WIP" means Work-in-progress. I think it's the same as a draft? I wonder why Github does not mark it as a draft automatically.

[CodeFetch]

Google does not respect our ICMP messages. I've tested how the browser behaves when QUIC traffic is filtered. It seems Chrome tests for QUIC support in the background. So blocking QUIC traffic that is too big is not an issue for the UX. Still I've send an email to Google and asked them if this is intended. They promote QUIC so I think they should behave according to the standard and do proper PMTU discovery... Instead they seem to have implemented their own algorithm which does not work correctly.