search

OpenVPN / openvpn3-linux

OpenVPN 3 Linux client
GNU Affero General Public License v3.0
554 stars 148 forks source link

Could not establish a connection with 'net.openvpn.v3.sessions' #42

Closed benshaw closed 3 years ago

benshaw commented 3 years ago

We are trying to get this working for NixOS (https://github.com/NixOS/nixpkgs/pull/120352) However we get the error * ERROR ** Could not establish a connection with 'net.openvpn.v3.sessions I have not been able to find more debugging information (nothing in journalctl) Please advise how to proceed.

Thanks!

dsommers commented 3 years ago

Can you try to start openvpn3-service-sessionmgr manually and see that it starts running? You can add --log-level 6 --log-file stdout: to get more log data to the console.

benshaw commented 3 years ago

Thanks for the quick response

openvpn3-service-sessionmgr is not found --log-file stdout: is not a valid option

dsommers commented 3 years ago

well, it's not in the normal $PATH, as it is expected to be automatically started by D-Bus daemon. I don't know what the default paths are in NixOS - as I know it does things very different from ordinary Linux distributions. On my RHEL box, it's /usr/libexec/openvpn3-linux/openvpn3-service-sessionmgr. Also pay attention to the D-Bus auto-start files (again, on RHEL, they're located in /usr/share/dbus-1/system-services/net.openvpn.v3.*.service). This is what instructs D-Bus to automatically start the various backend-services of OpenVPN 3 Linux.

benshaw commented 3 years ago 
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/libexec/openvpn3-linux/openvpn3-service-sessionmgr --log-level 6 --log-file stdout:
OpenVPN 3/Linux git:fetchgit:2031975261858750* (openvpn3-service-sessionmgr)
OpenVPN core 3.git:fetchgit:ce0c9963 linux x86_64 64-bit
Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
terminate called after throwing an instance of 'openvpn::DBusException'
  what():  D-Bus service 'net.openvpn.v3.log' did not start
Aborted (core dumped)
benshaw commented 3 years ago

I think these are the service files you are talking about According to the documentation they are all located in the correct place

/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.sessions.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.netcfg.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.configuration.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.backends.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.log.service
dsommers commented 3 years ago

This is an overview of the architecture of OpenVPN 3 Linux ovpn3-arch

The front-end applications, using the default D-Bus policy runs completely unprivileged and are only allowed to connect to the net.openvpn.v3.configuration (openvpn3-service-configmgr) and net.openvpn.v3.sessions (openvpn3-service-sessoinmgr) services. These services are started automatically by the D-Bus daemon. These services uses the net.openvpn.v3.log (openvpn3-service-logger) service, to capture and handle logging - this is where you're blocked currently. This service is also automatically started, but that doesn't happen here.

Further, when a new session is started to create a new VPN tunnel, the sessionmgr service starts the net.openvpn.v3.backends.be* (openvpn3-service-client) process via the openvpn3-service-backendstart service (net.openvpn.v3.backend), where client process is given the configuration path to use - which is uses to retrieve the configuration profile from the net.openvpn.v3.configuration service. When the connection to the server is established and the needed information to configure the virtual network interface (tun or ovpn-dco interfaces) has been received, the client process requests that via the net.openvpn.v3.netcfg (openvpn3-service-netcfg) service; the netcfg service is the most privileged process on the system and is the only one allowed to do configure IP addresses, routing, socket binding, DNS resolver configurations and so on. There exists one openvpn3-service-client process per VPN tunnel, the rest of these services are shared. And logging goes also to the net.openvpn.v3.log service.

This model is chosen to compartmentalize VPN sessions into smaller "scopes" where they only handle a single task (configuration management, session management, logging, VPN connection/session and network configuration).

When all the various services are no longer needed, they will stop running automatically after a pre-defined idle time.

The D-Bus service files you found are the key element to tell D-Bus daemon where each independent binary is located (which program to execute) and which D-Bus service name ("destination") they are tied to. They are simple text files (ini-style). If the D-Bus service is not able to start a service, it will fail. I would check these files if they point at the proper directories and binaries.

dsommers commented 3 years ago

@benshaw Is this still an issue which needs a fix in OpenVPN 3 Linux?

benshaw commented 3 years ago

@benshaw Is this still an issue which needs a fix in OpenVPN 3 Linux?

@dsommers this doesn't require anything in OpenVPN 3 Linux but there is an open issue in NixPkgs that probably requires input from OpenVPN3 Linux developers (ive noticed you have commented)

dsommers commented 3 years ago

@benshaw Sounds good. I'll close the ticket here and feel free to tag me and get my attention whenever needed in NixPkgs to complete the Nix packaging.