On 7/14/23 05:27, Maarten de Vries wrote:
On 18/05/2023 01:13, Harry G Coin wrote:
First, Hi and thanks for all the effort!
At least on Ubuntu latest LTS: As advertised, if a wireguard link
gets created by systemd/networkd, then set into a different net
namespace, all works well.
However, if that namespace is deleted, the link appears to be 'gone
forever'. Other link types reappear in the primary namespace when
the namespace they are in gets deleted. I'm not sure whether the
link retains its 'up' or 'down' state when the namespace it's in gets
deleted and reset to primary. Not a big deal, doesn't happen often.
This is 100% repeatable. Some other answer than 'inaccessible until
the next reboot' would be nice.
Hi,
This behavior is exactly what I would expect. I'm using namespaces to
restrict access to a wireguard link. If the namespace gets destroyed,
I absolutely do not want other programs to have access to the
wireguard link.
You can simply re-create the wireguard link to use it again. This may
not be the most convenient for you, but your use case seems to be a
bit unconventional: you are moving and deleting a resource created by
systemd and/or networkd manually. You are mixing automatic and manual
management, so there is a risk of breaking the automatic management.
Alternatively, you could move the interface back before deleting the
namespace.
Kind regards,
Maarten de Vries
Hi,
It's worth thinking about the only means by which a namespace 'gets
destroyed'.
The point of systemd/networkd for most of us is similarity and
convenience and uniformity in initialization across interface device
types. That frees later choices in nic management to involve only the
detail specific to those choices. Remember systemd/networkd (can be
just one-and-done setup time management) is a very different thing than
NetworkManager (Automatic active ongoing management). Someday I hope
systemd/networkd adds namespace comprehension.
As wireguard and namespaces management are both limited to the root
user, who presumably is aware of the security implications involved, and
wireguard's birth in the initial namespace is a selling point no matter
how it moves among namespaces later: allowing wireguard interfaces to
behave like all other interfaces when a namespace is destroyed (moving
back to the namespace where it was born and to which it retains
connection anyhow) avoids imposing further 'wireguard only' admin
burden. It might be convenient to automatically set the wireguard link
'down' as the interface transitions back from the namespace being
destroyed to the primary so as to avoid any possibility of overlapping
existing entries in the primary routing table. But destroying the
interface altogether generates admin burden beyond need.
Thanks for all the wireguard work!
Harry Coin
