[Openvpn-devel] [PATCH v2 4/8] doc/man: Complete openvpn.8.rst splitting

[David S. <da...@op...>]

This rebuilds the openvpn.8.rst content by using the text which was
split out in the previous commit by using RST ..include statements.

Signed-off-by: David Sommerseth <da...@op...>
---
 doc/openvpn.8.rst | 5614 +--------------------------------------------
 1 file changed, 17 insertions(+), 5597 deletions(-)

diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index 713cd309..4a7ca3aa 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -69,5603 +69,23 @@ a configuration file. Though all command line options are preceded by a
 double-leading-dash ("--"), this prefix can be removed when an option is
 placed in a configuration file.
 
---help
-
-  Show options.
-
---config file
-  Load additional config options from ``file`` where each line corresponds
-  to one command line option, but with the leading '--' removed.
-
-  If ``--config file`` is the only option to the openvpn command, the
-  ``--config`` can be removed, and the command can be given as ``openvpn
-  file``
-
-  Note that configuration files can be nested to a reasonable depth.
-
-  Double quotation or single quotation characters ("", '') can be used to
-  enclose single parameters containing whitespace, and "#" or ";"
-  characters in the first column can be used to denote comments.
-
-  Note that OpenVPN 2.0 and higher performs backslash-based shell escaping
-  for characters not in single quotations, so the following mappings
-  should be observed:
-  ::
-
-      \\       Maps to a single backslash character (\).
-      \"       Pass a literal doublequote character ("), don't
-               interpret it as enclosing a parameter.
-      \[SPACE] Pass a literal space or tab character, don't
-               interpret it as a parameter delimiter.
-
-  For example on Windows, use double backslashes to represent pathnames:
-  ::
-
-      secret "c:\\OpenVPN\\secret.key"
-
-
-  For examples of configuration files, see
-  https://openvpn.net/community-resources/how-to/
-
-  Here is an example configuration file:
-  ::
-
-      #
-      # Sample OpenVPN configuration file for
-      # using a pre-shared static key.
-      #
-      # '#' or ';' may be used to delimit comments.
-
-      # Use a dynamic tun device.
-      dev tun
-
-      # Our remote peer
-      remote mypeer.mydomain
-
-      # 10.1.0.1 is our local VPN endpoint
-      # 10.1.0.2 is our remote VPN endpoint
-      ifconfig 10.1.0.1 10.1.0.2
-
-      # Our pre-shared static key
-      secret static.key
-
-
-Tunnel Options:
----------------
-
---mode m
-  Set OpenVPN major mode. By default, OpenVPN runs in point-to-point mode
-  (:code:`p2p`). OpenVPN 2.0 introduces a new mode (:code:`server`) which
-  implements a multi-client server capability.
-
---local host
-  Local host name or IP address for bind. If specified, OpenVPN will bind
-  to this address only. If unspecified, OpenVPN will bind to all
-  interfaces.
-
---remote args
-  Remote host name or IP address.  It supports two additional optional
-  arguments: ``port`` and ``proto``.  On the client, multiple ``--remote``
-  options may be specified for redundancy, each referring to a different
-  OpenVPN server. Specifying multiple ``--remote`` options for this
-  purpose is a special case of the more general connection-profile
-  feature. See the ``<connection>`` documentation below.
-
-  The OpenVPN client will try to connect to a server at ``host:port`` in
-  the order specified by the list of ``--remote`` options.
-
-  Examples:
-  ::
-
-     remote server.example.net
-     remote server.example.net 1194
-     remote server.example.net tcp
-
-  ``proto`` indicates the protocol to use when connecting with the remote,
-  and may be :code:`tcp` or :code:`udp`.
-
-  For forcing IPv4 or IPv6 connection suffix tcp or udp with 4/6 like
-  udp4/udp6/tcp4/tcp6.
-
-  The client will move on to the next host in the list, in the event of
-  connection failure. Note that at any given time, the OpenVPN client will
-  at most be connected to one server.
-
-  Note that since UDP is connectionless, connection failure is defined by
-  the ``--ping`` and ``--ping-restart`` options.
-
-  Note the following corner case: If you use multiple ``--remote``
-  options, AND you are dropping root privileges on the client with
-  ``--user`` and/or ``--group`` AND the client is running a non-Windows
-  OS, if the client needs to switch to a different server, and that server
-  pushes back different TUN/TAP or route settings, the client may lack the
-  necessary privileges to close and reopen the TUN/TAP interface. This
-  could cause the client to exit with a fatal error.
-
-  If ``--remote`` is unspecified, OpenVPN will listen for packets from any
-  IP address, but will not act on those packets unless they pass all
-  authentication tests. This requirement for authentication is binding on
-  all potential peers, even those from known and supposedly trusted IP
-  addresses (it is very easy to forge a source IP address on a UDP
-  packet).
-
-  When used in TCP mode, ``--remote`` will act as a filter, rejecting
-  connections from any host which does not match ``host``.
-
-  If ``host`` is a DNS name which resolves to multiple IP addresses,
-  OpenVPN will try them in the order that the system getaddrinfo()
-  presents them, so priorization and DNS randomization is done by the
-  system library. Unless an IP version is forced by the protocol
-  specification (4/6 suffix), OpenVPN will try both IPv4 and IPv6
-  addresses, in the order getaddrinfo() returns them.
-
---remote-random-hostname
-  Prepend a random string (6 bytes, 12 hex characters) to hostname to
-  prevent DNS caching. For example, "foo.bar.gov" would be modified to
-  "<random-chars>.foo.bar.gov".
-
---proto-force p
-  When iterating through connection profiles, only consider profiles using
-  protocol ``p`` (:code:`tcp` \| :code:`udp`).
-
---remote-random
-  When multiple ``--remote`` address/ports are specified, or if connection
-  profiles are being used, initially randomize the order of the list as a
-  kind of basic load-balancing measure.
-
---proto p
-  Use protocol ``p`` for communicating with remote host. ``p`` can be
-  :code:`udp`, :code:`tcp-client`, or :code:`tcp-server`.
-
-  The default protocol is :code:`udp` when ``--proto`` is not specified.
-
-  For UDP operation, ``--proto udp`` should be specified on both peers.
-
-  For TCP operation, one peer must use ``--proto tcp-server`` and the
-  other must use ``--proto tcp-client``. A peer started with
-  :code:`tcp-server` will wait indefinitely for an incoming connection. A peer
-  started with :code:`tcp-client` will attempt to connect, and if that fails,
-  will sleep for 5 seconds (adjustable via the ``--connect-retry`` option)
-  and try again infinite or up to N retries (adjustable via the
-  ``--connect-retry-max`` option). Both TCP client and server will
-  simulate a SIGUSR1 restart signal if either side resets the connection.
-
-  OpenVPN is designed to operate optimally over UDP, but TCP capability is
-  provided for situations where UDP cannot be used. In comparison with
-  UDP, TCP will usually be somewhat less efficient and less robust when
-  used over unreliable or congested networks.
-
-  This article outlines some of problems with tunneling IP over TCP:
-  http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
-
-  There are certain cases, however, where using TCP may be advantageous
-  from a security and robustness perspective, such as tunneling non-IP or
-  application-level UDP protocols, or tunneling protocols which don't
-  possess a built-in reliability layer.
-
---connect-retry args
-  Wait ``n`` seconds between connection attempts (default :code:`5`).
-  Repeated reconnection attempts are slowed down after 5 retries per
-  remote by doubling the wait time after each unsuccessful attempt. An
-  optional argument ``max`` specifies the maximum value of wait time in
-  seconds at which it gets capped (default :code:`300`).
-
---connect-retry-max n
-  ``n`` specifies the number of times each ``--remote`` or
-  ``<connection>`` entry is tried. Specifying ``n`` as one would try each
-  entry exactly once. A successful connection resets the counter.
-  (default *unlimited*).
-
---show-proxy-settings
-  Show sensed HTTP or SOCKS proxy settings. Currently, only Windows
-  clients support this option.
-
---http-proxy args
-  Connect to remote host through an HTTP proxy.  This requires at least an
-  address ``server`` and ``port`` argument.  If HTTP Proxy-Authenticate
-  is required, a file name to an ``authfile`` file containing a username
-  and password on 2 lines can be given, or :code:`stdin` to prompt from
-  console. Its content can also be specified in the config file with the
-  ``--http-proxy-user-pass`` option. (See section on inline files)
-
-  The last optional argument is an ``auth-method`` which should be one
-  of :code:`none`, :code:`basic`, or :code:`ntlm`.
-
-  HTTP Digest authentication is supported as well, but only via the
-  :code:`auto` or :code:`auto-nct` flags (below).  This must replace
-  the ``authfile`` argument.
-
-  The :code:`auto` flag causes OpenVPN to automatically determine the
-  ``auth-method`` and query stdin or the management interface for
-  username/password credentials, if required. This flag exists on OpenVPN
-  2.1 or higher.
-
-  The ``auto-nct`` flag (no clear-text auth) instructs OpenVPN to
-  automatically determine the authentication method, but to reject weak
-  authentication protocols such as HTTP Basic Authentication.
-
-  Examples:
-  ::
-
-     http-proxy proxy.example.net 3128
-     http-proxy proxy.example.net 3128 authfile.txt
-     http-proxy proxy.example.net 3128 stdin
-     http-proxy proxy.example.net 3128 auto basic
-     http-proxy proxy.example.net 3128 auto-nct ntlm
-
---http-proxy-option args
-  Set extended HTTP proxy options. Requires an option ``type`` as argument
-  and an optional ``parameter`` to the type.  Repeat to set multiple
-  options.
-
-  :code:`VERSION` ``version``
-      Set HTTP version number to ``version`` (default :code:`1.0`).
-
-  :code:`AGENT` ``user-agent``
-      Set HTTP "User-Agent" string to ``user-agent``.
-
-  :code:`CUSTOM-HEADER` ``name`` ``content``
-      Adds the custom Header with ``name`` as name and ``content`` as
-      the content of the custom HTTP header.
-
-  Examples:
-  ::
-
-     http-proxy-option VERSION 1.1
-     http-proxy-option AGENT OpenVPN/2.4
-     http-proxy-option X-Proxy-Flag some-flags
-
---socks-proxy args
-  Connect to remote host through a Socks5 proxy.  A required ``server``
-  argument is needed.  Optionally a ``port`` (default :code:`1080`) and
-  ``authfile`` can be given.  The ``authfile`` is a file containing a
-  username and password on 2 lines, or :code:`stdin` can be used to
-  prompt from console.
-
---resolv-retry n
-  If hostname resolve fails for ``--remote``, retry resolve for ``n``
-  seconds before failing.
-
-  Set ``n`` to "infinite" to retry indefinitely.
-
-  By default, ``--resolv-retry infinite`` is enabled. You can disable by
-  setting n=0.
-
---float
-  Allow remote peer to change its IP address and/or port number, such as
-  due to DHCP (this is the default if ``--remote`` is not used).
-  ``--float`` when specified with ``--remote`` allows an OpenVPN session
-  to initially connect to a peer at a known address, however if packets
-  arrive from a new address and pass all authentication tests, the new
-  address will take control of the session. This is useful when you are
-  connecting to a peer which holds a dynamic address such as a dial-in
-  user or DHCP client.
-
-  Essentially, ``--float`` tells OpenVPN to accept authenticated packets
-  from any address, not only the address which was specified in the
-  ``--remote`` option.
-
---ipchange cmd
-  Run command ``cmd`` when our remote ip-address is initially
-  authenticated or changes.
-
-  ``cmd`` consists of a path to script (or executable program), optionally
-  followed by arguments. The path and arguments may be single- or
-  double-quoted and/or escaped using a backslash, and should be separated
-  by one or more spaces.
-
-  When ``cmd`` is executed two arguments are appended after any arguments
-  specified in ``cmd`` , as follows:
-  ::
-
-     cmd ip address port number
-
-  Don't use ``--ipchange`` in ``--mode server`` mode. Use a
-  ``--client-connect`` script instead.
-
-  See the `Environmental Variables`_ section below for additional
-  parameters passed as environmental variables.
-
-  If you are running in a dynamic IP address environment where the IP
-  addresses of either peer could change without notice, you can use this
-  script, for example, to edit the :code:`/etc/hosts` file with the current
-  address of the peer. The script will be run every time the remote peer
-  changes its IP address.
-
-  Similarly if *our* IP address changes due to DHCP, we should configure
-  our IP address change script (see man page for ``dhcpcd``\(8)) to
-  deliver a ``SIGHUP`` or ``SIGUSR1`` signal to OpenVPN. OpenVPN will
-  then reestablish a connection with its most recently authenticated
-  peer on its new IP address.
-
---port port
-  TCP/UDP port number or port name for both local and remote (sets both
-  ``--lport`` and ``--rport`` options to given port). The current default
-  of 1194 represents the official IANA port number assignment for OpenVPN
-  and has been used since version 2.0-beta17. Previous versions used port
-  5000 as the default.
-
---lport port
-  Set local TCP/UDP port number or name. Cannot be used together with
-  ``--nobind`` option.
-
---rport port
-  Set TCP/UDP port number or name used by the ``--remote`` option. The
-  port can also be set directly using the ``--remote`` option.
-
---bind keywords
-  Bind to local address and port. This is the default unless any of
-  ``--proto tcp-client`` , ``--http-proxy`` or ``--socks-proxy`` are used.
-
-  If the optional :code:`ipv6only` keyword is present OpenVPN will bind only
-  to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
-
---nobind
-  Do not bind to local address and port. The IP stack will allocate a
-  dynamic port for returning packets. Since the value of the dynamic port
-  could not be known in advance by a peer, this option is only suitable
-  for peers which will be initiating connections by using the --remote
-  option.
-
---dev device
-  TUN/TAP virtual network device which can be :code:`tunX`, :code:`tapX`,
-  :code:`null` or an arbitrary name string (:code:`X` can be omitted for
-  a dynamic device.)
-
-  See examples section below for an example on setting up a TUN device.
-
-  You must use either tun devices on both ends of the connection or tap
-  devices on both ends. You cannot mix them, as they represent different
-  underlying network layers:
-
-  :code:`tun`
-      devices encapsulate IPv4 or IPv6 (OSI Layer 3)
-
-  :code:`tap`
-      devices encapsulate Ethernet 802.3 (OSI Layer 2).
-
---dev-type device-type
-  Which device type are we using? ``device-type`` should be :code:`tun`
-  (OSI Layer 3) or :code:`tap` (OSI Layer 2). Use this option only if
-  the TUN/TAP device used with ``--dev`` does not begin with :code:`tun`
-  or :code:`tap`.
-
---topology mode
-  Configure virtual addressing topology when running in ``--dev tun``
-  mode. This directive has no meaning in ``--dev tap`` mode, which always
-  uses a :code:`subnet` topology.
-
-  If you set this directive on the server, the ``--server`` and
-  ``--server-bridge`` directives will automatically push your chosen
-  topology setting to clients as well. This directive can also be manually
-  pushed to clients. Like the ``--dev`` directive, this directive must
-  always be compatible between client and server.
-
-  ``mode`` can be one of:
-
-  :code:`net30`
-    Use a point-to-point topology, by allocating one /30 subnet
-    per client. This is designed to allow point-to-point semantics when some
-    or all of the connecting clients might be Windows systems. This is the
-    default on OpenVPN 2.0.
-
-  :code:`p2p`
-    Use a point-to-point topology where the remote endpoint of
-    the client's tun interface always points to the local endpoint of the
-    server's tun interface. This mode allocates a single IP address per
-    connecting client. Only use when none of the connecting clients are
-    Windows systems.
-
-  :code:`subnet`
-    Use a subnet rather than a point-to-point topology by
-    configuring the tun interface with a local IP address and subnet mask,
-    similar to the topology used in ``--dev tap`` and ethernet bridging
-    mode. This mode allocates a single IP address per connecting client and
-    works on Windows as well. Only available when server and clients are
-    OpenVPN 2.1 or higher, or OpenVPN 2.0.x which has been manually patched
-    with the ``--topology`` directive code. When used on Windows, requires
-    version 8.2 or higher of the TAP-Win32 driver. When used on \*nix,
-    requires that the tun driver supports an
-    ```ifconfig </man/man2html?8+ifconfig>`__``\ (8) command which sets a
-    subnet instead of a remote endpoint IP address.
-
-  This option exists in OpenVPN 2.1 or higher.
-
-  *Note:* Using ``--topology subnet`` changes the interpretation of the
-  arguments of ``--ifconfig`` to mean "address netmask", no longer "local
-  remote".
-
---dev-node node
-  Explicitly set the device node rather than using :code:`/dev/net/tun`,
-  :code:`/dev/tun`, :code:`/dev/tap`, etc. If OpenVPN cannot figure out
-  whether ``node`` is a TUN or TAP device based on the name, you should
-  also specify ``--dev-type tun`` or ``--dev-type tap``.
-
-  Under Mac OS X this option can be used to specify the default tun
-  implementation. Using ``--dev-node utun`` forces usage of the native
-  Darwin tun kernel support. Use ``--dev-node utunN`` to select a specific
-  utun instance. To force using the :code:`tun.kext` (:code:`/dev/tunX`)
-  use ``--dev-node tun``. When not specifying a ``--dev-node`` option
-  openvpn will first try to open utun, and fall back to tun.kext.
-
-  On Windows systems, select the TAP-Win32 adapter which is named ``node``
-  in the Network Connections Control Panel or the raw GUID of the adapter
-  enclosed by braces. The ``--show-adapters`` option under Windows can
-  also be used to enumerate all available TAP-Win32 adapters and will show
-  both the network connections control panel name and the GUID for each
-  TAP-Win32 adapter.
-
---lladdr address
-  Specify the link layer address, more commonly known as the MAC address.
-  Only applied to TAP devices.
-
---iproute cmd
-  Set alternate command to execute instead of default ``iproute2`` command.
-  May be used in order to execute OpenVPN in unprivileged environment.
-
---ifconfig args
-  Set TUN/TAP adapter parameters. It requires the *IP address* of the local
-  VPN endpoint. For TUN devices in point-to-point mode, the next argument
-  must be the VPN IP address of the remote VPN endpoint. For TAP devices,
-  or TUN devices used with ``--topology subnet``, the second argument
-  is the subnet mask of the virtual network segment which is being created
-  or connected to.
-
-  For TUN devices, which facilitate virtual point-to-point IP connections
-  (when used in ``--topology net30`` or ``p2p`` mode), the proper usage of
-  ``--ifconfig`` is to use two private IP addresses which are not a member
-  of any existing subnet which is in use. The IP addresses may be
-  consecutive and should have their order reversed on the remote peer.
-  After the VPN is established, by pinging ``rn``, you will be pinging
-  across the VPN.
-
-  For TAP devices, which provide the ability to create virtual ethernet
-  segments, or TUN devices in ``--topology subnet`` mode (which create
-  virtual "multipoint networks"), ``--ifconfig`` is used to set an IP
-  address and subnet mask just as a physical ethernet adapter would be
-  similarly configured. If you are attempting to connect to a remote
-  ethernet bridge, the IP address and subnet should be set to values which
-  would be valid on the the bridged ethernet segment (note also that DHCP
-  can be used for the same purpose).
-
-  This option, while primarily a proxy for the ``ifconfig``\(8) command,
-  is designed to simplify TUN/TAP tunnel configuration by providing a
-  standard interface to the different ifconfig implementations on
-  different platforms.
-
-  ``--ifconfig`` parameters which are IP addresses can also be specified
-  as a DNS or /etc/hosts file resolvable name.
-
-  For TAP devices, ``--ifconfig`` should not be used if the TAP interface
-  will be getting an IP address lease from a DHCP server.
-
-  Examples:
-  ::
-
-     # tun device in net30/p2p mode
-     ifconfig 10.8.0.2 10.8.0.1
-
-     # tun/tap device in subnet mode
-     ifconfig 10.8.0.2 255.255.255.0
-
---ifconfig-noexec
-  Don't actually execute ifconfig/netsh commands, instead pass
-  ``--ifconfig`` parameters to scripts using environmental variables.
-
---ifconfig-nowarn
-  Don't output an options consistency check warning if the ``--ifconfig``
-  option on this side of the connection doesn't match the remote side.
-  This is useful when you want to retain the overall benefits of the
-  options consistency check (also see ``--disable-occ`` option) while only
-  disabling the ifconfig component of the check.
-
-  For example, if you have a configuration where the local host uses
-  ``--ifconfig`` but the remote host does not, use ``--ifconfig-nowarn``
-  on the local host.
-
-  This option will also silence warnings about potential address conflicts
-  which occasionally annoy more experienced users by triggering "false
-  positive" warnings.
-
---route args
-  Add route to routing table after connection is established. Multiple
-  routes can be specified. Routes will be automatically torn down in
-  reverse order prior to TUN/TAP device close.
-
-  Valid syntaxes:
-  ::
-
-      route network/IP
-      route network/IP netmask
-      route network/IP netmask gateway
-      route network/IP netmask gateway metric
-
-  This option is intended as a convenience proxy for the ``route``\(8)
-  shell command, while at the same time providing portable semantics
-  across OpenVPN's platform space.
-
-  ``netmask``
-        defaults to :code:`255.255.255.255` when not given
-
-  ``gateway``
-        default taken from ``--route-gateway`` or the second
-        parameter to ``--ifconfig`` when ``--dev tun`` is specified.
-
-  ``metric``
-        default taken from ``--route-metric`` if set, otherwise :code:`0`.
-
-  The default can be specified by leaving an option blank or setting it to
-  :code:`default`.
-
-  The ``network`` and ``gateway`` parameters can also be specified as a
-  DNS or :code:`/etc/hosts` file resolvable name, or as one of three special
-  keywords:
-
-  :code:`vpn_gateway`
-      The remote VPN endpoint address (derived either from
-      ``--route-gateway`` or the second parameter to ``--ifconfig``
-      when ``--dev tun`` is specified).
-
-  :code:`net_gateway`
-      The pre-existing IP default gateway, read from the
-      routing table (not supported on all OSes).
-
-  :code:`remote_host`
-      The ``--remote`` address if OpenVPN is being run in
-      client mode, and is undefined in server mode.
-
---route-gateway arg
-  Specify a default *gateway* for use with ``--route``.
-
-  If :code:`dhcp` is specified as the parameter, the gateway address will
-  be extracted from a DHCP negotiation with the OpenVPN server-side LAN.
-
-  Valid syntaxes:
-  ::
-
-      route-gateway gateway
-      route-gateway dhcp
-
-
---route-metric m
-  Specify a default metric ``m`` for use with ``--route``.
-
---route-delay args
-  Valid syntaxes:
-  ::
-
-       route-delay
-       route-delay n
-       route-delay n m
-
-  Delay ``n`` seconds (default :code:`0`) after connection establishment,
-  before adding routes. If ``n`` is :code:`0`, routes will be added
-  immediately upon connection establishment. If ``--route-delay`` is
-  omitted, routes will be added immediately after TUN/TAP device open and
-  ``--up`` script execution, before any ``--user`` or ``--group`` privilege
-  downgrade (or ``--chroot`` execution.)
-
-  This option is designed to be useful in scenarios where DHCP is used to
-  set tap adapter addresses. The delay will give the DHCP handshake time
-  to complete before routes are added.
-
-  On Windows, ``--route-delay`` tries to be more intelligent by waiting
-  ``w`` seconds (default :code:`30` by default) for the TAP-Win32 adapter
-  to come up before adding routes.
-
---route-up cmd
-  Run command ``cmd`` after routes are added, subject to ``--route-delay``.
-
-  ``cmd`` consists of a path to script (or executable program), optionally
-  followed by arguments. The path and arguments may be single- or
-  double-quoted and/or escaped using a backslash, and should be separated
-  by one or more spaces.
-
-  See the `Environmental Variables`_ section below for additional
-  parameters passed as environmental variables.
-
---route-pre-down cmd
-  Run command ``cmd`` before routes are removed upon disconnection.
-
-  ``cmd`` consists of a path to script (or executable program), optionally
-  followed by arguments. The path and arguments may be single- or
-  double-quoted and/or escaped using a backslash, and should be separated
-  by one or more spaces.
-
-  See the `Environmental Variables`_ section below for additional
-  parameters passed as environmental variables.
-
---route-noexec
-  Don't add or remove routes automatically. Instead pass routes to
-  ``--route-up`` script using environmental variables.
-
---route-nopull
-  When used with ``--client`` or ``--pull``, accept options pushed by
-  server EXCEPT for routes, block-outside-dns and dhcp options like DNS
-  servers.
-
-  When used on the client, this option effectively bars the server from
-  adding routes to the client's routing table, however note that this
-  option still allows the server to set the TCP/IP properties of the
-  client's TUN/TAP interface.
-
---allow-pull-fqdn
-  Allow client to pull DNS names from server (rather than being limited to
-  IP address) for ``--ifconfig``, ``--route``, and ``--route-gateway``.
-
---client-nat args
-  This pushable client option sets up a stateless one-to-one NAT rule on
-  packet addresses (not ports), and is useful in cases where routes or
-  ifconfig settings pushed to the client would create an IP numbering
-  conflict.
-
-  Examples:
-  ::
-
-      client-nat snat 192.168.0.0/255.255.0.0
-      client-nat dnat 10.64.0.0/255.255.0.0
-
-  ``network/netmask`` (for example :code:`192.168.0.0/255.255.0.0`) defines
-  the local view of a resource from the client perspective, while
-  ``alias/netmask`` (for example :code:`10.64.0.0/255.255.0.0`) defines the
-  remote view from the server perspective.
-
-  Use :code:`snat` (source NAT) for resources owned by the client and
-  :code:`dnat` (destination NAT) for remote resources.
-
-  Set ``--verb 6`` for debugging info showing the transformation of
-  src/dest addresses in packets.
-
---redirect-gateway flags
-  Automatically execute routing commands to cause all outgoing IP traffic
-  to be redirected over the VPN. This is a client-side option.
-
-  This option performs three steps:
-
-  (1)  Create a static route for the ``--remote`` address which
-       forwards to the pre-existing default gateway. This is done so that
-       ``(3)`` will not create a routing loop.
-
-  (2)  Delete the default gateway route.
-
-  (3)  Set the new default gateway to be the VPN endpoint address
-       (derived either from ``--route-gateway`` or the second parameter to
-       ``--ifconfig`` when ``--dev tun`` is specified).
-
-  When the tunnel is torn down, all of the above steps are reversed so
-  that the original default route is restored.
-
-  Option flags:
-
-  :code:`local`
-      Add the :code:`local` flag if both OpenVPN peers are directly
-      connected via a common subnet, such as with wireless. The
-      :code:`local` flag will cause step ``(1)`` above to be omitted.
-
-  :code:`autolocal`
-      Try to automatically determine whether to enable :code:`local`
-      flag above.
-
-  :code:`def1`
-      Use this flag to override the default gateway by using
-      :code:`0.0.0.0/1` and :code:`128.0.0.0/1` rather than
-      :code:`0.0.0.0/0`. This has the benefit of overriding but not
-      wiping out the original default gateway.
-
-  :code:`bypass-dhcp`
-      Add a direct route to the DHCP server (if it is non-local) which
-      bypasses the tunnel (Available on Windows clients, may not be
-      available on non-Windows clients).
-
-  :code:`bypass-dns`
-      Add a direct route to the DNS server(s) (if they are non-local)
-      which bypasses the tunnel (Available on Windows clients, may
-      not be available on non-Windows clients).
-
-  :code:`block-local`
-      Block access to local LAN when the tunnel is active, except for
-      the LAN gateway itself. This is accomplished by routing the local
-      LAN (except for the LAN gateway address) into the tunnel.
-
-  :code:`ipv6`
-      Redirect IPv6 routing into the tunnel. This works similar to
-      the :code:`def1` flag, that is, more specific IPv6 routes are added
-      (:code:`2000::/4`, :code:`3000::/4`), covering the whole IPv6
-      unicast space.
-
-  :code:`!ipv4`
-      Do not redirect IPv4 traffic - typically used in the flag pair
-      :code:`ipv6 !ipv4` to redirect IPv6-only.
-
---link-mtu n
-  Sets an upper bound on the size of UDP packets which are sent between
-  OpenVPN peers. *It's best not to set this parameter unless you know what
-  you're doing.*
-
---redirect-private flags
-  Like ``--redirect-gateway``, but omit actually changing the default gateway.
-  Useful when pushing private subnets.
-
---block-ipv6
-  On the client, instead of sending IPv6 packets over the VPN tunnel, all
-  IPv6 packets are answered with an ICMPv6 no route host message. On the
-  server, all IPv6 packets from clients are answered with an ICMPv6 no
-  route to host message. This options is intended for cases when IPv6
-  should be blocked and other options are not available. ``--block-ipv6``
-  will use the remote IPv6 as source address of the ICMPv6 packets if set,
-  otherwise will use :code:`fe80::7` as source address.
-
-  For this option to make sense you actually have to route traffic to the
-  tun interface. The following example config block would send all IPv6
-  traffic to OpenVPN and answer all requests with no route to host,
-  effectively blocking IPv6.
-
-  **Client config**
-    ::
-
-       --ifconfig-ipv6 fd15:53b6:dead::2/64 fd15:53b6:dead::1
-       --redirect-gateway ipv6
-       --block-ipv6
-
-  **Server config**
-    Push a "valid" ipv6 config to the client and block on the server
-    ::
-
-       --push "ifconfig-ipv6 fd15:53b6:dead::2/64 fd15:53b6:dead::1"
-       --push "redirect-gateway ipv6"
-       --block-ipv6
-
---tun-mtu n
-  Take the TUN device MTU to be **n** and derive the link MTU from it
-  (default :code:`1500`). In most cases, you will probably want to leave
-  this parameter set to its default value.
-
-  The MTU (Maximum Transmission Units) is the maximum datagram size in
-  bytes that can be sent unfragmented over a particular network path.
-  OpenVPN requires that packets on the control or data channels be sent
-  unfragmented.
-
-  MTU problems often manifest themselves as connections which hang during
-  periods of active usage.
-
-  It's best to use the ``--fragment`` and/or ``--mssfix`` options to deal
-  with MTU sizing issues.
-
---tun-mtu-extra n
-  Assume that the TUN/TAP device might return as many as ``n`` bytes more
-  than the ``--tun-mtu`` size on read. This parameter defaults to 0, which
-  is sufficient for most TUN devices. TAP devices may introduce additional
-  overhead in excess of the MTU size, and a setting of 32 is the default
-  when TAP devices are used. This parameter only controls internal OpenVPN
-  buffer sizing, so there is no transmission overhead associated with
-  using a larger value.
-
---mtu-disc type
-  Should we do Path MTU discovery on TCP/UDP channel? Only supported on
-  OSes such as Linux that supports the necessary system call to set.
-
-  Valid types:
-
-  :code:`no`      Never send DF (Don't Fragment) frames
-
-  :code:`maybe`   Use per-route hints
-
-  :code:`yes`     Always DF (Don't Fragment)
-
---mtu-test
-  To empirically measure MTU on connection startup, add the ``--mtu-test``
-  option to your configuration. OpenVPN will send ping packets of various
-  sizes to the remote peer and measure the largest packets which were
-  successfully received. The ``--mtu-test`` process normally takes about 3
-  minutes to complete.
-
---fragment max
-  Enable internal datagram fragmentation so that no UDP datagrams are sent
-  which are larger than ``max`` bytes.
-
-  The ``max`` parameter is interpreted in the same way as the
-  ``--link-mtu`` parameter, i.e. the UDP packet size after encapsulation
-  overhead has been added in, but not including the UDP header itself.
-
-  The ``--fragment`` option only makes sense when you are using the UDP
-  protocol (``--proto udp``).
-
-  ``--fragment`` adds 4 bytes of overhead per datagram.
-
-  See the ``--mssfix`` option below for an important related option to
-  ``--fragment``.
-
-  It should also be noted that this option is not meant to replace UDP
-  fragmentation at the IP stack level. It is only meant as a last resort
-  when path MTU discovery is broken. Using this option is less efficient
-  than fixing path MTU discovery for your IP link and using native IP
-  fragmentation instead.
-
-  Having said that, there are circumstances where using OpenVPN's internal
-  fragmentation capability may be your only option, such as tunneling a
-  UDP multicast stream which requires fragmentation.
-
---mssfix max
-  Announce to TCP sessions running over the tunnel that they should limit
-  their send packet sizes such that after OpenVPN has encapsulated them,
-  the resulting UDP packet size that OpenVPN sends to its peer will not
-  exceed ``max`` bytes. The default value is :code:`1450`.
-
-  The ``max`` parameter is interpreted in the same way as the
-  ``--link-mtu`` parameter, i.e. the UDP packet size after encapsulation
-  overhead has been added in, but not including the UDP header itself.
-  Resulting packet would be at most 28 bytes larger for IPv4 and 48 bytes
-  for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header). Default
-  value of 1450 allows IPv4 packets to be transmitted over a link with MTU
-  1473 or higher without IP level fragmentation.
-
-  The ``--mssfix`` option only makes sense when you are using the UDP
-  protocol for OpenVPN peer-to-peer communication, i.e. ``--proto udp``.
-
-  ``--mssfix`` and ``--fragment`` can be ideally used together, where
-  ``--mssfix`` will try to keep TCP from needing packet fragmentation in
-  the first place, and if big packets come through anyhow (from protocols
-  other than TCP), ``--fragment`` will internally fragment them.
-
-  Both ``--fragment`` and ``--mssfix`` are designed to work around cases
-  where Path MTU discovery is broken on the network path between OpenVPN
-  peers.
-
-  The usual symptom of such a breakdown is an OpenVPN connection which
-  successfully starts, but then stalls during active usage.
-
-  If ``--fragment`` and ``--mssfix`` are used together, ``--mssfix`` will
-  take its default ``max`` parameter from the ``--fragment max`` option.
-
-  Therefore, one could lower the maximum UDP packet size to 1300 (a good
-  first try for solving MTU-related connection problems) with the
-  following options:
-  ::
-
-     --tun-mtu 1500 --fragment 1300 --mssfix
-
---sndbuf size
-  Set the TCP/UDP socket send buffer size. Defaults to operation system
-  default.
-
---rcvbuf size
-  Set the TCP/UDP socket receive buffer size. Defaults to operation system
-  default.
-
---mark value
-  Mark encrypted packets being sent with value. The mark value can be
-  matched in policy routing and packetfilter rules. This option is only
-  supported in Linux and does nothing on other operating systems.
-
---socket-flags flags
-  Apply the given flags to the OpenVPN transport socket. Currently, only
-  :code:`TCP_NODELAY` is supported.
-
-  The :code:`TCP_NODELAY` socket flag is useful in TCP mode, and causes the
-  kernel to send tunnel packets immediately over the TCP connection without
-  trying to group several smaller packets into a larger packet.  This can
-  result in a considerably improvement in latency.
-
-  This option is pushable from server to client, and should be used on
-  both client and server for maximum effect.
-
---txqueuelen n
-  *(Linux only)* Set the TX queue length on the TUN/TAP interface.
-  Currently defaults to 100.
-
---shaper n
-  Limit bandwidth of outgoing tunnel data to ``n`` bytes per second on the
-  TCP/UDP port. Note that this will only work if mode is set to
-  :code:`p2p`.  If you want to limit the bandwidth in both directions, use
-  this option on both peers.
-
-  OpenVPN uses the following algorithm to implement traffic shaping: Given
-  a shaper rate of ``n`` bytes per second, after a datagram write of ``b``
-  bytes is queued on the TCP/UDP port, wait a minimum of ``(b / n)``
-  seconds before queuing the next write.
-
-  It should be noted that OpenVPN supports multiple tunnels between the
-  same two peers, allowing you to construct full-speed and reduced
-  bandwidth tunnels at the same time, routing low-priority data such as
-  off-site backups over the reduced bandwidth tunnel, and other data over
-  the full-speed tunnel.
-
-  Also note that for low bandwidth tunnels (under 1000 bytes per second),
-  you should probably use lower MTU values as well (see above), otherwise
-  the packet latency will grow so large as to trigger timeouts in the TLS
-  layer and TCP connections running over the tunnel.
-
-  OpenVPN allows ``n`` to be between 100 bytes/sec and 100 Mbytes/sec.
-
---inactive args
-  Causes OpenVPN to exit after ``n`` seconds of inactivity on the TUN/TAP
-  device. The time length of inactivity is measured since the last
-  incoming or outgoing tunnel packet. The default value is 0 seconds,
-  which disables this feature.
-
-  Valid syntaxes:
-  ::
-
-       inactive n
-       inactive n bytes
-
-  If the optional ``bytes`` parameter is included, exit if less than
-  ``bytes`` of combined in/out traffic are produced on the tun/tap device
-  in ``n`` seconds.
-
-  In any case, OpenVPN's internal ping packets (which are just keepalives)
-  and TLS control packets are not considered "activity", nor are they
-  counted as traffic, as they are used internally by OpenVPN and are not
-  an indication of actual user activity.
-
---ping n
-  Ping remote over the TCP/UDP control channel if no packets have been
-  sent for at least ``n`` seconds (specify ``--ping`` on both peers to
-  cause ping packets to be sent in both directions since OpenVPN ping
-  packets are not echoed like IP ping packets). When used in one of
-  OpenVPN's secure modes (where ``--secret``, ``--tls-server`` or
-  ``--tls-client`` is specified), the ping packet will be
-  cryptographically secure.
-
-  This option has two intended uses:
-
-  (1)  Compatibility with stateful firewalls. The periodic ping will ensure
-       that a stateful firewall rule which allows OpenVPN UDP packets to
-       pass will not time out.
-
-  (2)  To provide a basis for the remote to test the existence of its peer
-       using the ``--ping-exit`` option.
-
---ping-exit n
-  Causes OpenVPN to exit after ``n`` seconds pass without reception of a
-  ping or other packet from remote. This option can be combined with
-  ``--inactive``, ``--ping`` and ``--ping-exit`` to create a two-tiered
-  inactivity disconnect.
-
-  For example,
-  ::
-
-      openvpn [options...] --inactive 3600 --ping 10 --ping-exit 60
-
-  when used on both peers will cause OpenVPN to exit within 60 seconds if
-  its peer disconnects, but will exit after one hour if no actual tunnel
-  data is exchanged.
-
---ping-restart n
-  Similar to ``--ping-exit``, but trigger a :code:`SIGUSR1` restart after
-  ``n`` seconds pass without reception of a ping or other packet from
-  remote.
-
-  This option is useful in cases where the remote peer has a dynamic IP
-  address and a low-TTL DNS name is used to track the IP address using a
-  service such as http://dyndns.org/ + a dynamic DNS client such as
-  ``ddclient``.
-
-  If the peer cannot be reached, a restart will be triggered, causing the
-  hostname used with ``--remote`` to be re-resolved (if ``--resolv-retry``
-  is also specified).
-
-  In server mode, ``--ping-restart``, ``--inactive`` or any other type of
-  internally generated signal will always be applied to individual client
-  instance objects, never to whole server itself. Note also in server mode
-  that any internally generated signal which would normally cause a
-  restart, will cause the deletion of the client instance object instead.
-
-  In client mode, the ``--ping-restart`` parameter is set to 120 seconds
-  by default. This default will hold until the client pulls a replacement
-  value from the server, based on the ``--keepalive`` setting in the
-  server configuration. To disable the 120 second default, set
-  ``--ping-restart 0`` on the client.
-
-  See the signals section below for more information on :code:`SIGUSR1`.
-
-  Note that the behavior of ``SIGUSR1`` can be modified by the
-  ``--persist-tun``, ``--persist-key``, ``--persist-local-ip`` and
-  ``--persist-remote-ip`` options.
-
-  Also note that ``--ping-exit`` and ``--ping-restart`` are mutually
-  exclusive and cannot be used together.
-
---keepalive args
-  A helper directive designed to simplify the expression of ``--ping`` and
-  ``--ping-restart``.
-
-  Valid syntax:
-  ::
-
-     keepalive interval timeout
-
-  This option can be used on both client and server side, but it is enough
-  to add this on the server side as it will push appropriate ``--ping``
-  and ``--ping-restart`` options to the client. If used on both server and
-  client, the values pushed from server will override the client local
-  values.
-
-  The ``timeout`` argument will be twice as long on the server side. This
-  ensures that a timeout is detected on client side before the server side
-  drops the connection.
-
-  For example, ``--keepalive 10 60`` expands as follows:
-  ::
-
-     if mode server:
-         ping 10                    # Argument: interval
-         ping-restart 120           # Argument: timeout*2
-         push "ping 10"             # Argument: interval
-         push "ping-restart 60"     # Argument: timeout
-     else
-         ping 10                    # Argument: interval
-         ping-restart 60            # Argument: timeout
-
---ping-timer-rem
-  Run the ``--ping-exit`` / ``--ping-restart`` timer only if we have a
-  remote address. Use this option if you are starting the daemon in listen
-  mode (i.e. without an explicit ``--remote`` peer), and you don't want to
-  start clocking timeouts until a remote peer connects.
-
---persist-tun
-  Don't close and reopen TUN/TAP device or run up/down scripts across
-  :code:`SIGUSR1` or ``--ping-restart`` restarts.
-
-  :code:`SIGUSR1` is a restart signal similar to :code:`SIGHUP`, but which
-  offers finer-grained control over reset options.
-
---persist-key
-  Don't re-read key files across :code:`SIGUSR1` or ``--ping-restart``.
-
-  This option can be combined with ``--user nobody`` to allow restarts
-  triggered by the :code:`SIGUSR1` signal. Normally if you drop root
-  privileges in OpenVPN, the daemon cannot be restarted since it will now
-  be unable to re-read protected key files.
-
-  This option solves the problem by persisting keys across :code:`SIGUSR1`
-  resets, so they don't need to be re-read.
-
---persist-local-ip
-  Preserve initially resolved local IP address and port number across
-  ``SIGUSR1`` or ``--ping-restart`` restarts.
-
---persist-remote-ip
-  Preserve most recently authenticated remote IP address and port number
-  across :code:`SIGUSR1` or ``--ping-restart`` restarts.
-
---mlock
-  Disable paging by calling the POSIX mlockall function. Requires that
-  OpenVPN be initially run as root (though OpenVPN can subsequently
-  downgrade its UID using the ``--user`` option).
-
-  Using this option ensures that key material and tunnel data are never
-  written to disk due to virtual memory paging operations which occur
-  under most modern operating systems. It ensures that even if an attacker
-  was able to crack the box running OpenVPN, he would not be able to scan
-  the system swap file to recover previously used ephemeral keys, which
-  are used for a period of time governed by the ``--reneg`` options (see
-  below), then are discarded.
-
-  The downside of using ``--mlock`` is that it will reduce the amount of
-  physical memory available to other applications.
-
---up cmd
-  Run command ``cmd`` after successful TUN/TAP device open (pre ``--user``
-  UID change).
-
-  ``cmd`` consists of a path to script (or executable program), optionally
-  followed by arguments. The path and arguments may be single- or
-  double-quoted and/or escaped using a backslash, and should be separated
-  by one or more spaces.
-
-  The up command is useful for specifying route commands which route IP
-  traffic destined for private subnets which exist at the other end of the
-  VPN connection into the tunnel.
-
-  For ``--dev tun`` execute as:
-  ::
-
-      cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [init | restart]
-
-  For ``--dev tap`` execute as:
-  ::
-
-       cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [init | restart]
-
-  See the `Environmental Variables`_ section below for additional
-  parameters passed as environmental variables.
-
-  Note that if ``cmd`` includes arguments, all OpenVPN-generated arguments
-  will be appended to them to build an argument list with which the
-  executable will be called.
-
-  Typically, ``cmd`` will run a script to add routes to the tunnel.
-
-  Normally the up script is called after the TUN/TAP device is opened. In
-  this context, the last command line parameter passed to the script will
-  be *init.* If the ``--up-restart`` option is also used, the up script
-  will be called for restarts as well. A restart is considered to be a
-  partial reinitialization of OpenVPN where the TUN/TAP instance is
-  preserved (the ``--persist-tun`` option will enable such preservation).
-  A restart can be generated by a SIGUSR1 signal, a ``--ping-restart``
-  timeout, or a connection reset when the TCP protocol is enabled with the
-  ``--proto`` option. If a restart occurs, and ``--up-restart`` has been
-  specified, the up script will be called with *restart* as the last
-  parameter.
-
-  *NOTE:*
-     On restart, OpenVPN will not pass the full set of environment
-     variables to the script. Namely, everything related to routing and
-     gateways will not be passed, as nothing needs to be done anyway - all
-     the routing setup is already in place. Additionally, the up-restart
-     script will run with the downgraded UID/GID settings (if configured).
-
-  The following standalone example shows how the ``--up`` script can be
-  called in both an initialization and restart context. (*NOTE:* for
-  security reasons, don't run the following example unless UDP port 9999
-  is blocked by your firewall. Also, the example will run indefinitely, so
-  you should abort with control-c).
-
-  ::
-
-      openvpn --dev tun --port 9999 --verb 4 --ping-restart 10 \
-              --up 'echo up' --down 'echo down' --persist-tun  \
-              --up-restart
-
-  Note that OpenVPN also provides the ``--ifconfig`` option to
-  automatically ifconfig the TUN device, eliminating the need to define an
-  ``--up`` script, unless you also want to configure routes in the
-  ``--up`` script.
-
-  If ``--ifconfig`` is also specified, OpenVPN will pass the ifconfig
-  local and remote endpoints on the command line to the ``--up`` script so
-  that they can be used to configure routes such as:
-
-  ::
-
-      route add -net 10.0.0.0 netmask 255.255.255.0 gw $5
-
---up-delay
-  Delay TUN/TAP open and possible ``--up`` script execution until after
-  TCP/UDP connection establishment with peer.
-
-  In ``--proto udp`` mode, this option normally requires the use of
-  ``--ping`` to allow connection initiation to be sensed in the absence of
-  tunnel data, since UDP is a "connectionless" protocol.
-
-  On Windows, this option will delay the TAP-Win32 media state
-  transitioning to "connected" until connection establishment, i.e. the
-  receipt of the first authenticated packet from the peer.
-
---down cmd
-  Run command ``cmd`` after TUN/TAP device close (post ``--user`` UID
-  change and/or ``--chroot`` ). ``cmd`` consists of a path to script (or
-  executable program), optionally followed by arguments. The path and
-  arguments may be single- or double-quoted and/or escaped using a
-  backslash, and should be separated by one or more spaces.
-
-  Called with the same parameters and environmental variables as the
-  ``--up`` option above.
-
-  Note that if you reduce privileges by using ``--user`` and/or
-  ``--group``, your ``--down`` script will also run at reduced privilege.
-
---down-pre
-  Call ``--down`` cmd/script before, rather than after, TUN/TAP close.
-
---up-restart
-  Enable the ``--up`` and ``--down`` scripts to be called for restarts as
-  well as initial program start. This option is described more fully above
-  in the ``--up`` option documentation.
-
---setenv args
-  Set a custom environmental variable :code:`name=value` to pass to script.
-
-  Valid syntaxes:
-  ::
-
-     setenv name value
-     setenv FORWARD_COMPATIBLE 1
-     setenv opt config_option
-
-  By setting :code:`FORWARD_COMPATIBLE` to :code:`1`, the config file
-  syntax checking is relaxed so that unknown directives will trigger a
-  warning but not a fatal error, on the assumption that a given unknown
-  directive might be valid in future OpenVPN versions.
-
-  This option should be used with caution, as there are good security
-  reasons for having OpenVPN fail if it detects problems in a config file.
-  Having said that, there are valid reasons for wanting new software
-  features to gracefully degrade when encountered by older software
-  versions.
-
-  It is also possible to tag a single directive so as not to trigger a
-  fatal error if the directive isn't recognized. To do this, prepend the
-  following before the directive: ``setenv opt``
-
-  Versions prior to OpenVPN 2.3.3 will always ignore options set with the
-  ``setenv opt`` directive.
-
-  See also ``--ignore-unknown-option``
-
---setenv-safe args
-  Set a custom environmental variable :code:`OPENVPN_name` to :code:`value`
-  to pass to scripts.
-
-  Valid syntaxes:
-  ::
-
-     setenv-safe name value
-
-  This directive is designed to be pushed by the server to clients, and
-  the prepending of :code:`OPENVPN_` to the environmental variable is a
-  safety precaution to prevent a :code:`LD_PRELOAD` style attack from a
-  malicious or compromised server.
-
---ignore-unknown-option args
-  Valid syntax:
-  ::
-
-     ignore-unknown-options opt1 opt2 opt3 ... optN
-
-  When one of options ``opt1 ... optN`` is encountered in the configuration
-  file the configuration file parsing does not fail if this OpenVPN version
-  does not support the option. Multiple ``--ignore-unknown-option`` options
-  can be given to support a larger number of options to ignore.
-
-  This option should be used with caution, as there are good security
-  reasons for having OpenVPN fail if it detects problems in a config file.
-  Having said that, there are valid reasons for wanting new software
-  features to gracefully degrade when encountered by older software
-  versions.
-
-  ``--ignore-unknown-option`` is available since OpenVPN 2.3.3.
-
---script-security level
-  This directive offers policy-level control over OpenVPN's usage of
-  external programs and scripts. Lower ``level`` values are more
-  restrictive, higher values are more permissive. Settings for ``level``:
-
-  :code:`0`
-      Strictly no calling of external programs.
-
-  :code:`1`
-      (Default) Only call built-in executables such as ifconfig,
-      ip, route, or netsh.
-
-  :code:`2`
-      Allow calling of built-in executables and user-defined
-      scripts.
-
-  :code:`3`
-      Allow passwords to be passed to scripts via environmental
-      variables (potentially unsafe).
-
-  OpenVPN releases before v2.3 also supported a ``method`` flag which
-  indicated how OpenVPN should call external commands and scripts. This
-  could be either :code:`execve` or :code:`system`. As of OpenVPN 2.3, this
-  flag is no longer accepted. In most \*nix environments the execve()
-  approach has been used without any issues.
-
-  Some directives such as ``--up`` allow options to be passed to the
-  external script. In these cases make sure the script name does not
-  contain any spaces or the configuration parser will choke because it
-  can't determine where the script name ends and script options start.
-
-  To run scripts in Windows in earlier OpenVPN versions you needed to
-  either add a full path to the script interpreter which can parse the
-  script or use the ``system`` flag to run these scripts. As of OpenVPN
-  2.3 it is now a strict requirement to have full path to the script
-  interpreter when running non-executables files. This is not needed for
-  executable files, such as .exe, .com, .bat or .cmd files. For example,
-  if you have a Visual Basic script, you must use this syntax now:
-
-  ::
-
-     --up 'C:\\Windows\\System32\\wscript.exe C:\\Program\ Files\\OpenVPN\\config\\my-up-script.vbs'
-
-  Please note the single quote marks and the escaping of the backslashes
-  (\\) and the space character.
-
-  The reason the support for the :code:`system` flag was removed is due to
-  the security implications with shell expansions when executing scripts
-  via the :code:`system()` call.
-
---disable-occ
-  Don't output a warning message if option inconsistencies are detected
-  between peers. An example of an option inconsistency would be where one
-  peer uses ``--dev tun`` while the other peer uses ``--dev tap``.
-
-  Use of this option is discouraged, but is provided as a temporary fix in
-  situations where a recent version of OpenVPN must connect to an old
-  version.
-
---user user
-  Change the user ID of the OpenVPN process to ``user`` after
-  initialization, dropping privileges in the process. This option is
-  useful to protect the system in the event that some hostile party was
-  able to gain control of an OpenVPN session. Though OpenVPN's security
-  features make this unlikely, it is provided as a second line of defense.
-
-  By setting ``user`` to :code:`nobody` or somebody similarly unprivileged,
-  the hostile party would be limited in what damage they could cause. Of
-  course once you take away privileges, you cannot return them to an
-  OpenVPN session. This means, for example, that if you want to reset an
-  OpenVPN daemon with a :code:`SIGUSR1` signal (for example in response to
-  a DHCP reset), you should make use of one or more of the ``--persist``
-  options to ensure that OpenVPN doesn't need to execute any privileged
-  operations in order to restart (such as re-reading key files or running
-  ``ifconfig`` on the TUN device).
-
---group group
-  Similar to the ``--user`` option, this option changes the group ID of
-  the OpenVPN process to ``group`` after initialization.
-
---cd dir
-  Change directory to ``dir`` prior to reading any files such as
-  configuration files, key files, scripts, etc. ``dir`` should be an
-  absolute path, with a leading "/", and without any references to the
-  current directory such as :code:`.` or :code:`..`.
-
-  This option is useful when you are running OpenVPN in ``--daemon`` mode,
-  and you want to consolidate all of your OpenVPN control files in one
-  location.
-
---chroot dir
-  Chroot to ``dir`` after initialization. ``--chroot`` essentially
-  redefines ``dir`` as being the top level directory tree (/). OpenVPN
-  will therefore be unable to access any files outside this tree. This can
-  be desirable from a security standpoint.
-
-  Since the chroot operation is delayed until after initialization, most
-  OpenVPN options that reference files will operate in a pre-chroot
-  context.
-
-  In many cases, the ``dir`` parameter can point to an empty directory,
-  however complications can result when scripts or restarts are executed
-  after the chroot operation.
-
-  Note: The SSL library will probably need /dev/urandom to be available
-  inside the chroot directory ``dir``. This is because SSL libraries
-  occasionally need to collect fresh random. Newer linux kernels and some
-  BSDs implement a getrandom() or getentropy() syscall that removes the
-  need for /dev/urandom to be available.
-
---setcon context
-  Apply SELinux ``context`` after initialization. This essentially
-  provides the ability to restrict OpenVPN's rights to only network I/O
-  operations, thanks to SELinux. This goes further than ``--user`` and
-  ``--chroot`` in that those two, while being great security features,
-  unfortunately do not protect against privilege escalation by
-  exploitation of a vulnerable system call. You can of course combine all
-  three, but please note that since setcon requires access to /proc you
-  will have to provide it inside the chroot directory (e.g. with mount
-  --bind).
-
-  Since the setcon operation is delayed until after initialization,
-  OpenVPN can be restricted to just network-related system calls, whereas
-  by applying the context before startup (such as the OpenVPN one provided
-  in the SELinux Reference Policies) you will have to allow many things
-  required only during initialization.
-
-  Like with chroot, complications can result when scripts or restarts are
-  executed after the setcon operation, which is why you should really
-  consider using the ``--persist-key`` and ``--persist-tun`` options.
-
---daemon progname
-  Become a daemon after all initialization functions are completed. This
-  option will cause all message and error output to be sent to the syslog
-  file (such as :code:`/var/log/messages`), except for the output of
-  scripts and ifconfig commands, which will go to :code:`/dev/null` unless
-  otherwise redirected. The syslog redirection occurs immediately at the
-  point that ``--daemon`` is parsed on the command line even though the
-  daemonization point occurs later. If one of the ``--log`` options is
-  present, it will supersede syslog redirection.
-
-  The optional ``progname`` parameter will cause OpenVPN to report its
-  program name to the system logger as ``progname``. This can be useful in
-  linking OpenVPN messages in the syslog file with specific tunnels. When
-  unspecified, ``progname`` defaults to "openvpn".
-
-  When OpenVPN is run with the ``--daemon`` option, it will try to delay
-  daemonization until the majority of initialization functions which are
-  capable of generating fatal errors are complete. This means that
-  initialization scripts can test the return status of the openvpn command
-  for a fairly reliable indication of whether the command has correctly
-  initialized and entered the packet forwarding event loop.
-
-  In OpenVPN, the vast majority of errors which occur after initialization
-  are non-fatal.
-
-  Note: as soon as OpenVPN has daemonized, it can not ask for usernames,
-  passwords, or key pass phrases anymore. This has certain consequences,
-  namely that using a password-protected private key will fail unless the
-  ``--askpass`` option is used to tell OpenVPN to ask for the pass phrase
-  (this requirement is new in v2.3.7, and is a consequence of calling
-  daemon() before initializing the crypto layer).
-
-  Further, using ``--daemon`` together with ``--auth-user-pass`` (entered
-  on console) and ``--auth-nocache`` will fail as soon as key
-  renegotiation (and reauthentication) occurs.
-
---syslog progname
-  Direct log output to system logger, but do not become a daemon. See
-  ``--daemon`` directive above for description of ``progname`` parameter.
-
---errors-to-stderr
-  O...
 
[truncated message content]