The Gluon Tunneldigger protocol handler hasn't received the care and
attention a core package, especially a VPN protocol, should.

Due to the works in #2102 it's no longer required to maintain
VPN handlers in the Gluon Core and they can be instead included via a
package feed.

Users who wish to continue using a supported core Gluon package are
encouraged to take a look at fastd in conjunction with it's null@l2tp method.
It offers roughly the same performance (it's using the same principle
of operation) and supports connections via IPv6 as a bonus.

In general it should be possible to change the VPN used protocol
asynchronously with a normal update.

If Gluon users wish to continue using tunneldigger the recomendation
is to participate in the development of tunneldigger inside our
community-packages.

Remove legacy migrations. These predate the currently supported upgrade path,
therefore we no longer need them.

Signed-off-by: Magnus Frühling <skorpy@frankfurt.ccc.de>

This code was added way back in 2017. We don't support updates from
those old versions, so we can remove it.

Signed-off-by: David Bauer <mail@david-bauer.net>

The vpn-core package does not utilize simple-tc anymore.
This is now up to the VPN implementations.

Signed-off-by: David Bauer <mail@david-bauer.net>

The ip6tables-legacy metapackage was renamed to ip6ables-zz-legacy.

If a community uses different vpn providers, they typically
assume the same MTU for the wan device underneath the VPN. As
different VPN providers however have different overhead, the MTU
of the VPN device differs for each provider. Therefore this
commit makes the MTU of the VPN device provider specific.

This has two advantages:
1. The same site.conf can used to bake firmwares for different
   VPN providers (only by selecting a diferent vpn feature in the
   site.mk).
2. We are coming closer to the option of integrating multiple VPN
   providers into one firmware.

Require legacy iptables, as Gluon still depends on firewall3. Otherwise,
nftables is pulled in as a dependency.

This removes PKG_VERSION and PKG_RELEASE from most Makefiles, as the
value was never useful for Gluon packages; instead, PKG_VERSION is set
to 1 in gluon.mk.

It also removes two other weird definitions:

- gluon-iptables-clamp-mss-to-pmtu replicating the old PKG_VERSION logic
  from gluon-core, but without the fixed PKG_BUILD_DIR to prevent
  unnessary rebuilds
- gluon-hoodselector set GLUON_VERSION=3

The address of the vpn interface is calculated in the style of
modified EUI-64, based on a virtual mac address. This virtual mac
address consists of 0x00 as first byte and the other five bytes
are taken from the first bytes of md5sum(base64 encoded public key).

The algorithm was taken by the ffmuc, with a slight difference. ffmuc
calculated the result of md5sum(base64 encoded public key + '\n')
which was interpreted as accidential fault and therefore dropped.

Example:
- Public-Key: "gP3VJnTTvnQut+z4O+m0N9RgMyXbgyUbUkF3E3TKX2w="
- Address: "fe80::02ca:b8ff:fedc:2eb3"

The following interfaces are used for wireguard:
- wg_mesh  -> wireguard interface
- mesh-vpn -> vxlan iface on top of wg_mesh

If you use this new feature, make sure the NTP servers in your site
config are publicly reachable. This is necessary, since wireguard
requires correct time before the vpn connection is established.
Therefore gluon performs ntp time synchronisation via WAN before it
establishes the vpn connection. Therefore the NTP servers have to
be publicly reachable (and not only via mesh).

With the removal of ramips-rt305x, the last user of
GLUON_SPECIALIZE_KERNEL is gone.

read_stdout can return NULL and thus the return value need to be checked
prior to accessing it.

Signed-off-by: David Bauer <mail@david-bauer.net>

In case the limit_ingress or limit_egress options are not present in
gluon's mesh_vpn section the respondd provider compares a string literal
with a NULL pointer, crashing respondd.

Check both pointers prior to comparing them in order to mitigate this
issue.

Suggested-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: David Bauer <mail@david-bauer.net>

omit unlimited bandwidth limit
A value of '-' marks a streamdirection as unlimited.

This fully abstracts VPN methods, making gluon-mesh-vpn-fastd and
gluon-mesh-vpn-tunneldigger completely self-contained.

Provide a LUA interface for generic interacting with VPN methods in
gluon-mesh-vpn-core and web packages.

This also adds the ability to install tunneldigger and fastd to the same
image, selecting the VPN method based on the selected domain.

Signed-off-by: David Bauer <mail@david-bauer.net>

This is a fix for the broken ingress traffic-shaping in gluon v2018.2.2
and possibly earlier.

For ingress traffic shaping the kernel option NET_ACT_POLICE is needed.
Before this patch there was no dependency to this. Neither in
gluon_core, gluon-mesh-vpn-core nor in the package.

This patch adds this dependency.

[Matthias Schiffer: move dependency from GLUON_CORE to gluon-mesh-vpn-core]

Fixes #1790

/etc/config/gluon-simple-tc was removed with Gluon 2016.1.

We now keep the VPN enable state, bandwidth limit enable and actual limits
in the core config to avoid having to recover "user intent" from different
config files when the used VPN packages change.

Fixes #1736

None of our scripts can handle fastd and tunneldigger running at the same
time. When both are installed, ignore tunneldigger.

./gluon-wan:25:1: (W122) setting read-only field ? of global arg
./gluon-wan:29:1: (W311) value assigned to variable ok is unused

gluon-wan is a sudo-like exec wrapper that switches the process group to
gluon-mesh-vpn, making it use the WAN dnsmasq rather than resolving over
the mesh.

Note that this only affects DNS at the moment. Processes running under
gluon-wan will still use the regular mesh IPv6 routing table, and not the
WAN routing table. This is not a problem for IPv4, as there is only one
IPv4 routing table.

Fixes #1575

Signed-off-by: Felix Kaechele <felix@kaechele.ca>

This is currently only implemented in the gluon-mesh-vpn-fastd
package.

Advertising the public key may be deemed problematic when
your threat-model involves protecting the nodes privacy
from tunnel traffic correlation by onlink observers.

It can be enabled by setting site.mesh_vpn.fastd.pubkey_privacy
to `false`.

In addition to significant internal differences in check_site_lib.lua (in
particular unifying error handling to a single place for the upcoming
multi-domain support), this changes the way fields are addressed in site
check scripts: rather than providing a string like 'next_node.ip6', the
path is passed as an array {'next_node', 'ip6'}.

Other changes in site check scripts:
* need_array and need_table now pass the full path to the sub fields to the
subcheck instead of the key and value
* Any check referring to a field inside a table implies that all higher
levels must be tables if they exist: a check for {'next_node', 'ip6'} adds
an implicit (optional) check for {'next_node'}, which allows to remove many
explicit checks for such tables

[Matthias schiffer: rebase, add a few more restrictions]

Some files have received some additional refactoring.

The generic upgrade script is moved to run after the more specific scripts.
In addition, the script will now remove the configuration sections of
uninstalled VPN packages, so both positive and negative changes of the
default enable state can be migrated correctly.

Based-on-patch-by: Cyrus Fox <cyrus@lambdacore.de>
Fixes: #1187

VPN daemons were always disabled

Based-on-patch-by: Cyrus Fox <cyrus@lambdacore.de>

The fastd_mesh_vpn site.conf section is renamed to mesh_vpn.fastd.