feat: Added ability to feed config from memory instead of file

[yma-het]

In some cases we want config to exist only in memory. In such case /dev/fd is very handy.

[schwabe]

Could you expand on your usecase when exactly you need this? The normal use case for the client library is already to pass an object that holds the config in memory. What use case do you have that you need to have some file reference in your configuration that cannot be in the configuration itself as well

[yma-het]

The normal use case for the client library is already to pass an object that holds the config in memory.

What do you mean? Currently, the only way i see is to pass config file name as an argument. Moreover, file name MUST end with .ovpn, if not, error will be thrown.

I'm talking about ovpncli utility interface.

I can explain my use case in more details. Currently, i use openvpn v2 and it has no problem consuming /dev/fd/...
But lack of support of managing dns on macos, forces me to migrate to openvpn v3 client. And the reason for using /dev/fd/... is the fact that i see no other option to prevent config leakage on filesystem. If there is some other options to achieve this without this hack, i will be glad to hear such opportunity.

[dsommers]

Have a look here: https://codeberg.org/OpenVPN/openvpn3-linux/src/branch/master/src/tests/misc/config-export-json-test.cpp

The OpenVPN 3 Linux project has an extension to OptionList which adds a JSON import/export + string export features. That's implemented here: https://codeberg.org/OpenVPN/openvpn3-linux/src/branch/master/src/common/core-extensions.hpp. If you just need the ProfileMerge::profile_content() you can remove the whole OptionListJSON part. Or if you just need the OptionList, just replace it.

This handles the configuration entirely in memory, by reading the entire config either from file or stdin,

[yma-het]

@dsommers I need this functionality for macos. AFAIK, there is no way to build openvpn3-linux for this os, or i missed something? At least, i cannot locate the code handling macos DNS settings. Also, i found existence of two separate openvpnv3-based clients kinda frustrating, because ovpncli supports DNS push on macos, but not on linux. And openvpn3-linux is a very good tool with near-to-full backward interface compatibility with openvpnv2 but it does not support macos at all...

[schwabe]

@yma-het ovpncli is not an official client, it is just meant as a test tool. So that doesn't exist as client apart from the test applications. So there is only one official Linux client which is openvpn3-linux and there is also only one official macOS client, which is called "OpenVPN Connect".

The missing features like certificate management and proper configuration management are just not in scope of this client.

We understand that this client could be used as VPN client but it has other shortcoming and quirks as well. The inconsistencies what ovpncli does on different platforms that you observed is one of the many one of such quirks. So trying to make it even more of a full featured client would be contra-productive in my opinion.

Is there any reason you cannot use Tunnelblick, OpenVPN Connect or openvpn with with an --up script for DNS like Tunnelblick does as well?

Also we are looking to implement native DNS support in macos for OpenVPN 2.x

There is also another reason to prevent the PR in its current form. You are modifying a central file that is used in a lot more places than just ovpncli. These changes of yours might have uninteded consqueses. I would rather modify ovpncli to allow reading from stdin when the config name is stdin or similar than modifying this central file.

[yma-het]

@schwabe
My main goal is to manage DNS as natural as possible. Yes, it is an option to call hacky scripts with --up, but it pushes me to distribute my own scripts to clients. Also, in case of using those scripts, there is a risk of DNS leak, because in case of kill -9 of openvpn process, there is no mechanism to garbage collect those DNS tweaks. In linux it is not a real issue, because records are being assigned to interface that is being destroyed after process dies. But in macos my experience is not enough to understand what's going on, but at firs glance, it looks like ovpnclient deals with DNS in much safer manner than openvpnv2 or Tunnelblick. What about OpenVPN Connect, i see no chances of passing config to it without storing this config permanently inside app. It cli interface looks VERY poor: https://openvpn.net/connect-docs/command-line-functionality-macos.html

Looks that ovpncli on macos and openvpn2 wrapper on openvpn3 on linux are my best options in such case. Or i missing something?

There is also another reason to prevent the PR in its current form. You are modifying a central file that is used in a lot more places than just ovpncli. These changes of yours might have uninteded consqueses. I would rather modify ovpncli to allow reading from stdin when the config name is stdin or similar than modifying this central file.

Eyah, this is a good point, i'll fix it. Thanks!

[schwabe]

Looks that ovpncli on macos and openvpn2 wrapper on openvpn3 on linux are my best options in such case. Or i missing something?

You are using a client a that has been only developed and maintained as a test client as productive tool. I would strictly recommend against using that tool for that purpose.

A proper openvpn3 based command line client for macOS simply does not does exist. ovpncli is not a properly maintained client or anything like that. It is a test client/development tool and we developers treat it as such. It goes through no QA, breaking changes are completely fine and also behaviour/feature of the client can change at any time.