lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d896bbd8-2709-4834-a637-f982fc51fc57@openvpn.net>
Date: Fri, 8 Mar 2024 01:08:21 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
 Sergey Ryazanov <ryazanov.s.a@...il.com>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next v2 04/22] ovpn: add basic interface
 creation/destruction/management routines

On 06/03/2024 20:31, Andrew Lunn wrote:
> On Wed, Mar 06, 2024 at 03:49:50PM +0100, Antonio Quartulli wrote:
>> On 05/03/2024 17:27, Andrew Lunn wrote:
>>>>>> +void ovpn_iface_destruct(struct ovpn_struct *ovpn, bool unregister_netdev)
>>>>>> +{
>>>>>> +	ASSERT_RTNL();
>>>>>> +
>>>>>> +	netif_carrier_off(ovpn->dev);
>>>>>
>>>>> You often see virtual devices turn their carrier off in there
>>>>> probe/create function, because it is unclear what state it is in after
>>>>> register_netdevice().
>>>>
>>>> Are you suggesting to turn it off both here and in the create function?
>>>> Or should I remove the invocation above?
>>>
>>> I noticed it in the _destruct function and went back to look at
>>> create. You probably want it in both, unless as part of destruct, you
>>> first disconnect all peers, which should set the carrier to off when
>>> the last peer disconnects?
>>
>> I think keeping the carrier on while no peer is connected is better for
>> OpenVPN.
> 
> I then have to wounder what carrier actually means?
> 
> Some routing protocols will kick off determining routes when the
> carrier goes down. Can you put team/bonding on top of openvpn? If the
> peer has gone, you want team to fall over to the active backup?

IIRC team/bonding requires a L2 interface, but ovpn creates a L3 device.
So I don't think this case applies here.

To be honest we don't have any real concept for the carrier off.
Especially on a server, I hardly believe it would be any useful.

However, on a client or on a p2p link, where there is exactly one remote 
host on the other side, it may make sense to turn the carrier off when 
that remote peer is lost.

There is an extra detail to consider: if the user wants to, the ovpn 
device should remain configured (with all IPs and routes) even if 
openvpn has fully disconnected and it is attempting a reconnection to 
another server. Reason being avoiding data leaks by accidentally 
removing routes to the tunnel (traffic that should go through the tunnel 
would rather go to the local network).

With all this being said, it may make sense to just keep the carrier on 
all time long.

Should we come up with something smarter in the future, we can still 
improve this behaviour.

Regards,

> 
>       Andrew

-- 
Antonio Quartulli
OpenVPN Inc.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ