fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-05-18 10:28:07 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/core/devices/nm-device-wireguard.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2094 lines
80 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: LGPL-2.1-or-later */
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2018 Javier Arteaga <jarteaga@jbeta.is>
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
*/
all: add "src/core/nm-default-daemon.h" as replacement for "nm-default.h"
2021-02-04 18:04:13 +01:00
#include "src/core/nm-default-daemon.h"
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#include "nm-device-wireguard.h"
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
#include <linux/rtnetlink.h>
#include <linux/fib_rules.h>
libnm,cli: add NMSettingWireGuard For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
2018-12-27 16:48:30 +01:00
#include "nm-setting-wireguard.h"
libnm: Use _nm_connection_ensure_setting() Use `_nm_connection_ensure_setting()` to eliminate the duplicated codes. This function will retrieve the specific setting from connection, if not found, create new one and attach to the connection. Signed-off-by: Gris Ge <fge@redhat.com>
2021-08-20 18:40:21 +08:00
#include "libnm-core-aux-intern/nm-libnm-core-utils.h"
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
#include "nm-l3-config-data.h"
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-intern/nm-core-internal.h"
build: move "shared/nm-{glib-aux,log-null,log-core}" to "src/libnm-{glib-aux,log-null,log-core}"
2021-02-18 17:37:47 +01:00
#include "libnm-glib-aux/nm-secret-utils.h"
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#include "nm-device-private.h"
platform: move more platform code to src/libnm-platform/
2021-03-04 11:29:39 +01:00
#include "libnm-platform/nm-platform.h"
#include "libnm-platform/nmp-object.h"
#include "libnm-platform/nmp-rules-manager.h"
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#include "nm-device-factory.h"
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
#include "nm-active-connection.h"
#include "nm-act-request.h"
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
#include "dns/nm-dns-manager.h"
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
device: improve "nm-device-logging.h" to support a self pointer of NMDevice type "nm-device-logging.h" defines logging macros for a NMDevice instance. It also expects a "self" variable in the call environment, and that variable had to be in the type of NMDevice or the NMDevice subclass. Extend the macro foo, so that @self can be either a NMDevice* pointer or a NMDevice$SUBTYPE. Of course, that would have always been possible, if we would simply cast to "(NMDevice *)" where we need it. The trick is that the macro only works if @self is one of the two expected types, and not some arbitrary unrelated type.
2020-11-06 18:22:11 +01:00
#define _NMLOG_DEVICE_TYPE NMDeviceWireGuard
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#include "nm-device-logging.h"
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/* TODO: activate profile with peer preshared-key-flags=2. On first activation, the secret is
* requested (good). Enter it and connect. Reactivate the profile, now there is no password
* prompt, as the secret is cached (good??). */
/* TODO: unlike for other VPNs, we don't inject a direct route to the peers. That means,
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* you might get a routing scenario where the peer (VPN server) is reachable via the VPN.
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
* How we handle adding routes to external gateway for other peers, has severe issues
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* as well. We may use policy-routing like wg-quick does. See also discussions at
wireguard: update TODO list for WireGuard devices (cherry picked from commit 3990c92fbf4789d8de2264b39f9d1b690f5dd4d5)
2019-03-01 09:02:20 +01:00
* https://www.wireguard.com/netns/#improving-the-classic-solutions */
/* TODO: honor the TTL of DNS to determine when to retry resolving endpoints. */
/* TODO: when we get multiple IP addresses when resolving a peer endpoint. We currently
* just take the first from GAI. We should only accept AAAA/IPv6 if we also have a suitable
* IPv6 address. The problem is, that we have to recheck that when IP addressing on other
* interfaces changes. This makes it almost too cumbersome to implement. */
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/*****************************************************************************/
libnm,cli: add NMSettingWireGuard For now only add the core settings, no peers' data. To support peers and the allowed-ips of the peers is more complicated and will be done later. It's more complicated because these are nested lists (allowed-ips) inside a list (peers). That is quite unusual and to conveniently support that in D-Bus API, in keyfile format, in libnm, and nmcli, is a effort. Also, it's further complicated by the fact that each peer has a secret (the preshared-key). Thus we probably need secret flags for each peer, which is a novelty as well (until now we require a fixed set of secrets per profile that is well known).
2018-12-27 16:48:30 +01:00
G_STATIC_ASSERT(NM_WIREGUARD_PUBLIC_KEY_LEN == NMP_WIREGUARD_PUBLIC_KEY_LEN);
G_STATIC_ASSERT(NM_WIREGUARD_SYMMETRIC_KEY_LEN == NMP_WIREGUARD_SYMMETRIC_KEY_LEN);
/*****************************************************************************/
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
#define LINK_CONFIG_RATE_LIMIT_NSEC (50 * NM_UTILS_NSEC_PER_MSEC)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/* a special @next_try_at_nsec timestamp indicating that we should try again as soon as possible. */
#define NEXT_TRY_AT_NSEC_ASAP ((gint64) G_MAXINT64)
/* a special @next_try_at_nsec timestamp that is
* - positive (indicating resolve-checks are enabled)
* - already in the past (we use the absolute timestamp of 1nsec for that). */
#define NEXT_TRY_AT_NSEC_PAST ((gint64) 1)
/* like %NEXT_TRY_AT_NSEC_ASAP, but used for indicating to retry ASAP for a @retry_in_msec value.
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* That is a relative time duration, contrary to @next_try_at_nsec which is an absolute
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
* timestamp. */
#define RETRY_IN_MSEC_ASAP ((gint64) G_MAXINT64)
clang-format: reformat code with clang 12 The format depends on the version of the tool. Now that Fedora 34 is released, update to clang 12 (clang-tools-extra-12.0.0-0.3.rc1.fc34.x86_64).
2021-05-03 21:48:58 +02:00
#define RETRY_IN_MSEC_MAX ((gint64) (30 * 60 * 1000))
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
typedef enum {
LINK_CONFIG_MODE_FULL,
LINK_CONFIG_MODE_REAPPLY,
LINK_CONFIG_MODE_ASSUME,
LINK_CONFIG_MODE_ENDPOINTS,
} LinkConfigMode;
typedef struct {
GCancellable *cancellable;
NMSockAddrUnion sockaddr;
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
/* the timestamp (in nm_utils_get_monotonic_timestamp_nsec() scale) when we want
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
* to retry resolving the endpoint (again).
*
* It may be set to %NEXT_TRY_AT_NSEC_ASAP to indicate to re-resolve as soon as possible.
*
* A @sockaddr is either fixed or it has
* - @cancellable set to indicate an ongoing request
* - @next_try_at_nsec set to a positive value, indicating when
* we ought to retry. */
gint64 next_try_at_nsec;
guint resolv_fail_count;
} PeerEndpointResolveData;
typedef struct {
NMWireGuardPeer *peer;
NMDeviceWireGuard *self;
CList lst_peers;
PeerEndpointResolveData ep_resolv;
/* dirty flag used during _peers_update_all(). */
bool dirty_update_all : 1;
} PeerData;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
NM_GOBJECT_PROPERTIES_DEFINE(NMDeviceWireGuard, PROP_PUBLIC_KEY, PROP_LISTEN_PORT, PROP_FWMARK, );
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
typedef struct {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMDnsManager *dns_manager;
NMPlatformLnkWireGuard lnk_curr;
NMActRequestGetSecretsCallId *secrets_call_id;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
CList lst_peers_head;
GHashTable *peers;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
/* counts the numbers of peers that are currently resolving. */
guint peers_resolving_cnt;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gint64 resolve_next_try_at;
gint64 link_config_last_at;
guint resolve_next_try_id;
guint link_config_delayed_id;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
guint32 auto_default_route_fwmark;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint32 auto_default_route_priority;
bool auto_default_route_enabled_4 : 1;
bool auto_default_route_enabled_6 : 1;
bool auto_default_route_initialized : 1;
bool auto_default_route_refresh : 1;
bool auto_default_route_priority_initialized : 1;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
} NMDeviceWireGuardPrivate;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
struct _NMDeviceWireGuard {
NMDevice parent;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceWireGuardPrivate _priv;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
};
struct _NMDeviceWireGuardClass {
NMDeviceClass parent;
};
G_DEFINE_TYPE(NMDeviceWireGuard, nm_device_wireguard, NM_TYPE_DEVICE)
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
#define NM_DEVICE_WIREGUARD_GET_PRIVATE(self) \
_NM_GET_PRIVATE(self, NMDeviceWireGuard, NM_IS_DEVICE_WIREGUARD, NMDevice)
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static void _peers_resolve_start(NMDeviceWireGuard *self, PeerData *peer_data);
static void _peers_resolve_retry_reschedule(NMDeviceWireGuard *self, gint64 new_next_try_at_nsec);
static gboolean link_config_delayed_resolver_cb(gpointer user_data);
static gboolean link_config_delayed_ratelimit_cb(gpointer user_data);
/*****************************************************************************/
shared: drop _STATIC variant of macros that define functions Several macros are used to define function. They had a "_STATIC" variant, to define the function as static. I think those macros should not try to abstract entirely what they do. They should not accept the function scope as argument (or have two variants per scope). This also because it might make sense to add additional __attribute__(()) to the function. That only works, if the macro does not pretend to *not* define a plain function. Instead, embrace what the function does and let the users place the function scope as they see fit. This also follows what is already done with static NM_CACHED_QUARK_FCN ("autoconnect-root", autoconnect_root_quark)
2020-02-13 14:55:26 +01:00
static NM_UTILS_LOOKUP_STR_DEFINE(_link_config_mode_to_string,
LinkConfigMode,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_UTILS_LOOKUP_DEFAULT_NM_ASSERT(NULL),
NM_UTILS_LOOKUP_ITEM(LINK_CONFIG_MODE_FULL, "full"),
NM_UTILS_LOOKUP_ITEM(LINK_CONFIG_MODE_REAPPLY, "reapply"),
NM_UTILS_LOOKUP_ITEM(LINK_CONFIG_MODE_ASSUME, "assume"),
NM_UTILS_LOOKUP_ITEM(LINK_CONFIG_MODE_ENDPOINTS, "endpoints"), );
/*****************************************************************************/
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
static void
_auto_default_route_get_enabled(NMSettingWireGuard *s_wg,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *connection,
gboolean *out_enabled_v4,
gboolean *out_enabled_v6)
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
{
NMTernary enabled_v4;
NMTernary enabled_v6;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
enabled_v4 = nm_setting_wireguard_get_ip4_auto_default_route(s_wg);
enabled_v6 = nm_setting_wireguard_get_ip6_auto_default_route(s_wg);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
if (enabled_v4 == NM_TERNARY_DEFAULT) {
if (nm_setting_ip_config_get_never_default(
nm_connection_get_setting_ip_config(connection, AF_INET)))
enabled_v4 = FALSE;
}
if (enabled_v6 == NM_TERNARY_DEFAULT) {
if (nm_setting_ip_config_get_never_default(
nm_connection_get_setting_ip_config(connection, AF_INET6)))
enabled_v6 = FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
if (enabled_v4 == NM_TERNARY_DEFAULT || enabled_v6 == NM_TERNARY_DEFAULT) {
guint i, n_peers;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
n_peers = nm_setting_wireguard_get_peers_len(s_wg);
for (i = 0; i < n_peers; i++) {
NMWireGuardPeer *peer = nm_setting_wireguard_get_peer(s_wg, i);
guint n_aips;
guint j;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
n_aips = nm_wireguard_peer_get_allowed_ips_len(peer);
for (j = 0; j < n_aips; j++) {
const char *aip;
gboolean valid;
int prefix;
int addr_family;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
aip = nm_wireguard_peer_get_allowed_ip(peer, j, &valid);
if (!valid)
continue;
if (!nm_utils_parse_inaddr_prefix_bin(AF_UNSPEC, aip, &addr_family, NULL, &prefix))
continue;
if (prefix != 0)
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
if (addr_family == AF_INET) {
if (enabled_v4 == NM_TERNARY_DEFAULT) {
enabled_v4 = TRUE;
if (enabled_v6 != NM_TERNARY_DEFAULT)
goto done;
}
} else {
if (enabled_v6 == NM_TERNARY_DEFAULT) {
enabled_v6 = TRUE;
if (enabled_v4 != NM_TERNARY_DEFAULT)
goto done;
}
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
done:;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
*out_enabled_v4 = (enabled_v4 == TRUE);
*out_enabled_v6 = (enabled_v6 == TRUE);
}
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
#define AUTO_RANDOM_RANGE 500u
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
static guint32
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
_auto_default_route_get_auto_fwmark(const char *uuid)
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
{
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
guint64 rnd_seed;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
/* we use the generated number as fwmark but also as routing table for
* the default-route.
*
* We pick a number
*
* - based on the connection's UUID (as stable seed).
* - larger than 51820u (arbitrarily)
* - one out of AUTO_RANDOM_RANGE
*/
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
rnd_seed = c_siphash_hash(NM_HASH_SEED_16(0xb9,
0x39,
0x8e,
0xed,
0x15,
0xb3,
0xd1,
0xc4,
0x5f,
0x45,
0x00,
0x4f,
0xec,
0xc2,
0x2b,
0x7e),
(const guint8 *) uuid,
uuid ? strlen(uuid) + 1u : 0u);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
return 51820u + (rnd_seed % AUTO_RANDOM_RANGE);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
}
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
#define PRIO_WIDTH 2u
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
static guint32
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
_auto_default_route_get_auto_priority(const char *uuid)
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
{
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
const guint32 RANGE_TOP = 32766u - 1000u;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint64 rnd_seed;
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
/* we pick a priority for the routing rules as follows:
*
* - use the connection's UUID as stable seed for the "random" number.
* - have it smaller than RANGE_TOP (32766u - 1000u), where 32766u is the priority of the default
* rules
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* - we add 2 rules (PRIO_WIDTH). Hence only pick even priorities.
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
* - pick one out of AUTO_RANDOM_RANGE. */
rnd_seed = c_siphash_hash(NM_HASH_SEED_16(0x99,
0x22,
0x4d,
0x7c,
0x37,
0xda,
0x8e,
0x7b,
0x2f,
0x55,
0x16,
0x7b,
0x75,
0xda,
0x42,
0xdc),
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
(const guint8 *) uuid,
uuid ? strlen(uuid) + 1u : 0u);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
return RANGE_TOP - (((rnd_seed % (PRIO_WIDTH * AUTO_RANDOM_RANGE)) / PRIO_WIDTH) * PRIO_WIDTH);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
}
static void
_auto_default_route_init(NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *connection;
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
gboolean enabled_v4 = FALSE;
gboolean enabled_v6 = FALSE;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
gboolean refreshing_only;
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
guint32 new_fwmark = 0;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint32 old_fwmark;
char sbuf1[100];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
if (G_LIKELY(priv->auto_default_route_initialized && !priv->auto_default_route_refresh))
return;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
refreshing_only = priv->auto_default_route_initialized && priv->auto_default_route_refresh;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
old_fwmark = priv->auto_default_route_fwmark;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
connection = nm_device_get_applied_connection(NM_DEVICE(self));
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
if (connection) {
NMSettingWireGuard *s_wg;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
s_wg = _nm_connection_get_setting(connection, NM_TYPE_SETTING_WIREGUARD);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
new_fwmark = nm_setting_wireguard_get_fwmark(s_wg);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
_auto_default_route_get_enabled(s_wg, connection, &enabled_v4, &enabled_v6);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
if ((enabled_v4 || enabled_v6) && new_fwmark == 0u) {
if (refreshing_only)
new_fwmark = old_fwmark;
else
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
new_fwmark = _auto_default_route_get_auto_fwmark(nm_connection_get_uuid(connection));
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
priv->auto_default_route_refresh = FALSE;
priv->auto_default_route_fwmark = new_fwmark;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
priv->auto_default_route_enabled_4 = enabled_v4;
priv->auto_default_route_enabled_6 = enabled_v6;
priv->auto_default_route_initialized = TRUE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: fix crash in _auto_default_route_init() #3 0x00007fb0aa9e7d3d in g_return_if_fail_warning (log_domain=log_domain@entry=0x562295fd5ee3 "libnm", pretty_function=pretty_function@entry=0x562295fd71d0 <__func__.35180> "_connection_get_setting_check", expression=expression@entry=0x562295f8edf7 "NM_IS_CONNECTION (connection)") at ../glib/gmessages.c:2767 #4 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:207 #5 0x0000562295df151a in _connection_get_setting_check (connection=0x0, setting_type=0x562297b17050 [NMSettingWireGuard/NMSetting]) at libnm-core/nm-connection.c:205 #6 0x0000562295ef132a in _nm_connection_get_setting (type=<optimized out>, connection=0x0) at ./libnm-core/nm-core-internal.h:483 #7 0x0000562295ef132a in _auto_default_route_init (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device-wireguard.c:443 #8 0x0000562295ef1b98 in coerce_route_table (device=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, route_table=0, is_user_config=<optimized out>) at src/devices/nm-device-wireguard.c:565 #9 0x0000562295ea42ae in _get_route_table (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard], addr_family=addr_family@entry=2) at src/devices/nm-device.c:2311 #10 0x0000562295ea4593 in nm_device_get_route_table (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2) at src/devices/nm-device.c:2338 #11 0x0000562295eabde0 in ip_config_merge_and_apply (self=0x562297bf82b0 [NMDeviceWireGuard], addr_family=2, commit=1) at src/devices/nm-device.c:7590 #12 0x0000562295ed2f0b in device_link_changed (self=self@entry=0x562297bf82b0 [NMDeviceWireGuard]) at src/devices/nm-device.c:3939 #13 0x00007fb0aa9dc7db in g_idle_dispatch (source=source@entry=0x562297bf0b30, callback=0x562295ed2880 <device_link_changed>, user_data=0x562297bf82b0) at ../glib/gmain.c:5627 #14 0x00007fb0aa9dfedd in g_main_dispatch (context=0x562297a28090) at ../glib/gmain.c:3189 #15 0x00007fb0aa9dfedd in g_main_context_dispatch (context=context@entry=0x562297a28090) at ../glib/gmain.c:3854 #16 0x00007fb0aa9e0270 in g_main_context_iterate (context=0x562297a28090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:3927 #17 0x00007fb0aa9e05a3 in g_main_loop_run (loop=0x562297a0b380) at ../glib/gmain.c:4123 #18 0x0000562295d0b147 in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:465 https://bugzilla.redhat.com/show_bug.cgi?id=1734383 (cherry picked from commit 47fc1a4293437a88adfd247734e32fa1b86ca7a9)
2019-07-30 18:38:48 +02:00
if (connection) {
_LOGT(LOGD_DEVICE,
"auto-default-route is %s for IPv4 and %s for IPv6%s",
priv->auto_default_route_enabled_4 ? "enabled" : "disabled",
priv->auto_default_route_enabled_6 ? "enabled" : "disabled",
priv->auto_default_route_enabled_4 || priv->auto_default_route_enabled_6
? nm_sprintf_buf(sbuf1, " (fwmark 0x%x)", priv->auto_default_route_fwmark)
: "");
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
}
}
static GPtrArray *
get_extra_rules(NMDevice *device)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(device);
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
gs_unref_ptrarray GPtrArray *extra_rules = NULL;
guint32 priority = 0;
int is_ipv4;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *connection;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
_auto_default_route_init(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
connection = nm_device_get_applied_connection(device);
if (!connection)
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
for (is_ipv4 = 0; is_ipv4 < 2; is_ipv4++) {
NMSettingIPConfig *s_ip;
int addr_family = is_ipv4 ? AF_INET : AF_INET6;
guint32 table_main;
guint32 fwmark;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
if (is_ipv4) {
if (!priv->auto_default_route_enabled_4)
continue;
} else {
if (!priv->auto_default_route_enabled_6)
continue;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
if (!extra_rules) {
if (priv->auto_default_route_priority_initialized)
priority = priv->auto_default_route_priority;
else {
wireguard: use fixed fwmark/rule-priority for auto-default-route With "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route", NetworkManager automatically adds policy routing rules for the default route. For that, it needs to pick (up to) two numbers: - the fwmark. This is used both for WireGuard's fwmark setting and is also the number of the routing table where the default-route is added. - the rule priority. NetworkManager adds two policy routing rules, and we need to place them somewhere before the default rules (at 32766). Previously, we looked at exiting platform configuration and picked numbers that were not yet used. However, during restart of NetworkManager, we leave the interface up and after restart we will take over the previous configuration. At that point, we need to choose the same fwmark/priority, otherwise the configuration changes. But since we picked numbers that were not yet used, we would always choose different numbers. For routing rules that meant that after restart a second pair of rules was added. We possibly could store this data in the device's state-file. But that is complex. Instead, just pick numbers deterministically based on the connection's UUID. If the picked numbers are not suitable, then the user can still work around that: - for fwmark, the user can explicitly configure wireguard.fwmark setting. - for the policy routes, the user can explicitly add the rules with the desired priorirites (arguably, currently the default-route cannot be added like a regular route, so the table cannot be set. Possibly the user would have to add two /1 routes instead with suppress_prefixlength=1). (cherry picked from commit cfb497e49936d36867ae3175537c7d4f77259655)
2019-07-31 10:01:04 +02:00
priority =
_auto_default_route_get_auto_priority(nm_connection_get_uuid(connection));
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
priv->auto_default_route_priority = priority;
priv->auto_default_route_priority_initialized = TRUE;
}
extra_rules = g_ptr_array_new_with_free_func((GDestroyNotify) nmp_object_unref);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
s_ip = nm_connection_get_setting_ip_config(connection, addr_family);
table_main = nm_setting_ip_config_get_route_table(s_ip);
if (table_main == 0)
table_main = RT_TABLE_MAIN;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
fwmark = priv->auto_default_route_fwmark;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
G_STATIC_ASSERT_EXPR(PRIO_WIDTH == 2);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
g_ptr_array_add(extra_rules,
nmp_object_new(NMP_OBJECT_TYPE_ROUTING_RULE,
&((const NMPlatformRoutingRule){
.priority = priority,
.addr_family = addr_family,
.action = FR_ACT_TO_TBL,
.table = table_main,
.suppress_prefixlen_inverse = ~((guint32) 0u),
})));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
g_ptr_array_add(extra_rules,
nmp_object_new(NMP_OBJECT_TYPE_ROUTING_RULE,
&((const NMPlatformRoutingRule){
.priority = priority + 1u,
.addr_family = addr_family,
.action = FR_ACT_TO_TBL,
.table = fwmark,
.flags = FIB_RULE_INVERT,
.fwmark = fwmark,
.fwmask = 0xFFFFFFFFu,
})));
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
return g_steal_pointer(&extra_rules);
}
static guint32
coerce_route_table(NMDevice *device, int addr_family, guint32 route_table, gboolean is_user_config)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(device);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
gboolean auto_default_route_enabled;
if (route_table != 0u)
return route_table;
_auto_default_route_init(self);
auto_default_route_enabled = (addr_family == AF_INET) ? priv->auto_default_route_enabled_4
: priv->auto_default_route_enabled_6;
if (auto_default_route_enabled) {
/* we need to enable full-sync mode of all routing tables. */
_LOGT(LOGD_DEVICE,
"coerce ipv%c.route-table setting to \"main\" (table 254) as we enable "
"auto-default-route handling",
nm_utils_addr_family_to_char(addr_family));
return RT_TABLE_MAIN;
}
return 0;
}
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static gboolean
_peer_data_equal(gconstpointer ptr_a, gconstpointer ptr_b)
{
const PeerData *peer_data_a = ptr_a;
const PeerData *peer_data_b = ptr_b;
return nm_streq(nm_wireguard_peer_get_public_key(peer_data_a->peer),
nm_wireguard_peer_get_public_key(peer_data_b->peer));
}
static guint
_peer_data_hash(gconstpointer ptr)
{
const PeerData *peer_data = ptr;
return nm_hash_str(nm_wireguard_peer_get_public_key(peer_data->peer));
}
static PeerData *
_peers_find(NMDeviceWireGuardPrivate *priv, NMWireGuardPeer *peer)
{
nm_assert(peer);
G_STATIC_ASSERT_EXPR(G_STRUCT_OFFSET(PeerData, peer) == 0);
return g_hash_table_lookup(priv->peers, &peer);
}
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
static guint
_peers_resolving_cnt(NMDeviceWireGuardPrivate *priv)
{
nm_assert(priv);
#if NM_MORE_ASSERTS > 3
{
PeerData *peer_data;
guint cnt = 0;
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers) {
if (peer_data->ep_resolv.cancellable)
cnt++;
}
nm_assert(cnt == priv->peers_resolving_cnt);
}
#endif
return priv->peers_resolving_cnt;
}
static void
_peers_resolving_cnt_decrement(NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
nm_assert(priv);
nm_assert(priv->peers_resolving_cnt > 0);
priv->peers_resolving_cnt--;
nm_assert(_peers_resolving_cnt(priv) == priv->peers_resolving_cnt);
if (priv->peers_resolving_cnt == 0) {
if (nm_device_get_state(NM_DEVICE(self)) == NM_DEVICE_STATE_CONFIG) {
_LOGT(LOGD_DEVICE,
"activation delayed to resolve DNS names of peers: completed, proceed now");
nm_device_activate_schedule_stage2_device_config(NM_DEVICE(self), FALSE);
}
}
}
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static void
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
_peers_remove(NMDeviceWireGuard *self, PeerData *peer_data)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
{
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert(peer_data);
nm_assert(g_hash_table_lookup(priv->peers, peer_data) == peer_data);
if (!g_hash_table_remove(priv->peers, peer_data))
nm_assert_not_reached();
c_list_unlink_stale(&peer_data->lst_peers);
nm_wireguard_peer_unref(peer_data->peer);
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
if (nm_clear_g_cancellable(&peer_data->ep_resolv.cancellable))
_peers_resolving_cnt_decrement(self);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
g_slice_free(PeerData, peer_data);
wireguard: fix use-after free in _peers_remove() (cherry picked from commit 85c26341a280b1234cf73c6537b0bae55fb3adbf)
2019-08-03 12:27:57 +02:00
if (c_list_is_empty(&priv->lst_peers_head)) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_clear_g_source(&priv->resolve_next_try_id);
nm_clear_g_source(&priv->link_config_delayed_id);
}
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
nm_assert(_peers_resolving_cnt(priv) == priv->peers_resolving_cnt);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
static PeerData *
_peers_add(NMDeviceWireGuard *self, NMWireGuardPeer *peer)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert(peer);
nm_assert(nm_wireguard_peer_is_sealed(peer));
nm_assert(!_peers_find(priv, peer));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
peer_data = g_slice_new(PeerData);
*peer_data = (PeerData){
.self = self,
.peer = nm_wireguard_peer_ref(peer),
.ep_resolv =
{
.sockaddr = NM_SOCK_ADDR_UNION_INIT_UNSPEC,
},
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
c_list_link_tail(&priv->lst_peers_head, &peer_data->lst_peers);
if (!nm_g_hash_table_add(priv->peers, peer_data))
nm_assert_not_reached();
return peer_data;
}
static gboolean
_peers_resolve_retry_timeout(gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = user_data;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gint64 now;
gint64 next;
priv->resolve_next_try_id = 0;
_LOGT(LOGD_DEVICE, "wireguard-peers: rechecking peer endpoints...");
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
now = nm_utils_get_monotonic_timestamp_nsec();
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
next = G_MAXINT64;
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers) {
if (peer_data->ep_resolv.next_try_at_nsec <= 0)
continue;
if (peer_data->ep_resolv.cancellable) {
/* we are currently resolving a name. We don't need the global
* watchdog to guard this peer. No need to adjust @next for
* this one, when the currently ongoing resolving completes, we
* may reschedule. Skip. */
continue;
}
if (peer_data->ep_resolv.next_try_at_nsec == NEXT_TRY_AT_NSEC_ASAP
|| now >= peer_data->ep_resolv.next_try_at_nsec) {
_peers_resolve_start(self, peer_data);
/* same here. Now we are resolving. We don't need the global
* watchdog. Skip w.r.t. finding @next. */
continue;
}
if (next > peer_data->ep_resolv.next_try_at_nsec)
next = peer_data->ep_resolv.next_try_at_nsec;
}
if (next < G_MAXINT64)
_peers_resolve_retry_reschedule(self, next);
return G_SOURCE_REMOVE;
}
static void
_peers_resolve_retry_reschedule(NMDeviceWireGuard *self, gint64 new_next_try_at_nsec)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
guint32 interval_ms;
gint64 now;
nm_assert(new_next_try_at_nsec > 0);
nm_assert(new_next_try_at_nsec != NEXT_TRY_AT_NSEC_ASAP);
if (priv->resolve_next_try_id && priv->resolve_next_try_at <= new_next_try_at_nsec) {
/* we already have an earlier timeout scheduled (possibly for
* another peer that expires sooner). Don't reschedule now.
* Even if the scheduled timeout expires too early, we will
* compute the right next-timeout and reschedule then. */
return;
}
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
now = nm_utils_get_monotonic_timestamp_nsec();
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/* schedule at most one day ahead. No problem if we expire earlier
* than expected. Also, rate-limit to 500 msec. */
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
interval_ms = NM_CLAMP((new_next_try_at_nsec - now) / NM_UTILS_NSEC_PER_MSEC,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
(gint64) 500,
clang-format: reformat code with clang 12 The format depends on the version of the tool. Now that Fedora 34 is released, update to clang 12 (clang-tools-extra-12.0.0-0.3.rc1.fc34.x86_64).
2021-05-03 21:48:58 +02:00
(gint64) (24 * 60 * 60 * 1000));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_LOGT(LOGD_DEVICE,
"wireguard-peers: schedule rechecking peer endpoints in %u msec",
interval_ms);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_clear_g_source(&priv->resolve_next_try_id);
priv->resolve_next_try_at = new_next_try_at_nsec;
priv->resolve_next_try_id = g_timeout_add(interval_ms, _peers_resolve_retry_timeout, self);
}
static void
_peers_resolve_retry_reschedule_for_peer(NMDeviceWireGuard *self,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gint64 retry_in_msec)
{
nm_assert(retry_in_msec >= 0);
if (retry_in_msec == RETRY_IN_MSEC_ASAP) {
_peers_resolve_start(self, peer_data);
return;
}
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
peer_data->ep_resolv.next_try_at_nsec =
nm_utils_get_monotonic_timestamp_nsec() + (retry_in_msec * NM_UTILS_NSEC_PER_MSEC);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_peers_resolve_retry_reschedule(self, peer_data->ep_resolv.next_try_at_nsec);
}
static gint64
_peers_retry_in_msec(PeerData *peer_data, gboolean after_failure)
{
if (peer_data->ep_resolv.next_try_at_nsec == NEXT_TRY_AT_NSEC_ASAP) {
peer_data->ep_resolv.resolv_fail_count = 0;
return RETRY_IN_MSEC_ASAP;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (after_failure) {
if (peer_data->ep_resolv.resolv_fail_count < G_MAXUINT)
peer_data->ep_resolv.resolv_fail_count++;
} else
peer_data->ep_resolv.resolv_fail_count = 0;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (!after_failure)
return RETRY_IN_MSEC_MAX;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (peer_data->ep_resolv.resolv_fail_count > 20)
return RETRY_IN_MSEC_MAX;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/* double the retry-time, starting with one second. */
return NM_MIN(RETRY_IN_MSEC_MAX, (1u << peer_data->ep_resolv.resolv_fail_count) * 500);
}
static void
_peers_resolve_cb(GObject *source_object, GAsyncResult *res, gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self;
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
NMDeviceWireGuardPrivate *priv;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data;
gs_free_error GError *resolv_error = NULL;
GList *list;
gboolean changed;
NMSockAddrUnion sockaddr;
gint64 retry_in_msec;
char s_sockaddr[100];
char s_retry[100];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
list = g_resolver_lookup_by_name_finish(G_RESOLVER(source_object), res, &resolv_error);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
all: add nm_utils_error_is_cancelled() and nm_utils_error_is_cancelled_or_disposing() Most callers would pass FALSE to nm_utils_error_is_cancelled(). That's not very useful. Split the two functions and have nm_utils_error_is_cancelled() and nm_utils_error_is_cancelled_is_disposing().
2020-01-23 10:36:24 +01:00
if (nm_utils_error_is_cancelled(resolv_error))
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
return;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
peer_data = user_data;
self = peer_data->self;
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
if (nm_clear_g_object(&peer_data->ep_resolv.cancellable))
_peers_resolving_cnt_decrement(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert((!resolv_error) != (!list));
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
nm_assert(_peers_resolving_cnt(priv) == priv->peers_resolving_cnt);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
#define _retry_in_msec_to_string(retry_in_msec, s_retry) \
({ \
gint64 _retry_in_msec = (retry_in_msec); \
\
_retry_in_msec == RETRY_IN_MSEC_ASAP \
? "right away" \
: nm_sprintf_buf(s_retry, "in %" G_GINT64_FORMAT " msec", _retry_in_msec); \
})
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (resolv_error
&& !g_error_matches(resolv_error, G_RESOLVER_ERROR, G_RESOLVER_ERROR_NOT_FOUND)) {
retry_in_msec = _peers_retry_in_msec(peer_data, TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_LOGT(LOGD_DEVICE,
"wireguard-peer[%s]: failure to resolve endpoint \"%s\": %s (retry %s)",
nm_wireguard_peer_get_public_key(peer_data->peer),
nm_wireguard_peer_get_endpoint(peer_data->peer),
resolv_error->message,
_retry_in_msec_to_string(retry_in_msec, s_retry));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_peers_resolve_retry_reschedule_for_peer(self, peer_data, retry_in_msec);
return;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
sockaddr = (NMSockAddrUnion) NM_SOCK_ADDR_UNION_INIT_UNSPEC;
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
changed = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (!resolv_error) {
GList *iter;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
for (iter = list; iter; iter = iter->next) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GInetAddress *a = iter->data;
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
NMSockAddrUnion sockaddr_tmp;
NMSockAddrUnion *s;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
s = sockaddr.sa.sa_family == AF_UNSPEC ? &sockaddr : &sockaddr_tmp;
switch (g_inet_address_get_family(a)) {
case G_SOCKET_FAMILY_IPV4:
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert(g_inet_address_get_native_size(a) == sizeof(struct in_addr));
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
s->in = (struct sockaddr_in){
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
.sin_family = AF_INET,
.sin_port = htons(nm_sock_addr_endpoint_get_port(
_nm_wireguard_peer_get_endpoint(peer_data->peer))),
};
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
memcpy(&s->in.sin_addr, g_inet_address_to_bytes(a), sizeof(struct in_addr));
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
break;
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
case G_SOCKET_FAMILY_IPV6:
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert(g_inet_address_get_native_size(a) == sizeof(struct in6_addr));
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
s->in6 = (struct sockaddr_in6){
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
.sin6_family = AF_INET6,
.sin6_port = htons(nm_sock_addr_endpoint_get_port(
_nm_wireguard_peer_get_endpoint(peer_data->peer))),
.sin6_scope_id = 0,
.sin6_flowinfo = 0,
};
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
memcpy(&s->in6.sin6_addr, g_inet_address_to_bytes(a), sizeof(struct in6_addr));
break;
default:
continue;
}
changed = TRUE;
if (peer_data->ep_resolv.sockaddr.sa.sa_family == AF_UNSPEC)
break;
if (nm_sock_addr_union_cmp(&peer_data->ep_resolv.sockaddr, &sockaddr) == 0) {
changed = FALSE;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
break;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
g_list_free_full(list, g_object_unref);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (sockaddr.sa.sa_family == AF_UNSPEC) {
/* we failed to resolve the name. There is no need to reset the previous
* sockaddr. Either it was already AF_UNSPEC, or we had a good name
* from resolving before. In that case, we don't want to throw away
* a possibly good IP address, since WireGuard supports automatic roaming
* anyway. Either the IP address is still good (and we would wrongly
* reject it), or it isn't -- in which case it does not hurt much. */
wireguard: prefer last resolved IP from resolving endpoint from DNS We periodically re-resolve the DNS name for entpoints. Since WireGuard has no concept of being connected, we want to eventually pick up if the DNS name resolves to a different IP address. However, on resolution failure, we will never clear the endpoint we already have. Thus, resolving names can only give a better endpoint, not remove an IP address entirely. DNS names might do Round-Robin load distribution and the name of the endpoint might resolve to multiple IP addresses. Improve to stick to the IP address that we already have -- provided that the IP address is still among the new resolution result. Otherwise, we continue to pick the first IP address that was resolved. (cherry picked from commit 98348ee5396dde5756fbb82ebf16b90790b6b32d)
2021-02-13 15:47:31 +01:00
} else if (changed)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
peer_data->ep_resolv.sockaddr = sockaddr;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (resolv_error || peer_data->ep_resolv.sockaddr.sa.sa_family == AF_UNSPEC) {
/* while it technically did not fail, something is probably odd. Retry frequently to
* resolve the name, like we would do for normal failures. */
retry_in_msec = _peers_retry_in_msec(peer_data, TRUE);
_LOGT(LOGD_DEVICE,
"wireguard-peer[%s]: no %sresults for endpoint \"%s\" (retry %s)",
nm_wireguard_peer_get_public_key(peer_data->peer),
resolv_error ? "" : "suitable ",
nm_wireguard_peer_get_endpoint(peer_data->peer),
_retry_in_msec_to_string(retry_in_msec, s_retry));
} else {
retry_in_msec = _peers_retry_in_msec(peer_data, FALSE);
_LOGT(LOGD_DEVICE,
"wireguard-peer[%s]: endpoint \"%s\" resolved to %s (retry %s)",
nm_wireguard_peer_get_public_key(peer_data->peer),
nm_wireguard_peer_get_endpoint(peer_data->peer),
nm_sock_addr_union_to_string(&peer_data->ep_resolv.sockaddr,
s_sockaddr,
sizeof(s_sockaddr)),
_retry_in_msec_to_string(retry_in_msec, s_retry));
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_peers_resolve_retry_reschedule_for_peer(self, peer_data, retry_in_msec);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (changed) {
/* schedule the job in the background, to give multiple resolve events time
* to complete. */
nm_clear_g_source(&priv->link_config_delayed_id);
priv->link_config_delayed_id = g_idle_add_full(G_PRIORITY_DEFAULT_IDLE + 1,
link_config_delayed_resolver_cb,
self,
NULL);
}
}
static void
_peers_resolve_start(NMDeviceWireGuard *self, PeerData *peer_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gs_unref_object GResolver *resolver = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *host;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
resolver = g_resolver_get_default();
nm_assert(!peer_data->ep_resolv.cancellable);
peer_data->ep_resolv.cancellable = g_cancellable_new();
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
priv->peers_resolving_cnt++;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/* set a special next-try timestamp. It is positive, and indicates
* that we are in the process of trying.
* This timestamp however already lies in the past, but that is correct,
* because we are currently in the process of trying. We will determine
* a next-try timestamp once the try completes. */
peer_data->ep_resolv.next_try_at_nsec = NEXT_TRY_AT_NSEC_PAST;
host = nm_sock_addr_endpoint_get_host(_nm_wireguard_peer_get_endpoint(peer_data->peer));
g_resolver_lookup_by_name_async(resolver,
host,
peer_data->ep_resolv.cancellable,
_peers_resolve_cb,
peer_data);
_LOGT(LOGD_DEVICE,
"wireguard-peer[%s]: resolving name \"%s\" for endpoint \"%s\"...",
nm_wireguard_peer_get_public_key(peer_data->peer),
host,
nm_wireguard_peer_get_endpoint(peer_data->peer));
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
nm_assert(_peers_resolving_cnt(priv) == priv->peers_resolving_cnt);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
static void
_peers_resolve_reresolve_all(NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers) {
if (peer_data->ep_resolv.cancellable) {
/* remember to retry when the currently ongoing request completes. */
peer_data->ep_resolv.next_try_at_nsec = NEXT_TRY_AT_NSEC_ASAP;
} else if (peer_data->ep_resolv.next_try_at_nsec <= 0) {
/* this peer does not require resolving the name. Skip it. */
} else {
/* we have a next-try scheduled. Restart right away. */
peer_data->ep_resolv.resolv_fail_count = 0;
_peers_resolve_start(self, peer_data);
}
}
}
static gboolean
_peers_update(NMDeviceWireGuard *self,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data,
NMWireGuardPeer *peer,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gboolean force_update)
{
nm_auto_unref_wgpeer NMWireGuardPeer *old_peer = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSockAddrEndpoint *old_endpoint;
NMSockAddrEndpoint *endpoint;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gboolean endpoint_changed = FALSE;
gboolean changed;
NMSockAddrUnion sockaddr;
gboolean sockaddr_fixed;
char sockaddr_sbuf[100];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert(peer);
nm_assert(nm_wireguard_peer_is_sealed(peer));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (peer == peer_data->peer && !force_update)
return FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
changed = (nm_wireguard_peer_cmp(peer, peer_data->peer, NM_SETTING_COMPARE_FLAG_EXACT) != 0);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
old_peer = peer_data->peer;
peer_data->peer = nm_wireguard_peer_ref(peer);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
old_endpoint = old_peer ? _nm_wireguard_peer_get_endpoint(old_peer) : NULL;
endpoint = peer ? _nm_wireguard_peer_get_endpoint(peer) : NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
endpoint_changed = (endpoint != old_endpoint
&& (!old_endpoint || !endpoint
|| !nm_streq(nm_sock_addr_endpoint_get_endpoint(old_endpoint),
nm_sock_addr_endpoint_get_endpoint(endpoint))));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (!force_update && !endpoint_changed) {
/* nothing to do. */
return changed;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
sockaddr = (NMSockAddrUnion) NM_SOCK_ADDR_UNION_INIT_UNSPEC;
sockaddr_fixed = TRUE;
if (endpoint && nm_sock_addr_endpoint_get_host(endpoint)) {
if (!nm_sock_addr_endpoint_get_fixed_sockaddr(endpoint, &sockaddr)) {
/* we have an endpoint, but it's not a static IP address. We need to resolve
* the names. */
sockaddr_fixed = FALSE;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (nm_sock_addr_union_cmp(&peer_data->ep_resolv.sockaddr, &sockaddr) != 0)
changed = TRUE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
if (nm_clear_g_cancellable(&peer_data->ep_resolv.cancellable))
_peers_resolving_cnt_decrement(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
peer_data->ep_resolv = (PeerEndpointResolveData){
.sockaddr = sockaddr,
.resolv_fail_count = 0,
.cancellable = NULL,
.next_try_at_nsec = 0,
};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (!endpoint) {
_LOGT(LOGD_DEVICE,
"wireguard-peer[%s]: no endpoint configured",
nm_wireguard_peer_get_public_key(peer_data->peer));
} else if (!nm_sock_addr_endpoint_get_host(endpoint)) {
_LOGT(LOGD_DEVICE,
"wireguard-peer[%s]: invalid endpoint \"%s\"",
nm_wireguard_peer_get_public_key(peer_data->peer),
nm_sock_addr_endpoint_get_endpoint(endpoint));
} else if (sockaddr_fixed) {
_LOGT(LOGD_DEVICE,
"wireguard-peer[%s]: fixed endpoint \"%s\" (%s)",
nm_wireguard_peer_get_public_key(peer_data->peer),
nm_sock_addr_endpoint_get_endpoint(endpoint),
nm_sock_addr_union_to_string(&peer_data->ep_resolv.sockaddr,
sockaddr_sbuf,
sizeof(sockaddr_sbuf)));
} else
_peers_resolve_start(self, peer_data);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
return changed;
}
static void
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
_peers_remove_all(NMDeviceWireGuard *self)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
{
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
while ((peer_data = c_list_first_entry(&priv->lst_peers_head, PeerData, lst_peers)))
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
_peers_remove(self, peer_data);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
static void
_peers_update_all(NMDeviceWireGuard *self, NMSettingWireGuard *s_wg, gboolean *out_peers_removed)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
PeerData *peer_data_safe;
PeerData *peer_data;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
guint i, n;
gboolean peers_removed = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers)
peer_data->dirty_update_all = TRUE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
n = nm_setting_wireguard_get_peers_len(s_wg);
for (i = 0; i < n; i++) {
NMWireGuardPeer *peer = nm_setting_wireguard_get_peer(s_wg, i);
gboolean added = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
peer_data = _peers_find(priv, peer);
if (!peer_data) {
peer_data = _peers_add(self, peer);
added = TRUE;
}
_peers_update(self, peer_data, peer, added);
peer_data->dirty_update_all = FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
c_list_for_each_entry_safe (peer_data, peer_data_safe, &priv->lst_peers_head, lst_peers) {
if (peer_data->dirty_update_all) {
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
_peers_remove(self, peer_data);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
peers_removed = TRUE;
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_SET_OUT(out_peers_removed, peers_removed);
}
static void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_peers_get_platform_list(NMDeviceWireGuardPrivate *priv,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
LinkConfigMode config_mode,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMPWireGuardPeer **out_peers,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMPlatformWireGuardChangePeerFlags **out_peer_flags,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
guint *out_len,
GArray **out_allowed_ips_data)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_free NMPWireGuardPeer *plpeers = NULL;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gs_free NMPlatformWireGuardChangePeerFlags *plpeer_flags = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
gs_unref_array GArray *allowed_ips = NULL;
PeerData *peer_data;
guint i_good;
guint n_aip;
guint i_aip;
guint len;
guint i;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert(out_peers && !*out_peers);
nm_assert(out_peer_flags && !*out_peer_flags);
nm_assert(out_len && *out_len == 0);
nm_assert(out_allowed_ips_data && !*out_allowed_ips_data);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
len = g_hash_table_size(priv->peers);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_assert(len == c_list_length(&priv->lst_peers_head));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (len == 0)
return;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
plpeers = g_new0(NMPWireGuardPeer, len);
plpeer_flags = g_new0(NMPlatformWireGuardChangePeerFlags, len);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
i_good = 0;
c_list_for_each_entry (peer_data, &priv->lst_peers_head, lst_peers) {
NMPlatformWireGuardChangePeerFlags *plf = &plpeer_flags[i_good];
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMPWireGuardPeer *plp = &plpeers[i_good];
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMSettingSecretFlags psk_secret_flags;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: rename and expose nm_utils_base64secret_decode() in libnm A NetworkManager client requires an API to validate and decode a base64 secret -- like it is used by WireGuard. If we don't have this as part of the API, it's inconvenient. Expose it. Rename it from _nm_utils_wireguard_decode_key(), to give it a more general name. Also, rename _nm_utils_wireguard_normalize_key() to nm_utils_base64secret_normalize(). But this one we keep as internal API. The user will care more about validating and decoding the base64 key. To convert the key back to base64, we don't need a public API in libnm. This is another ABI change since 1.16-rc1. (cherry picked from commit e46ba0186720bfe5e31dcad9a5001a415deb9ce6)
2019-03-02 17:10:25 +01:00
if (!nm_utils_base64secret_decode(nm_wireguard_peer_get_public_key(peer_data->peer),
sizeof(plp->public_key),
plp->public_key))
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
continue;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
*plf = NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_NONE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
plp->persistent_keepalive_interval =
nm_wireguard_peer_get_persistent_keepalive(peer_data->peer);
if (NM_IN_SET(config_mode, LINK_CONFIG_MODE_FULL, LINK_CONFIG_MODE_REAPPLY))
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_KEEPALIVE_INTERVAL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
/* if the peer has an endpoint but it is not yet resolved (not ready),
* we still configure it and leave the endpoint unspecified. Later,
* when we can resolve the endpoint, we will update. */
plp->endpoint = peer_data->ep_resolv.sockaddr;
if (plp->endpoint.sa.sa_family == AF_UNSPEC) {
/* we don't actually ever clear endpoints, if we don't have better information. */
} else
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ENDPOINT;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (NM_IN_SET(config_mode, LINK_CONFIG_MODE_FULL, LINK_CONFIG_MODE_REAPPLY)) {
psk_secret_flags = nm_wireguard_peer_get_preshared_key_flags(peer_data->peer);
if (!NM_FLAGS_HAS(psk_secret_flags, NM_SETTING_SECRET_FLAG_NOT_REQUIRED)) {
libnm: rename and expose nm_utils_base64secret_decode() in libnm A NetworkManager client requires an API to validate and decode a base64 secret -- like it is used by WireGuard. If we don't have this as part of the API, it's inconvenient. Expose it. Rename it from _nm_utils_wireguard_decode_key(), to give it a more general name. Also, rename _nm_utils_wireguard_normalize_key() to nm_utils_base64secret_normalize(). But this one we keep as internal API. The user will care more about validating and decoding the base64 key. To convert the key back to base64, we don't need a public API in libnm. This is another ABI change since 1.16-rc1. (cherry picked from commit e46ba0186720bfe5e31dcad9a5001a415deb9ce6)
2019-03-02 17:10:25 +01:00
if (!nm_utils_base64secret_decode(
nm_wireguard_peer_get_preshared_key(peer_data->peer),
sizeof(plp->preshared_key),
plp->preshared_key)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
&& config_mode == LINK_CONFIG_MODE_FULL)
goto skip;
}
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_PRESHARED_KEY;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (NM_IN_SET(config_mode, LINK_CONFIG_MODE_FULL, LINK_CONFIG_MODE_REAPPLY)
&& ((n_aip = nm_wireguard_peer_get_allowed_ips_len(peer_data->peer)) > 0)) {
if (!allowed_ips)
allowed_ips = g_array_new(FALSE, FALSE, sizeof(NMPWireGuardAllowedIP));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
*plf |= NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_HAS_ALLOWEDIPS
| NM_PLATFORM_WIREGUARD_CHANGE_PEER_FLAG_REPLACE_ALLOWEDIPS;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
plp->_construct_idx_start = allowed_ips->len;
for (i_aip = 0; i_aip < n_aip; i_aip++) {
const char *aip;
NMIPAddr addrbin = {};
int addr_family;
gboolean valid;
int prefix;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
aip = nm_wireguard_peer_get_allowed_ip(peer_data->peer, i_aip, &valid);
if (!valid
|| !nm_utils_parse_inaddr_prefix_bin(AF_UNSPEC,
aip,
&addr_family,
&addrbin,
&prefix)) {
/* the address is really not expected to be invalid, because then
* the connection would not verify. Anyway, silently skip it. */
continue;
}
if (prefix == -1)
prefix = addr_family == AF_INET ? 32 : 128;
g_array_append_val(allowed_ips,
((NMPWireGuardAllowedIP){
.family = addr_family,
.mask = prefix,
.addr = addrbin,
}));
}
plp->_construct_idx_end = allowed_ips->len;
}
i_good++;
continue;
skip:
memset(plp, 0, sizeof(*plp));
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (i_good == 0)
return;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
for (i = 0; i < i_good; i++) {
NMPWireGuardPeer *plp = &plpeers[i];
guint l;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (plp->_construct_idx_end == 0) {
nm_assert(plp->_construct_idx_start == 0);
plp->allowed_ips = NULL;
plp->allowed_ips_len = 0;
} else {
nm_assert(plp->_construct_idx_start < plp->_construct_idx_end);
l = plp->_construct_idx_end - plp->_construct_idx_start;
plp->allowed_ips =
&g_array_index(allowed_ips, NMPWireGuardAllowedIP, plp->_construct_idx_start);
plp->allowed_ips_len = l;
}
}
*out_peers = g_steal_pointer(&plpeers);
all/style: remove duplicate semicolon (";;") in sources
2020-09-23 12:43:47 +02:00
*out_peer_flags = g_steal_pointer(&plpeer_flags);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
*out_len = i_good;
*out_allowed_ips_data = g_steal_pointer(&allowed_ips);
}
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static void
update_properties(NMDevice *device)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self;
NMDeviceWireGuardPrivate *priv;
const NMPlatformLink *plink;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
const NMPlatformLnkWireGuard *props = NULL;
int ifindex;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
g_return_if_fail(NM_IS_DEVICE_WIREGUARD(device));
self = NM_DEVICE_WIREGUARD(device);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
ifindex = nm_device_get_ifindex(device);
props = nm_platform_link_get_lnk_wireguard(nm_device_get_platform(device), ifindex, &plink);
if (!props) {
_LOGW(LOGD_PLATFORM, "could not get wireguard properties");
return;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
g_object_freeze_notify(G_OBJECT(device));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#define CHECK_PROPERTY_CHANGED(field, prop) \
G_STMT_START \
{ \
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (priv->lnk_curr.field != props->field) { \
priv->lnk_curr.field = props->field; \
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
_notify(self, prop); \
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
} \
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
} \
G_STMT_END
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
#define CHECK_PROPERTY_CHANGED_ARRAY(field, prop) \
G_STMT_START \
{ \
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (memcmp(&priv->lnk_curr.field, &props->field, sizeof(priv->lnk_curr.field)) != 0) { \
memcpy(&priv->lnk_curr.field, &props->field, sizeof(priv->lnk_curr.field)); \
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
_notify(self, prop); \
} \
} \
G_STMT_END
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
CHECK_PROPERTY_CHANGED_ARRAY(public_key, PROP_PUBLIC_KEY);
CHECK_PROPERTY_CHANGED(listen_port, PROP_LISTEN_PORT);
CHECK_PROPERTY_CHANGED(fwmark, PROP_FWMARK);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
g_object_thaw_notify(G_OBJECT(device));
}
static void
link_changed(NMDevice *device, const NMPlatformLink *pllink)
{
NM_DEVICE_CLASS(nm_device_wireguard_parent_class)->link_changed(device, pllink);
update_properties(device);
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static NMDeviceCapabilities
get_generic_capabilities(NMDevice *dev)
{
return NM_DEVICE_CAP_IS_SOFTWARE;
}
/*****************************************************************************/
static gboolean
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
create_and_realize(NMDevice *device,
NMConnection *connection,
NMDevice *parent,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
const NMPlatformLink **out_plink,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **error)
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
{
const char *iface = nm_device_get_iface(device);
int r;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_return_val_if_fail(iface, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
r = nm_platform_link_wireguard_add(nm_device_get_platform(device), iface, out_plink);
if (r < 0) {
g_set_error(error,
NM_DEVICE_ERROR,
NM_DEVICE_ERROR_CREATION_FAILED,
"Failed to create WireGuard interface '%s' for '%s': %s",
iface,
nm_connection_get_id(connection),
nm_strerror(r));
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
return TRUE;
}
/*****************************************************************************/
static void
_secrets_cancel(NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
if (priv->secrets_call_id)
nm_act_request_cancel_secrets(NULL, priv->secrets_call_id);
nm_assert(!priv->secrets_call_id);
}
static void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_secrets_cb(NMActRequest *req,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMActRequestGetSecretsCallId *call_id,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingsConnection *connection,
GError *error,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
gpointer user_data)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(user_data);
NMDevice *device = NM_DEVICE(self);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceWireGuardPrivate *priv;
g_return_if_fail(NM_IS_DEVICE_WIREGUARD(self));
g_return_if_fail(NM_IS_ACT_REQUEST(req));
priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
g_return_if_fail(priv->secrets_call_id == call_id);
priv->secrets_call_id = NULL;
if (g_error_matches(error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
return;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_return_if_fail(req == nm_device_get_act_request(device));
g_return_if_fail(nm_device_get_state(device) == NM_DEVICE_STATE_NEED_AUTH);
g_return_if_fail(nm_act_request_get_settings_connection(req) == connection);
if (error) {
_LOGW(LOGD_ETHER, "%s", error->message);
nm_device_state_changed(device, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_NO_SECRETS);
device: let devices call stage1 again after being ready to proceed I am about to change the when stage1 gets postponed, then the way to proceed it is to schedule stage1 again (instead of scheduling stage2). The reason is that stage1 handling should be reentrant and we should keep entering it until there is no more reason to postpone it. If a subclass postpones stage1 and then later progresses it by directly scheduling stage2, then only the subclass is in control over postponing stage 2. Instead, anybody should be able to delay stage2 independently. That can only work if everybody signals readyness to proceed by scheduling stage1 again.
2019-08-22 10:43:22 +02:00
return;
}
device: allow scheduling nm_device_activate_schedule_stage1_prepare() right away There was only API to schedule the stage on an idle handler. Sometimes, we are just in the right situation to schedule the stage right away. It should be possibly to avoid going through the extra hop. For now, none of the caller makes use of this. So, there isn't any actual change in behavior. But by adding this possibility, we may do use in the future.
2020-02-28 13:55:40 +01:00
nm_device_activate_schedule_stage1_device_prepare(device, FALSE);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
static void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
_secrets_get_secrets(NMDeviceWireGuard *self,
const char *setting_name,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMSecretAgentGetSecretsFlags flags,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *const *hints)
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMActRequest *req;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
_secrets_cancel(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
req = nm_device_get_act_request(NM_DEVICE(self));
g_return_if_fail(NM_IS_ACT_REQUEST(req));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
priv->secrets_call_id =
nm_act_request_get_secrets(req, TRUE, setting_name, flags, hints, _secrets_cb, self);
g_return_if_fail(priv->secrets_call_id);
}
static NMActStageReturn
_secrets_handle_auth_or_fail(NMDeviceWireGuard *self, NMActRequest *req, gboolean new_secrets)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *applied_connection;
const char *setting_name;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
gs_unref_ptrarray GPtrArray *hints = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (!nm_device_auth_retries_try_next(NM_DEVICE(self)))
return NM_ACT_STAGE_RETURN_FAILURE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
nm_device_state_changed(NM_DEVICE(self),
NM_DEVICE_STATE_NEED_AUTH,
NM_DEVICE_STATE_REASON_NONE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
nm_active_connection_clear_secrets(NM_ACTIVE_CONNECTION(req));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
applied_connection = nm_act_request_get_applied_connection(req);
setting_name = nm_connection_need_secrets(applied_connection, &hints);
if (!setting_name) {
_LOGI(LOGD_DEVICE, "Cleared secrets, but setting didn't need any secrets.");
return NM_ACT_STAGE_RETURN_FAILURE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (hints)
g_ptr_array_add(hints, NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
_secrets_get_secrets(self,
setting_name,
NM_SECRET_AGENT_GET_SECRETS_FLAG_ALLOW_INTERACTION
| (new_secrets ? NM_SECRET_AGENT_GET_SECRETS_FLAG_REQUEST_NEW : 0),
(hints ? (const char *const *) hints->pdata : NULL));
return NM_ACT_STAGE_RETURN_POSTPONE;
}
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static void
_dns_config_changed(NMDnsManager *dns_manager, NMDeviceWireGuard *self)
{
/* when the DNS configuration changes, we re-resolve the peer addresses.
*
* Possibly, we should also do that when the default-route changes, but it's
* hard to figure out when that happens. */
_peers_resolve_reresolve_all(self);
}
/*****************************************************************************/
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static NMActStageReturn
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
link_config(NMDeviceWireGuard *self,
const char *reason,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
LinkConfigMode config_mode,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceStateReason *out_failure_reason)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
nm_auto_bzero_secret_ptr NMSecretPtr wg_lnk_clear_private_key = NM_SECRET_PTR_INIT();
NMSettingWireGuard *s_wg;
NMConnection *connection;
NMActStageReturn ret;
gs_unref_array GArray *allowed_ips_data = NULL;
NMPlatformLnkWireGuard wg_lnk;
gs_free NMPWireGuardPeer *plpeers = NULL;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gs_free NMPlatformWireGuardChangePeerFlags *plpeer_flags = NULL;
guint plpeers_len = 0;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *setting_name;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
gboolean peers_removed;
NMPlatformWireGuardChangeFlags wg_change_flags;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
int ifindex;
int r;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_SET_OUT(out_failure_reason, NM_DEVICE_STATE_REASON_NONE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
connection = nm_device_get_applied_connection(NM_DEVICE(self));
s_wg = NM_SETTING_WIREGUARD(nm_connection_get_setting(connection, NM_TYPE_SETTING_WIREGUARD));
g_return_val_if_fail(s_wg, NM_ACT_STAGE_RETURN_FAILURE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
priv->link_config_last_at = nm_utils_get_monotonic_timestamp_nsec();
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_LOGT(LOGD_DEVICE,
"wireguard link config (%s, %s)...",
reason,
_link_config_mode_to_string(config_mode));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
_auto_default_route_init(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (!priv->dns_manager) {
priv->dns_manager = g_object_ref(nm_dns_manager_get());
g_signal_connect(priv->dns_manager,
NM_DNS_MANAGER_CONFIG_CHANGED,
G_CALLBACK(_dns_config_changed),
self);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (NM_IN_SET(config_mode, LINK_CONFIG_MODE_FULL)
&& (setting_name = nm_connection_need_secrets(connection, NULL))) {
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMActRequest *req = nm_device_get_act_request(NM_DEVICE(self));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
_LOGD(LOGD_DEVICE,
"Activation: connection '%s' has security, but secrets are required.",
nm_connection_get_id(connection));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
ret = _secrets_handle_auth_or_fail(self, req, FALSE);
if (ret != NM_ACT_STAGE_RETURN_SUCCESS) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (ret != NM_ACT_STAGE_RETURN_POSTPONE) {
nm_assert(ret == NM_ACT_STAGE_RETURN_FAILURE);
NM_SET_OUT(out_failure_reason, NM_DEVICE_STATE_REASON_NO_SECRETS);
}
return ret;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
ifindex = nm_device_get_ip_ifindex(NM_DEVICE(self));
if (ifindex <= 0) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_SET_OUT(out_failure_reason, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
return NM_ACT_STAGE_RETURN_FAILURE;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_peers_update_all(self, s_wg, &peers_removed);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_lnk = (NMPlatformLnkWireGuard){};
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_change_flags = NM_PLATFORM_WIREGUARD_CHANGE_FLAG_NONE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (NM_IN_SET(config_mode, LINK_CONFIG_MODE_FULL)
|| (NM_IN_SET(config_mode, LINK_CONFIG_MODE_REAPPLY) && peers_removed))
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_REPLACE_PEERS;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (NM_IN_SET(config_mode, LINK_CONFIG_MODE_FULL, LINK_CONFIG_MODE_REAPPLY)) {
device/wireguard: fix separating lines by semicolon in link_config()
2019-07-15 11:00:01 +02:00
wg_lnk.listen_port = nm_setting_wireguard_get_listen_port(s_wg);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_LISTEN_PORT;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wg_lnk.fwmark = priv->auto_default_route_fwmark;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_FWMARK;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: rename and expose nm_utils_base64secret_decode() in libnm A NetworkManager client requires an API to validate and decode a base64 secret -- like it is used by WireGuard. If we don't have this as part of the API, it's inconvenient. Expose it. Rename it from _nm_utils_wireguard_decode_key(), to give it a more general name. Also, rename _nm_utils_wireguard_normalize_key() to nm_utils_base64secret_normalize(). But this one we keep as internal API. The user will care more about validating and decoding the base64 key. To convert the key back to base64, we don't need a public API in libnm. This is another ABI change since 1.16-rc1. (cherry picked from commit e46ba0186720bfe5e31dcad9a5001a415deb9ce6)
2019-03-02 17:10:25 +01:00
if (nm_utils_base64secret_decode(nm_setting_wireguard_get_private_key(s_wg),
sizeof(wg_lnk.private_key),
wg_lnk.private_key)) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
wg_lnk_clear_private_key = NM_SECRET_PTR_ARRAY(wg_lnk.private_key);
wg_change_flags |= NM_PLATFORM_WIREGUARD_CHANGE_FLAG_HAS_PRIVATE_KEY;
} else {
if (NM_IN_SET(config_mode, LINK_CONFIG_MODE_FULL)) {
_LOGD(LOGD_DEVICE, "the provided private-key is invalid");
NM_SET_OUT(out_failure_reason, NM_DEVICE_STATE_REASON_NO_SECRETS);
return NM_ACT_STAGE_RETURN_FAILURE;
}
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_peers_get_platform_list(priv,
config_mode,
&plpeers,
&plpeer_flags,
&plpeers_len,
&allowed_ips_data);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
r = nm_platform_link_wireguard_change(nm_device_get_platform(NM_DEVICE(self)),
ifindex,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
&wg_lnk,
plpeers,
plpeer_flags,
plpeers_len,
wg_change_flags);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
device/wireguard: fix explicit_bzero() call on peers buffer in link_config() Correctly warned by coverity. (cherry picked from commit 458a2edbb24061bfd9532594e447da2e23819092)
2019-08-02 09:16:34 +02:00
nm_explicit_bzero(plpeers, sizeof(plpeers[0]) * plpeers_len);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
if (r < 0) {
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_SET_OUT(out_failure_reason, NM_DEVICE_STATE_REASON_CONFIG_FAILED);
return NM_ACT_STAGE_RETURN_FAILURE;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
return NM_ACT_STAGE_RETURN_SUCCESS;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static void
link_config_delayed(NMDeviceWireGuard *self, const char *reason)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
gint64 now;
priv->link_config_delayed_id = 0;
if (priv->link_config_last_at != 0) {
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
now = nm_utils_get_monotonic_timestamp_nsec();
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (now < priv->link_config_last_at + LINK_CONFIG_RATE_LIMIT_NSEC) {
all: codespell fixes Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2'). (cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
2019-03-11 12:00:32 +01:00
/* we ratelimit calls to link_config(), because we call this whenever a resolver
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
* completes. */
_LOGT(LOGD_DEVICE, "wireguard link config (%s) (postponed)", reason);
all: rename time related function to spell out nsec/usec/msec/sec The abbreviations "ns" and "ms" seem not very clear to me. Spell them out to nsec/msec. Also, in parts we already used the longer abbreviations, so it wasn't consistent.
2019-12-13 16:54:30 +01:00
priv->link_config_delayed_id =
g_timeout_add(NM_MAX((priv->link_config_last_at + LINK_CONFIG_RATE_LIMIT_NSEC - now)
/ NM_UTILS_NSEC_PER_MSEC,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
(gint64) 1),
link_config_delayed_ratelimit_cb,
self);
return;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
link_config(self, reason, LINK_CONFIG_MODE_ENDPOINTS, NULL);
}
static gboolean
link_config_delayed_ratelimit_cb(gpointer user_data)
{
link_config_delayed(user_data, "after-ratelimiting");
return G_SOURCE_REMOVE;
}
static gboolean
link_config_delayed_resolver_cb(gpointer user_data)
{
link_config_delayed(user_data, "resolver-update");
return G_SOURCE_REMOVE;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
static NMActStageReturn
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
act_stage2_config(NMDevice *device, NMDeviceStateReason *out_failure_reason)
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(device);
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
NMDeviceSysIfaceState sys_iface_state;
NMDeviceStateReason failure_reason;
NMActStageReturn ret;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
sys_iface_state = nm_device_sys_iface_state_get(device);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_EXTERNAL) {
NM_SET_OUT(out_failure_reason, NM_DEVICE_STATE_REASON_NONE);
return NM_ACT_STAGE_RETURN_SUCCESS;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
ret =
link_config(NM_DEVICE_WIREGUARD(device),
device: various code cleanups in devices Mostly just cleanups, there should be no significant change in behavior.
2020-02-27 16:45:16 +01:00
"configure",
(sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_ASSUME) ? LINK_CONFIG_MODE_ASSUME
: LINK_CONFIG_MODE_FULL,
&failure_reason);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
device: various code cleanups in devices Mostly just cleanups, there should be no significant change in behavior.
2020-02-27 16:45:16 +01:00
if (ret == NM_ACT_STAGE_RETURN_FAILURE) {
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
if (sys_iface_state == NM_DEVICE_SYS_IFACE_STATE_ASSUME) {
/* this never fails. */
return NM_ACT_STAGE_RETURN_SUCCESS;
}
device: various code cleanups in devices Mostly just cleanups, there should be no significant change in behavior.
2020-02-27 16:45:16 +01:00
nm_device_state_changed(device, NM_DEVICE_STATE_FAILED, failure_reason);
NM_SET_OUT(out_failure_reason, failure_reason);
return NM_ACT_STAGE_RETURN_FAILURE;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
nm_assert(NM_IN_SET(ret, NM_ACT_STAGE_RETURN_SUCCESS, NM_ACT_STAGE_RETURN_POSTPONE));
if (ret == NM_ACT_STAGE_RETURN_SUCCESS && _peers_resolving_cnt(priv) > 0u) {
_LOGT(LOGD_DEVICE,
"activation delayed to resolve DNS names of peers: resolving and waiting...");
return NM_ACT_STAGE_RETURN_POSTPONE;
}
device: various code cleanups in devices Mostly just cleanups, there should be no significant change in behavior.
2020-02-27 16:45:16 +01:00
return ret;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
static const NML3ConfigData *
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
_get_dev2_ip_config(NMDeviceWireGuard *self, int addr_family)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
nm_auto_unref_l3cd_init NML3ConfigData *l3cd = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *connection;
NMSettingWireGuard *s_wg;
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
guint n_peers;
guint i;
int ip_ifindex;
guint32 route_metric;
guint32 route_table_coerced;
gboolean auto_default_route_enabled;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
_auto_default_route_init(self);
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
connection = nm_device_get_applied_connection(NM_DEVICE(self));
s_wg = NM_SETTING_WIREGUARD(nm_connection_get_setting(connection, NM_TYPE_SETTING_WIREGUARD));
/* Differences to `wg-quick`.
*
* `wg-quick` supports the "Table" setting with 3 modes:
*
* a1) "off": this is what we do with "peer-routes" disabled.
*
* a2) an explicit routing table. This is our behavior with "peer-routes" on. In this case
* we honor the "ipv4.route-table" and "ipv6.route-table" settings. One difference is that
* `wg-quick` would resolve table names from /etc/iproute2/rt_tables. Our connection profiles
all: codespell fixes Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2'). (cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
2019-03-11 12:00:32 +01:00
* only contain table numbers, so that conversion from name to table must have happened
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
* before already.
*
* a3) "auto" (the default). In this case, `wg-quick` would only add the route to the
* main table, if the AllowedIP range is not yet reachable on the link. With "peer-routes"
* enabled, we don't check for that and always add the routes to the main-table
* (with 'ipv4.route-table' and 'ipv6.route-table' set to zero or RT_TABLE_MAIN (254)).
*
* Also, in "auto" mode, `wg-quick` would add special handling for /0 routes and pick
* an empty table to configure policy routing to avoid routing loops. This handling
* of routing-loops via policy routing is not yet done, and requires a separate solution
* from constructing the peer-routes here.
*/
if (!nm_setting_wireguard_get_peer_routes(s_wg))
return NULL;
ip_ifindex = nm_device_get_ip_ifindex(NM_DEVICE(self));
if (ip_ifindex <= 0)
return NULL;
route_metric = nm_device_get_route_metric(NM_DEVICE(self), addr_family);
device: support reapplying route-table Changing "ipv4.route-table" and "ipv6.route-table" was not allowed during reapply. The main difficulty for supporting that is changing the sync-mode. With route-table 0, we don't sync all tables but only the main table. So, when reapply changes from full-sync to no-full-sync, it's slightly more complicated. But it's probably not too complicated either. The change from no-full-sync to full-sync is simple: we just start doing a full-sync. The reverse change is slightly more complicated, because we need to do one last full-sync, to get rid of routes that we configured on those other tables.
2019-04-30 14:01:10 +02:00
route_table_coerced =
nm_platform_route_table_coerce(nm_device_get_route_table(NM_DEVICE(self), addr_family));
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
auto_default_route_enabled = (addr_family == AF_INET) ? priv->auto_default_route_enabled_4
: priv->auto_default_route_enabled_6;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
n_peers = nm_setting_wireguard_get_peers_len(s_wg);
for (i = 0; i < n_peers; i++) {
NMWireGuardPeer *peer = nm_setting_wireguard_get_peer(s_wg, i);
guint n_aips;
guint j;
n_aips = nm_wireguard_peer_get_allowed_ips_len(peer);
for (j = 0; j < n_aips; j++) {
NMPlatformIPXRoute rt;
NMIPAddr addrbin;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *aip;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
gboolean valid;
int prefix;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
guint32 rtable_coerced;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
aip = nm_wireguard_peer_get_allowed_ip(peer, j, &valid);
if (!valid
|| !nm_utils_parse_inaddr_prefix_bin(addr_family, aip, NULL, &addrbin, &prefix))
continue;
if (prefix < 0)
prefix = (addr_family == AF_INET) ? 32 : 128;
wireguard: suppress automatic "wireguard.peer-routes" for default routes if "ipv[46].never-default" is enabled Enabling both peer-routes and never-default conflicts with having AllowedIPs set to a default route. Let never-default win. (cherry picked from commit 5da82ee3eab29fc716b4fcf616c2ae89da748c4c)
2020-04-22 10:57:27 +02:00
if (prefix == 0) {
NMSettingIPConfig *s_ip;
s_ip = nm_connection_get_setting_ip_config(connection, addr_family);
if (nm_setting_ip_config_get_never_default(s_ip))
continue;
}
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
if (!l3cd) {
l3cd = nm_device_create_l3_config_data(NM_DEVICE(self), NM_IP_CONFIG_SOURCE_USER);
nm_l3_config_data_set_flags(l3cd,
NM_L3_CONFIG_DAT_FLAGS_IGNORE_MERGE_NO_DEFAULT_ROUTES);
wireguard: don't let explicit gateway override WireGuard's peer route The profile's "ipv4.gateway" and "ipv6.gateway" has only one real purpose: to define the next hop of a static default route. Usually, when specifying a gateway in this way, the default route from other addressing methods (like DHCPv4 or IPv6 autoconf) gets ignored. If you have a WireGuard peer with "AllowedIPs=0.0.0.0/0" and "wireguard.peer-routes" enabled, NetworkManager would automatically add a route to the peer. Previously, if the user also set a gateway, that route was suppressed. That doesn't feel right. Note that configuring a gateway on a WireGuard profile is likely to be wrong to begin with. At least, unless you take otherwise care to avoid routing loops. If you take care, setting a gateway may work, but it would feel clearer to instead just add an explicit /0 manual route instead. Also, note that usually you don't need a gateway anyway. WireGuard is a Layer 3 (IP) tunnel, where the next hop is alway just the other side of the tunnel. The next hop has little effect on the routes that you configure on a WireGuard interface. What however matters is whether a default route is present or not. Also, an explicit gateway probably works badly with "ipv[46].ip4-auto-default-route", because in that case the automatism should add a /0 peer-route route in a separate routing table. The explicit gateway interferes with that too. Nonetheless, without this patch it's not obvious why the /0 peer route gets suppressed when a gateway is set. Don't allow for that, and always add the peer-route. Probably the profile's gateway setting is still wrong and causes the profile not to work. But at least, you see all routes configured, and it's clearer where the (wrong) default route to the gateway comes from. (cherry picked from commit 115291a46f52ee4adfe85264b9566d216bcb25e8)
2020-04-22 10:46:17 +02:00
}
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
nm_utils_ipx_address_clear_host_address(addr_family, &addrbin, NULL, prefix);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
rtable_coerced = route_table_coerced;
if (prefix == 0 && auto_default_route_enabled) {
/* In auto-default-route mode, we place the default route in a table that
* has the same number as the fwmark. wg-quick does that too. If you don't
* like that, configure the rules and the default-route explicitly in the
* connection profile. */
rtable_coerced = nm_platform_route_table_coerce(priv->auto_default_route_fwmark);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
if (addr_family == AF_INET) {
rt.r4 = (NMPlatformIP4Route){
.network = addrbin.addr4,
.plen = prefix,
.ifindex = ip_ifindex,
.rt_source = NM_IP_CONFIG_SOURCE_USER,
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
.table_coerced = rtable_coerced,
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
.metric = route_metric,
};
} else {
rt.r6 = (NMPlatformIP6Route){
.network = addrbin.addr6,
.plen = prefix,
.ifindex = ip_ifindex,
.rt_source = NM_IP_CONFIG_SOURCE_USER,
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
.table_coerced = rtable_coerced,
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
.metric = route_metric,
};
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
nm_l3_config_data_add_route(l3cd, addr_family, NULL, &rt.rx);
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
if (!l3cd)
return NULL;
return nm_l3_config_data_seal(g_steal_pointer(&l3cd));
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
}
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
static void
act_stage3_ip_config(NMDevice *device, int addr_family)
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
{
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
nm_auto_unref_l3cd const NML3ConfigData *l3cd = NULL;
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
l3cd = _get_dev2_ip_config(NM_DEVICE_WIREGUARD(device), addr_family);
nm_device_devip_set_state(device, addr_family, NM_DEVICE_IP_STATE_READY, l3cd);
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
}
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
static guint32
device: fix setting MTU from connection when limited by parent We try to set only one time the MTU from the connection to not interfere with manual user changes. If at some point the parent interface changes temporarily MTU to a lower value (for example, because the connection was reactivated), the kernel will also lower the MTU on child interface and we will not update it ever again. Add a workaround to this. If we detect that the MTU we want to set from connection is higher that the allowed one, go into a state where we follow the parent MTU until it is possible to set again the desired MTU. This is a bit ugly, but I can't think of any nicer way to do it. https://bugzilla.redhat.com/show_bug.cgi?id=1751079
2019-09-11 10:57:07 +02:00
get_configured_mtu(NMDevice *device, NMDeviceMtuSource *out_source, gboolean *out_force)
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
{
/* When "MTU" for `wg-quick up` is unset, it calls `ip route get` for
* each configured endpoint, to determine the suitable MTU how to reach
* each endpoint.
* For `wg-quick` this works very well, because whenever the script runs it
* determines the best setting at that point in time. It's simply not concerned
* with what happens later (and it's not around anyway).
*
* NetworkManager sticks around, so the right MTU would need to be re-determined
* whenever anything relevant changes. Which basically means, to re-evaluate whenever
* something related to addresses or routing changes (which happens all the time).
*
* The correct MTU indeed depends on the MTU setting of other interfaces (or routes).
* But it's still odd, that activating/deactivating a seemingly unrelated interface
* would trigger an MTU change. It's odd to explain/document and odd to implemented
* -- despite this being the reality.
*
* For now, only support configuring an explicit MTU, or leave the setting untouched.
all: codespell fixes Codespel run with the same arguments as described in commit 58510ed56679 ('docs: misc. typos pt2'). (cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
2019-03-11 12:00:32 +01:00
* The same limitation also applies to other "ip-tunnel" types, where we could use
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
* similar smarts for autodetecting the MTU.
*/
return nm_device_get_configured_mtu_from_connection(device,
NM_TYPE_SETTING_WIREGUARD,
out_source);
}
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
static void
_device_cleanup(NMDeviceWireGuard *self)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
wireguard: delay activation while resolving DNS names for WireGuard peers to avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
2021-01-08 11:09:03 +01:00
_peers_remove_all(self);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
_secrets_cancel(self);
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
priv->auto_default_route_initialized = FALSE;
priv->auto_default_route_priority_initialized = FALSE;
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static void
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
device_state_changed(NMDevice *device,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceState new_state,
NMDeviceState old_state,
NMDeviceStateReason reason)
{
if (new_state <= NM_DEVICE_STATE_ACTIVATED)
return;
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
_device_cleanup(NM_DEVICE_WIREGUARD(device));
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
/*****************************************************************************/
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
static gboolean
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
can_reapply_change(NMDevice *device,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
const char *setting_name,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSetting *s_old,
NMSetting *s_new,
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
GHashTable *diffs,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError **error)
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
{
if (nm_streq(setting_name, NM_SETTING_WIREGUARD_SETTING_NAME)) {
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
/* Most, but not all WireGuard settings can be reapplied. Whitelist.
*
* MTU cannot be reapplied. */
return nm_device_hash_check_invalid_keys(diffs,
NM_SETTING_WIREGUARD_SETTING_NAME,
error,
NM_SETTING_WIREGUARD_FWMARK,
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
NM_SETTING_WIREGUARD_IP4_AUTO_DEFAULT_ROUTE,
NM_SETTING_WIREGUARD_IP6_AUTO_DEFAULT_ROUTE,
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
NM_SETTING_WIREGUARD_LISTEN_PORT,
NM_SETTING_WIREGUARD_PEERS,
wireguard: implement direct "peer-routes" for WireGuard allowed-ips ranges (cherry picked from commit 626beaf83e142fcaff32dbf1662d75af1d826b2d)
2019-03-04 09:31:28 +01:00
NM_SETTING_WIREGUARD_PEER_ROUTES,
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
NM_SETTING_WIREGUARD_PRIVATE_KEY,
NM_SETTING_WIREGUARD_PRIVATE_KEY_FLAGS);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
return NM_DEVICE_CLASS(nm_device_wireguard_parent_class)
->can_reapply_change(device, setting_name, s_old, s_new, diffs, error);
}
static void
reapply_connection(NMDevice *device, NMConnection *con_old, NMConnection *con_new)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(device);
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
NMDeviceState state = nm_device_get_state(device);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NM_DEVICE_CLASS(nm_device_wireguard_parent_class)->reapply_connection(device, con_old, con_new);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
device: allow reapply when the device is activating Allow a reapply of the connection when the device is still activating and ensure that each reapply action is performed only at a given activation stage. For example, the IP configuration is not reactivated if the device is in the prepare stage. https://bugzilla.redhat.com/show_bug.cgi?id=1763062
2019-10-22 16:55:55 +02:00
if (state >= NM_DEVICE_STATE_CONFIG) {
priv->auto_default_route_refresh = TRUE;
link_config(NM_DEVICE_WIREGUARD(device), "reapply", LINK_CONFIG_MODE_REAPPLY, NULL);
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
device: allow reapply when the device is activating Allow a reapply of the connection when the device is still activating and ensure that each reapply action is performed only at a given activation stage. For example, the IP configuration is not reactivated if the device is in the prepare stage. https://bugzilla.redhat.com/show_bug.cgi?id=1763062
2019-10-22 16:55:55 +02:00
if (state >= NM_DEVICE_STATE_IP_CONFIG) {
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
nm_auto_unref_l3cd const NML3ConfigData *l3cd_4 = NULL;
nm_auto_unref_l3cd const NML3ConfigData *l3cd_6 = NULL;
l3cd_4 = _get_dev2_ip_config(self, AF_INET);
l3cd_6 = _get_dev2_ip_config(self, AF_INET6);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
nm_device_devip_set_state(device, AF_INET, NM_DEVICE_IP_STATE_READY, l3cd_4);
nm_device_devip_set_state(device, AF_INET6, NM_DEVICE_IP_STATE_READY, l3cd_6);
device: allow reapply when the device is activating Allow a reapply of the connection when the device is still activating and ensure that each reapply action is performed only at a given activation stage. For example, the IP configuration is not reactivated if the device is in the prepare stage. https://bugzilla.redhat.com/show_bug.cgi?id=1763062
2019-10-22 16:55:55 +02:00
}
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
}
/*****************************************************************************/
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static void
update_connection(NMDevice *device, NMConnection *connection)
{
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(device);
libnm: Use _nm_connection_ensure_setting() Use `_nm_connection_ensure_setting()` to eliminate the duplicated codes. This function will retrieve the specific setting from connection, if not found, create new one and attach to the connection. Signed-off-by: Gris Ge <fge@redhat.com>
2021-08-20 18:40:21 +08:00
NMSettingWireGuard *s_wg = _nm_connection_ensure_setting(connection, NM_TYPE_SETTING_WIREGUARD);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMPObject *obj_wg;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
const NMPObjectLnkWireGuard *olnk_wg;
guint i;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_object_set(s_wg,
NM_SETTING_WIREGUARD_FWMARK,
(guint) priv->lnk_curr.fwmark,
NM_SETTING_WIREGUARD_LISTEN_PORT,
(guint) priv->lnk_curr.listen_port,
NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
obj_wg = NMP_OBJECT_UP_CAST(nm_platform_link_get_lnk_wireguard(nm_device_get_platform(device),
nm_device_get_ip_ifindex(device),
NULL));
if (!obj_wg)
return;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
olnk_wg = &obj_wg->_lnk_wireguard;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
for (i = 0; i < olnk_wg->peers_len; i++) {
nm_auto_unref_wgpeer NMWireGuardPeer *peer = NULL;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const NMPWireGuardPeer *ppeer = &olnk_wg->peers[i];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
peer = nm_wireguard_peer_new();
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
_nm_wireguard_peer_set_public_key_bin(peer, ppeer->public_key);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
nm_setting_wireguard_append_peer(s_wg, peer);
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
}
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static void
get_property(GObject *object, guint prop_id, GValue *value, GParamSpec *pspec)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(object);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
switch (prop_id) {
case PROP_PUBLIC_KEY:
all: use nm_g_variant_new_ay() helper
2021-04-15 09:17:47 +02:00
g_value_take_variant(
value,
nm_g_variant_new_ay(priv->lnk_curr.public_key, sizeof(priv->lnk_curr.public_key)));
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
break;
case PROP_LISTEN_PORT:
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_value_set_uint(value, priv->lnk_curr.listen_port);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
break;
case PROP_FWMARK:
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
g_value_set_uint(value, priv->lnk_curr.fwmark);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, prop_id, pspec);
break;
}
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
/*****************************************************************************/
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static void
nm_device_wireguard_init(NMDeviceWireGuard *self)
{
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
c_list_init(&priv->lst_peers_head);
priv->peers = g_hash_table_new(_peer_data_hash, _peer_data_equal);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
}
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
static void
dispose(GObject *object)
{
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(object);
wireguard: refactor cleanup of NMDeviceWireGuard on disconnect/dispose
2019-07-29 14:37:29 +02:00
_device_cleanup(self);
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
G_OBJECT_CLASS(nm_device_wireguard_parent_class)->dispose(object);
}
static void
finalize(GObject *object)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceWireGuard *self = NM_DEVICE_WIREGUARD(object);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NMDeviceWireGuardPrivate *priv = NM_DEVICE_WIREGUARD_GET_PRIVATE(self);
nm_explicit_bzero(priv->lnk_curr.private_key, sizeof(priv->lnk_curr.private_key));
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
if (priv->dns_manager) {
g_signal_handlers_disconnect_by_func(priv->dns_manager, _dns_config_changed, self);
g_object_unref(priv->dns_manager);
}
device/wireguard: fix memleak for NMDeviceWireGuard Fixes: 2148d0948202 ('core/wireguard: add support for WireGuard peers')
2019-05-03 11:03:01 +02:00
g_hash_table_destroy(priv->peers);
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
G_OBJECT_CLASS(nm_device_wireguard_parent_class)->finalize(object);
}
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
static const NMDBusInterfaceInfoExtended interface_info_device_wireguard = {
.parent = NM_DEFINE_GDBUS_INTERFACE_INFO_INIT(
NM_DBUS_INTERFACE_DEVICE_WIREGUARD,
.properties = NM_DEFINE_GDBUS_PROPERTY_INFOS(
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("PublicKey",
"ay",
NM_DEVICE_WIREGUARD_PUBLIC_KEY),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("ListenPort",
"q",
NM_DEVICE_WIREGUARD_LISTEN_PORT),
NM_DEFINE_DBUS_PROPERTY_INFO_EXTENDED_READABLE("FwMark",
"u",
NM_DEVICE_WIREGUARD_FWMARK), ), ),
};
static void
nm_device_wireguard_class_init(NMDeviceWireGuardClass *klass)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GObjectClass *object_class = G_OBJECT_CLASS(klass);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
NMDBusObjectClass *dbus_object_class = NM_DBUS_OBJECT_CLASS(klass);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMDeviceClass *device_class = NM_DEVICE_CLASS(klass);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
object_class->get_property = get_property;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
object_class->dispose = dispose;
object_class->finalize = finalize;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
dbus_object_class->interface_infos = NM_DBUS_INTERFACE_INFOS(&interface_info_device_wireguard);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->connection_type_supported = NM_SETTING_WIREGUARD_SETTING_NAME;
device_class->connection_type_check_compatible = NM_SETTING_WIREGUARD_SETTING_NAME;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES(NM_LINK_TYPE_WIREGUARD);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->state_changed = device_state_changed;
device_class->create_and_realize = create_and_realize;
device_class->act_stage2_config = act_stage2_config;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
device_class->act_stage2_config_also_for_external_or_assume = TRUE;
core: rework IP configuration in NetworkManager using layer 3 configuration Completely rework IP configuration in the daemon. Use NML3Cfg as layer 3 manager for the IP configuration of an interface. Use NML3ConfigData as pieces of configuration that the various components collect and configure. NMDevice is managing most of the IP configuration at a higher level, that is, it starts DHCP and other IP methods. Rework the state handling there. This is a huge rework of how NetworkManager daemon handles IP configuration. Some fallout is to be expected. It appears the patch deletes many lines of code. That is not accurate, because you also have to count the files `src/core/nm-l3*`, which were unused previously. Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
2021-08-06 15:17:05 +02:00
device_class->act_stage3_ip_config = act_stage3_ip_config;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->get_generic_capabilities = get_generic_capabilities;
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
device_class->link_changed = link_changed;
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
device_class->update_connection = update_connection;
core/wireguard: add support for WireGuard peers That is slightly complex, because we need to (DNS) resolve the endpoints, and we also have to retry periodically. For example, initially we may be unable to resolve an endpoint, but later we may be. What is also interesting is that during assume and reapply, we may not have all information in the profile. Most notably, the private keys will be missing. We need to cope with that and not reconfigure keys. However, we still need to resolve names and update the endpoints.
2019-01-12 12:33:35 +01:00
device_class->can_reapply_change = can_reapply_change;
device_class->reapply_connection = reapply_connection;
wireguard: add "mtu" setting for WireGuard profiles This adds new API for 1.16.0 and is an ABI break since 1.16-rc1. (cherry picked from commit d5e93ae613fd355351bdf37530cae3d3dfb4e5ba)
2019-03-02 23:33:15 +01:00
device_class->get_configured_mtu = get_configured_mtu;
wireguard: support configuring policy routing to avoid routing loops For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
2019-04-30 17:48:46 +02:00
device_class->get_extra_rules = get_extra_rules;
device_class->coerce_route_table = coerce_route_table;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
obj_properties[PROP_PUBLIC_KEY] =
g_param_spec_variant(NM_DEVICE_WIREGUARD_PUBLIC_KEY,
"",
"",
G_VARIANT_TYPE("ay"),
NULL,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
obj_properties[PROP_LISTEN_PORT] = g_param_spec_uint(NM_DEVICE_WIREGUARD_LISTEN_PORT,
"",
"",
0,
G_MAXUINT16,
0,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
obj_properties[PROP_FWMARK] = g_param_spec_uint(NM_DEVICE_WIREGUARD_FWMARK,
"",
"",
0,
G_MAXUINT32,
0,
G_PARAM_READABLE | G_PARAM_STATIC_STRINGS);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
}
/*************************************************************/
#define NM_TYPE_WIREGUARD_DEVICE_FACTORY (nm_wireguard_device_factory_get_type())
#define NM_WIREGUARD_DEVICE_FACTORY(obj) \
(G_TYPE_CHECK_INSTANCE_CAST((obj), NM_TYPE_WIREGUARD_DEVICE_FACTORY, NMWireGuardDeviceFactory))
static NMDevice *
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
create_device(NMDeviceFactory *factory,
const char *iface,
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
const NMPlatformLink *plink,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMConnection *connection,
gboolean *out_ignore)
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
{
all: drop unnecessary cast for return value of g_object_new() C casts unconditionally force the type, and as such they don't necessarily improve type safety, but rather overcome restrictions from the compiler when necessary. Casting a void pointer is unnecessary (in C), it does not make the code more readable nor more safe. In particular for g_object_new(), which is known to return a void pointer of the right type. Drop such casts. sed 's/([A-Za-z_0-9]\+ *\* *) *g_object_new/g_object_new/g' $(git grep -l g_object_new) -i ./contrib/scripts/nm-code-format-container.sh
2020-11-12 15:57:06 +01:00
return g_object_new(NM_TYPE_DEVICE_WIREGUARD,
NM_DEVICE_IFACE,
iface,
NM_DEVICE_TYPE_DESC,
"WireGuard",
NM_DEVICE_DEVICE_TYPE,
NM_DEVICE_TYPE_WIREGUARD,
NM_DEVICE_LINK_TYPE,
NM_LINK_TYPE_WIREGUARD,
NULL);
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
}
NM_DEVICE_FACTORY_DEFINE_INTERNAL(
WIREGUARD,
WireGuard,
wireguard,
core/wireguard: add basic support for creating wireguard devices Configuring peers (and allowed-ips of the peers) is not yet supported.
2018-12-29 00:04:20 +01:00
NM_DEVICE_FACTORY_DECLARE_LINK_TYPES(NM_LINK_TYPE_WIREGUARD)
NM_DEVICE_FACTORY_DECLARE_SETTING_TYPES(NM_SETTING_WIREGUARD_SETTING_NAME),
core: introduce NMDeviceWireGuard For now, the device only exposes partial link status (not including peers). It cannot create new links.
2018-03-13 13:42:38 +00:00
factory_class->create_device = create_device;)
Reference in a new issue Copy permalink