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