/* * OpenVPN -- An application to securely tunnel IP networks * over a single TCP/UDP port, with support for SSL/TLS-based * session authentication and key exchange, * packet encryption, packet authentication, and * packet compression. * * Copyright (C) 2010-2018 Fox Crypto B.V. <openvpn@fox-it.com> * * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 * as published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. */ /** * @file * VPN tunnel state documentation file. */ /** * @page tunnel_state Structure of the VPN tunnel state storage * * This section describes how OpenVPN stores its VPN tunnel state during * operation. * * OpenVPN uses several data structures as storage containers for state * information of active VPN tunnels. These are described in this * section, together with a little bit of history to help understand the * origin of the current architecture. * * Whether an OpenVPN process is running in client-mode or server-mode * determines whether it can support only one or multiple simultaneously * active VPN tunnels. This consequently also determines how the * associated state information is wrapped up internally. This section * gives an overview of the differences. * * @section tunnel_state_history Historic developments * * In the old v1.x series, an OpenVPN process managed only one single VPN * tunnel. This allowed the VPN tunnel state to be stored together with * process-global information in one single \c context structure. * * This changed, however, in the v2.x series, as new OpenVPN versions * running in server-mode can support multiple simultaneously active VPN * tunnels. This necessitated a redesign of the VPN tunnel state * container structures, and modification of the \link * external_multiplexer External Multiplexer\endlink and \link * internal_multiplexer Internal Multiplexer\endlink systems. The * majority of these changes are only relevant for OpenVPN processes * running in server-mode, and the client-mode structure has remained very * similar to the v1.x single-tunnel form. * * @section tunnel_state_client Client-mode state * * An OpenVPN process running in client-mode can manage at most one single * VPN tunnel at any one time. The state information for a client's VPN * tunnel is stored in a \c context structure. * * The \c context structure is created in the \c main() function. That is * also where process-wide initialization takes place, such as parsing * command line %options and reading configuration files. The \c context * is then passed to \c tunnel_point_to_point() which drives OpenVPN's * main event processing loop. These functions are both part of the \link * eventloop Main Event Loop\endlink module. * * @subsection tunnel_state_client_init Initialization and cleanup * * Because there is only one \c context structure present, it can be * initialized and cleaned up from the client's main event processing * function. Before the \c tunnel_point_to_point() function enters its * event loop, it calls \c init_instance_handle_signals() which calls \c * init_instance() to initialize the single \c context structure. After * the event loop stops, it calls \c close_instance() to clean up the \c * context. * * @subsection tunnel_state_client_event Event processing * * When the main event processing loop activates the external or internal * multiplexer to handle a network event, it is not necessary to determine * which VPN tunnel the event is associated with, because there is only * one VPN tunnel active. * * @section tunnel_state_server Server-mode state * * An OpenVPN process running in server-mode can manage multiple * simultaneously active VPN tunnels. For every VPN tunnel active, in * other words for every OpenVPN client which is connected to a server, * the OpenVPN server has one \c context structure in which it stores that * particular VPN tunnel's state information. * * @subsection tunnel_state_server_multi Multi_context and multi_instance structures * * To support multiple \c context structures, each is wrapped in a \c * multi_instance structure, and all the \c multi_instance structures are * registered in one single \c multi_context structure. The \link * external_multiplexer External Multiplexer\endlink and \link * internal_multiplexer Internal Multiplexer\endlink then use the \c * multi_context to retrieve the correct \c multi_instance and \c context * associated with a given network address. * * @subsection tunnel_state_server_init Startup and initialization * * An OpenVPN process running in server-mode starts in the same \c main() * function as it would in client-mode. The same process-wide * initialization is performed, and the resulting state and configuration * is stored in a \c context structure. The server-mode and client-mode * processes diverge when the \c main() function calls one of \c * tunnel_point_to_point() or \c tunnel_server(). * * In server-mode, \c main() calls the \c tunnel_server() function, which * transfers control to \c tunnel_server_udp_single_threaded() or \c * tunnel_server_tcp() depending on the external transport protocol. * * These functions receive the \c context created in \c main(). This * object has a special status in server-mode, as it does not represent an * active VPN tunnel, but does contain process-wide configuration * parameters. In the source code, it is often stored in "top" variables. * To distinguish this object from other instances of the same type, its * \c context.mode value is set to \c CM_TOP. Other \c context objects, * which do represent active VPN tunnels, have a \c context.mode set to \c * CM_CHILD_UDP or \c CM_CHILD_TCP, depending on the external transport * protocol. * * Both \c tunnel_server_udp_single_threaded() and \c tunnel_server_tcp() * perform similar initialization. In either case, a \c multi_context * structure is created, and it is initialized according to the * configuration stored in the top \c context by the \c multi_init() and * \c multi_top_init() functions. * * @subsection tunnel_state_server_tunnels Creating and destroying VPN tunnels * * When an OpenVPN client makes a new connection to a server, the server * creates a new \c context and \c multi_instance. The latter is * registered in the \c multi_context, which makes it possible for the * external and internal multiplexers to retrieve the correct \c * multi_instance and \c context when a network event occurs. * * @subsection tunnel_state_server_cleanup Final cleanup * * After the main event loop exits, both \c * tunnel_server_udp_single_threaded() and \c tunnel_server_tcp() perform * similar cleanup. They call \c multi_uninit() followed by \c * multi_top_free() to clean up the \c multi_context structure. */