[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55d91682-762e-411e-8abc-0790a9d81102@openvpn.net>
Date: Tue, 26 Nov 2024 09:17:22 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sergey Ryazanov <ryazanov.s.a@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Donald Hunter <donald.hunter@...il.com>, Shuah Khan <shuah@...nel.org>,
sd@...asysnail.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next v11 05/23] ovpn: keep carrier always on
On 25/11/2024 22:32, Sergey Ryazanov wrote:
[...]
>> FTR, here is the text in the manpage:
>>
>> --persist-tun
>> Don't close and reopen TUN/TAP device or run up/down
>> scripts across SIGUSR1 or --ping-restart restarts.
>>
>> SIGUSR1 is a restart signal similar to SIGHUP, but
>> which offers finer-grained control over reset options.
>>
>>
>> SIGUSR1 is a session reconnection, not a process restart.
>> The manpage just indicates what happens at the low level when this
>> option is provided.
>
> Still no mentions of the traffic leaking prevention. Is it?
Like I said, the manpage only mentions the low level bits.
I have already proposed a patch to further extend this text.
[...]
>> Having userspace configure a blackhole route is something that can be
>> considered by whoeever decides to implement the "kill switch" feature.
>>
>> OpenVPN does not. It just implements --persist-tun.
>>
>> So all in all, the conclusion is that in this case it's usersapce to
>> decide when the interface should go up and down, depending on the
>> configuration. I'd like to keep it as it is to avoid the ovpn
>> interface to make decisions on its own.
>>
>> I can spell this out in the comment (I think it definitely makes
>> sense), to clarify that the netcarrier is expected to be driven by
>> userspace (where the control plane is) rather than having the device
>> make decisions without having the full picture.
>>
>> What do you think?
>
> It wasn't suggested to destroy the interface in case of interface
> becoming non-operational. I apologize if something I wrote earlier
> sounded like that. The interface existence stays unquestionable. It's
> going to be solid persistent.
>
> Back to the proposed rephrasing. If the 'full picture' means forcing the
> running state indication even when the netdev is not capable to deliver
> packets, then it looks like an attempt to hide the control knob of the
> misguiding feature somewhere else.
>
> And since the concept of on-purpose false indication is still here, many
> words regarding the control plane and a full picture do not sound good
> either.
Can you please point out the code where other virtual drivers are doing
what you are suggesting so I can have a look?
Wireguard is the closest module in terms of concept and I couldn't see
anything like that. Neither in ipsec.
But I may have overlooked something.
Please let me know.
Regards,
--
Antonio Quartulli
OpenVPN Inc.
Powered by blists - more mailing lists