Home
Arrows in this diagram represent data flow directions. While in all the cases actual data is flowing both ways, communication tunnel or request data is not considered in this direction. So, if some data is always requested by component1 and component2 is responding, this is displayed as component1 <- component2.
This is the main service for NordVPN Linux application. It is started on application install and on OS start and it is running until OS shuts down or application is uninstalled. It uses all of the components mentioned below in order to handle application state and communicate with all the other processes and services.
As it is displayed in Overview, it uses various linux utilities for configuring and monitoring system’s network state (firewall, routing, DNS configuration, etc) and uses either OpenVPN or libtelio depending on selected VPN technology or both in case of active VPN connection with OpenVPN technology set and Meshnet setting enabled.
Purpose of this component is to allow the application to communicate with our infrastructure maintained by Core team to exchange all the data about our infrastructure which is needed by an app: authentication, server lists, service credentials, account information, meshnet configuration and so on. Mostly it is a HTTP client with our configuration, domain rotation, HTTP protocol (HTTP/1.1, HTTP/3) rotator.
A component responsible for collecting server lists and other information about servers (locations, supported configurations, etc.) and caching them. In case the recommended server is not enough for server selection, this data is being used to find exact configuration to be used for a VPN connection.
A sole purpose of this component is to periodically execute data manager to keep cached information up to date.
Used during either first call to nordvpnd since startup or to any other first call after X time since the last remote config check. It retrieves the information about global configuration of the application which is the same for all the users, such as the minimal supported version for a feature.
This is started once the user is logged in or nordvpnd is started when the user is already logged in. It keeps the connection with Notification Center alive and forwards all the received notifications to the nordvpnd process where it handles the responsible entities to react to them accordingly (e. g. refresh meshnet peer list and refresh networker after notification about updated mesh map is received).
It is used to store and receive current settings of the user as well as cached API token and service credentials. Config manager is used whenever any configuration or credentials are needed to be accessed.
A separate binary executed by nordvpnd process, therefore it runs as a child process to it during the VPN connection. This is built by our team from upstream and applying tunnelblick patches and added into the package of application.
This service is started on user login by systemd or by nordvpnd once meshnet is enabled. The main reason this was separated from nordvpnd was due to permission model and security as manipulating files in user permission scope is way more protected from privilege escalations and unauthorized manipulations by design. Whole file sharing feature is handled in this service, therefore CLI directly communicates to it regarding file sharing functionality. It needs information from nordvpnd about meshnet peer list and user’s configuration such as permissions.
Event Manager is responsible for libdrop event handling. It keeps transfer state, distributes events to further subscribers, and uses History for transfer state persistence.
A component used to store all completed and ongoing transfers persistently as this is not part of libdrop functionality.
User facing application which accepts all of the commands from the user, communicates with nordvpnd and nordfileshared via gRPC over UNIX domain sockets and displays results for the user. Lifetime of this process is between the entered command and displayed response.