Development discussion of WireGuard
 help / color / mirror / Atom feed
* ip netns del zaps wg link
@ 2023-05-17 23:13 Harry G Coin
  2023-07-14 10:27 ` Maarten de Vries
  0 siblings, 1 reply; 5+ messages in thread
From: Harry G Coin @ 2023-05-17 23:13 UTC (permalink / raw)
  To: wireguard

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.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ip netns del zaps wg link
  2023-05-17 23:13 ip netns del zaps wg link Harry G Coin
@ 2023-07-14 10:27 ` Maarten de Vries
  2023-07-14 21:48   ` Harry G Coin
  0 siblings, 1 reply; 5+ messages in thread
From: Maarten de Vries @ 2023-07-14 10:27 UTC (permalink / raw)
  To: wireguard

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ip netns del zaps wg link
  2023-07-14 10:27 ` Maarten de Vries
@ 2023-07-14 21:48   ` Harry G Coin
  2023-07-15  4:48     ` Michael Tokarev
  0 siblings, 1 reply; 5+ messages in thread
From: Harry G Coin @ 2023-07-14 21:48 UTC (permalink / raw)
  To: wireguard; +Cc: maarten


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








^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ip netns del zaps wg link
  2023-07-14 21:48   ` Harry G Coin
@ 2023-07-15  4:48     ` Michael Tokarev
  2023-07-15 20:29       ` Harry G Coin
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Tokarev @ 2023-07-15  4:48 UTC (permalink / raw)
  To: Harry G Coin, wireguard; +Cc: maarten

15.07.2023 00:48, Harry G Coin wrote:
..

> [] 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) 

The thing is that all interface types behave like this when a network namespace is removed:
they're destroyed together with the namespace.  All which can be deleted anyway, for which
an `ip link del' command works, - like, physical NICs are the only exception here b/c you
can't remove a physical NIC from a physical machine this way.

So in this context, wg interfaces are *already* behaving like all other virtual interfaces,
and this is done by linux network/namespace subsystem, not by wireguard.

/mjt

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ip netns del zaps wg link
  2023-07-15  4:48     ` Michael Tokarev
@ 2023-07-15 20:29       ` Harry G Coin
  0 siblings, 0 replies; 5+ messages in thread
From: Harry G Coin @ 2023-07-15 20:29 UTC (permalink / raw)
  To: Michael Tokarev, wireguard; +Cc: maarten


On 7/14/23 23:48, Michael Tokarev wrote:
> 15.07.2023 00:48, Harry G Coin wrote:
> ..
>
>> [] 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) 
>
> The thing is that all interface types behave like this when a network 
> namespace is removed:
> they're destroyed together with the namespace.  All which can be 
> deleted anyway, for which
> an `ip link del' command works, - like, physical NICs are the only 
> exception here b/c you
> can't remove a physical NIC from a physical machine this way.
>
> So in this context, wg interfaces are *already* behaving like all 
> other virtual interfaces,
> and this is done by linux network/namespace subsystem, not by wireguard.
>
> /mjt


Oh dear.    It sure makes more sense to me for anything called 'an 
interface' to move in the same fashion as any other.  Having to 'just 
know' which ones will 'remain' and which ones will 'go away and need to 
be entirely reconfigured all the time' seems more than the security need 
calls for.  Just setting the link down when the netns goes away would be 
better, I can decide when, whether and how to create and destroy 
interfaces.   Or at least an option to 'treat all links the same when 
the netns goes away' somehow.

Off soap box now!

Thanks for the comments.



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-07-15 20:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-17 23:13 ip netns del zaps wg link Harry G Coin
2023-07-14 10:27 ` Maarten de Vries
2023-07-14 21:48   ` Harry G Coin
2023-07-15  4:48     ` Michael Tokarev
2023-07-15 20:29       ` Harry G Coin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).