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).
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>
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
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
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
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
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
