Сети‎ > ‎VPN‎ > ‎Параметры OpenVPN‎ > ‎

Tunnel

Tunnel Options (Ч1):

--mode m
Устанавливает основной режим работы. По умолчанию OpenVPN запускается в режиме point-to-point mode ("p2p").  OpenVPN 2.0 поддерживает также режим "server" в котором доступны мультиклиентские возможности серверов. 
--local host
Local host name или IP address для сыязывания. Если определен, OpenVPN будет опредляться только для соединения по этому адрессу. Если не определено, то OpenVPN будет дейтсовать на все интерфейсы устройства.   
--remote host [port] [proto]
Remote host name или IP address. На клиенте несколько параметров --remote  может быть определно для резервируемого соединения, где каждая запись ссылается на другой OpenVPN server. Определение несколько  параметров --remote для этих целей является частным случаем более общего connection-profile, где кроме хоста и порта можна настроить доп. параметры.  См. <connection>.
OpenVPN client будет пытаться подключиться к серверу по host:port в порядке, определенном списку параметров --remote.
proto определяет протокол, используемый для соединения: "tcp" или "udp".
Клиент будет двигаться к следующей по списку записи если соединение не получится.  
Обратите внимание, что:
- в один момент времени клиент может быть подлючен только к одному серверу;
- поскольку  UDP не требует соединение, то сбои в связи определяются параметрами --ping и --ping-restart.
- если используются несколько параметров --remote  и сбрасываете привелегии root на клиентской машине с --user или/и --group (не на Windows OS) и клиент будет переключаться на другой сервер, и этот сервер отодвигает (pushes back) различные  TUN/TAP или настройки маршрутизации, у клиента может не хватить привилегий для заккрытия и повторного открытия интерфейса TUN/TAP, что может привести к фатальной ошибке на клиенте. 
Если параметр --remote не задан, OpenVPN будет принимать все пакеты с любого IP адреса,  но не будет их обрабатывать, если они не прошли проверку аутентификации. Это требование для аутентификации является обязательным для всех потенциальных соединений, даже для известных и якобы надежных IP-адресов (это очень легко подделать IP-адрес источника в пакете UDP). 
Если используется TCP mode, --remote будет действовать как фильтр, отвергая соединение от любого хоста, который отсутствует в списке host.
Если host - это имя DNS который разрешает несколько IP addresses, будет выбираться один из них случайным образом в качетсве базового. 
--remote-random-hostname
Добавляет случайную последовательность (6 символов) к первой части DNS-имени для предотвращения кеширования DNS. Например  
"foo.bar.gov" будет изменен на "<random-chars>.foo.bar.gov".
<connection>
Определяет профиль клиентского соединения. Профили клиентских соединений (Client connection profiles) - группа параметров OpenVPN, которые определяют как соединяться с этим OpenVPN server. Профили клиентских соединений определяются в OpenVPN configuration file, и каждый профиль обрамляется <connection> и </connection>.
OpenVPN client будет пытаться соединиться согласно списку профилей, пока не получиться соединиться.
--remote-random может быть использовано для первоначального выбора профиля из списка.
Пример:
client dev tun <connection> remote 198.19.34.56 1194 udp </connection> <connection> remote 198.19.34.56 443 tcp </connection> <connection> remote 198.19.34.56 443 tcp http-proxy 192.168.0.8 8080 http-proxy-retry </connection> <connection> remote 198.19.36.99 443 tcp http-proxy 192.168.0.8 8080 http-proxy-retry </connection> persist-key persist-tun pkcs12 client.p12 ns-cert-type server verb 3
Первоначально мы пыатемся подключиться к серверу по 198.19.34.56:1194 используя UDP. Если подключение не удалось, следущая попытка идет по 198.19.34.56:443 используя TCP. Если и тут плохо, то через HTTP proxy (192.168.0.8:8080) к 198.19.34.56:443 используя TCP. Последняя попытка через тот же proxy но к 198.19.36.99:443 используя TCP.
Следующие параметры OpenVPN могут быть использованы в блоке <connection>: bind, connect-retry, connect-retry-max, connect-timeout, explicit-exit-notify, float, fragment, http-proxy, http-proxy-option, http-proxy-retry, http-proxy-timeout, link-mtu, local, lport, mssfix, mtu-disc, nobind, port, proto, remote, rport, socks-proxy, socks-proxy-retry, tun-mtu and tun-mtu-extra.
Можно определить параметры "по умолчанию" для всех профилей <connection> . Если параметры (за исключениме remote ) появляются выше за пределами блока <connection> , но в конфигурационном файле есть такие блоки, то эти параметры будут использоваться как по умолчанию для этих блоков.  Например, предположим параметр nobind находится в том же конфигурационном файле высше первого блока <connection>. Это будет работать так, как будто этот параметр был определен в каждом из ниженаходящихся блоков <connection> 
--proto-force p
При переборе профилей, рассматривать только профили, использующие проткол p ('tcp' или 'udp').
--remote-random
Если указано несколько  --remote address/ports, или если используются профили соединения (<connection>), используется случайный в списке remote.
--proto p
Использовать проткол p дл соединения с удаленным хостом: udp, tcp-client, or tcp-server 
По умолчанию используется протокол  udp если --proto не указан.
При указании --proto udp должно быть указано в обоих концах.
Для соединений TCP, в одном конце должен использоваться --proto tcp-server а в другом должен использоваться --proto tcp-client. Узел, стартовавший с tcp-server будет бесконечно ожидать входящего соединения. Узел, стартовавший как tcp-client будет пытаться соединиться, и в случае ошибки, будет ожидать 5 секунд (настраиваются через параметр --connect-retry ) и пытается соединиться бесконечное количество раз или до N раз (настраивается через параметр --connect-retry-max). Оба TCP client и server будут имитировать SIGUSR1 сигнал перезапуска если одна из сторон сбрасывает соединение.  
OpenVPN разработан для оптимального функционирования поверх UDP, однако доступно также использование TCP, если UDP по каким-то причинам не может быть использовано. В сравнении с  UDP, TCP будет менее эффективным при использовании в перегруженных сетях. Детальнее о сравнении http://sites.inka.de/sites/bigred/devel/tcp-tcp.html . TCP может быть использован например в случаях, когда поверху используются ненадежные протоколы.
--connect-retry n
Для--proto tcp-client, значение n - это время в секундах между повторными соединениями (по умолчанию=5).
--connect-timeout n
Для --proto tcp-client, это время ожидания в секундах n для каждого соединения (default=10).
--connect-retry-max n
Для --proto tcp-client, значение n это количество попыток соединения (default=infinite).
PROXY
--show-proxy-settings
Показывается какой тип прокси используется: HTTP или SOCKS. Только для Windows clients.
--http-proxy server port [authfile|'auto'|'auto-nct'] [auth-method]
Соединение с удаленным хостом через HTTP-прокси по address server и port port. Если требуется аутентификация на прокси,  указывается authfile как файл, содержащий имя пользователя и пароль в двох строках, или "stdin" для ввода с консоли.
auth-method может быть "none", "basic", или "ntlm".
HTTP Digest authentication is supported as well, but only via the auto or auto-nct flags (below). The 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.
--http-proxy-retry
Retry indefinitely on HTTP proxy errors. If an HTTP proxy error occurs, simulate a SIGUSR1 reset.
--http-proxy-timeout n
Set proxy timeout to n seconds, default=5.
--http-proxy-option type [parm]
Set extended HTTP proxy options. Repeat to set multiple options.
VERSION version -- Set HTTP version number to version (default=1.0).
AGENT user-agent -- Set HTTP "User-Agent" string to user-agent.
--socks-proxy server [port]
Connect to remote host through a Socks5 proxy at address server and port port (default=1080).
--socks-proxy-retry
Retry indefinitely on Socks proxy errors. If a Socks proxy error occurs, simulate a SIGUSR1 reset.

--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
Разрешить удаленному узлу изменить  IP address и/или номер порта, например по причине DHCP (это по умолчанию стоит если --remote  не используется). Параметр --float при указании --remote дает возможность при OpenVPN сессии иницировать соединение с удаленны узлом по известному адрессу, однако если пакеты приходят от нового адресса и проходят все тесты аутентификации, новый адрес будет взят под контроль сессиии. Этот параметр полезен при использовании дианмического адресса на удаленном узле.
То есть --float указывает, что можно принимать данные с любого IP адресса, а не только указанного в параметре --remote .
--ipchange cmd
Запуск команды cmd если удаленный ip-address в начале проверки аутентификации или изменения.
cmd содержит путь скрипта (программы) и аргументов (опционально). Путь и аргументы могут быть в одинарных или двойных кавычках и/или escaped using a backslash, and should be separated by one or more spaces.
Если 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 /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 порта для обоих узлов: локального и удаленного. По умолчанию - 1194 (official IANA port для OpenVPN с version 2.0-beta17). Предыдущие версии использовали порт 5000 по умолчанию.
--lport port
TCP/UDP port number локальный.
--rport port
TCP/UDP port number удаленный.
--bind
Привязаться к локальному адресу и порту. Это значение по умолчанию если не используется --proto tcp-client , --http-proxy или --socks-proxy are used.
--nobind
Не привязываться к локальному адресу и порту. IP-стек будет выделять динамический порт для входящих пакетов. Так как значение динамического порта не известен заранее, этот параметр доступен только при установленом параметре --remote.  
--dev tunX | tapX | null
Тип (TUN или TAP) устройства (комуникац порта) виртуальной сети ( X может быть опущен для динамических устройств). См. примеры.
Вы должны использовать на обох концах одинаковый тип устройства. tun устройство инкапсулирует датаграммы IPv4 или IPv6 (OSI Layer 3) тогда как tap устройство инкапсулирует кадры Ethernet 802.3 (OSI Layer 2).
--dev-type device-type
Which device type are we using? device-type should be tun (OSI Layer 3) or tap (OSI Layer 2). Use this option only if the TUN/TAP device used with --dev does not begin with tun or tap.
--topology mode
Конфигурирется виртуальная адресная топология, если выбран --dev tun mode. Этот параметр не имеет никакого смысла при при --dev tap режиме, поскольку там всегда используется топология subnet.
Если этот параметр используется на сервере, параметры --server и --server-bridge будут автоматически толкать выбранную топологию всем клиентам. Однако можно назначить топологию клиентам и вручную. Подобно параметру --dev, этот параметр должен быть совместим между клиентом и сервером. 
mode варианты:
net30 - используется топология point-to-point, выделяя одну подсеть /30 для клиента. Это определено для возможности разработки point-to-point семантики в системах, где некоторые или все подключенные клиенты с Windows системами. Это режим по умолчанию для OpenVPN 2.0.
p2p -- используется топология point-to-point, в которой удаленные клиентские tun интерфейсы узлов всегда соединяются с локальными серверными. Этот режим выделяет один IP address для каждого клиента. Используется только в случаях если нет клиентов с Windows.  Этот режим функционально эквивалентен установке параметру --ifconfig-pool-linear  который доступен в OpenVPN 2.0 и в настоящий момент осуждается. 
subnet -- использование этого значения вместо тополгии point-to-point при конфигурировании интерфейса tun с локальным IP address и маской подсети, подобно использованию --dev tap и режима моста ethernet. Этот режим выделяет единый IP address для каждого подключенного клиента и работает с Windows. Этот режим доступен только если server и клиенты поддерживают OpenVPN 2.1 или высше, или OpenVPN 2.0.x или в котором были вручную исправлены коды реализации директив --topology. Если используется узлы на Windows, требуются драйверы TAP-Win32 версии 8.2 или высше. Если используются  *nix, требуется, чтоб tun driver поддерживал  комманду ifconfig(8) которая устанавливает подсеть всместо адреса удаленного узла.
Этот параметр пристуствует в OpenVPN 2.1 или высше.
--tun-ipv6
Build a tun link capable of forwarding IPv6 traffic. Should be used in conjunction with --dev tun or --dev tunX. A warning will be displayed if no specific IPv6 TUN support for your OS has been compiled into OpenVPN.  See below for further IPv6-related configuration options.
--dev-node node
Явно устанавливает  
Explicitly set the device node rather than using /dev/net/tun, /dev/tun, /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.  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
Определяет link layer address, нужно для задания MAC address. Только для TAP devices.
--iproute cmd
Определяет альтернативную комманду для выполнения, вместо iproute2. Может быть использована для выполнения OpenVPN в непревеливгованных средах. 
--ifconfig l rn
Устанавливает параметры адпатера TUN/TAP. 
l это IP адрес локальной VPN endpoint.
Для TUN устройств, rn это IP address удаленной VPN точки. Для TAP устройств, rn это маска подсети виртуального сегмента ethernet по которому проводится соединение.
Для TUN устройств с виртуальными point-to-point IP соединениями, правильное использование --ifconfig это указание двух адресов IP 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, --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.

--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 network/IP [netmask] [gateway] [metric]
Добавляет маршрут в маршрутную таблицу после установки соединения. Может быть определено несколько маршрутов. Маршруты будут автоматически очищены в обратном порядке закрытия TUN/TAP устройств.
Этот параметр предназначен для удобства proxy для route(8) команды, в то же время обеспечивает кроссплатформенную переносимую семантику для всех OpenVPN's платформ.
netmask default -255.255.255.255
gateway по умолчанию берется с параметра --route-gateway или 2-го параметра --ifconfig где--dev tun определен.
metric по умолчанию берется  --route-metric инчае 0.
Парамтеры network и gateway могут также определять DNS или /etc/hosts файл с именами, или ключевые слова:
     vpn_gateway - удаленный адрес узла VPN (получается из --route-gateway or the second parameter или второго параметра --ifconfig где определен --dev tun is specified).
    net_gateway - наперед существующий IP шлюза по умолчанию, читать с таблицы маршрутов
    remote_host - Адрес --remote если OpenVPN запущен на клиентсокй машине, и не определен на серверной .
--max-routes n
Allow a maximum number of n --route options to be specified, either in the local configuration file, or pulled from an OpenVPN server. By default, n=100.
--route-gateway gw|'dhcp'
Specify a default gateway gw for use with --route.

If dhcp is specified as the parameter, the gateway address will be extracted from a DHCP negotiation with the OpenVPN server-side LAN.

--route-metric m
Specify a default metric m for use with --route.
--route-delay [n] [w]
Delay n seconds (default=0) after connection establishment, before adding routes. If n is 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 (w=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 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 snat|dnat network netmask alias
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.

network/netmask (for example 192.168.0.0/255.255.0.0) defines the local view of a resource from the client perspective, while alias/netmask (for example 10.64.0.0/255.255.0.0) defines the remote view from the server perspective.

Use snat (source NAT) for resources owned by the client and 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:

local -- Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.

autolocal -- Try to automatically determine whether to enable local flag above.

def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

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).

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).

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.

--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.
--tun-mtu n
Take the TUN device MTU to be n and derive the link MTU from it (default=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.

'no' -- Never send DF (Don't Fragment) frames
'maybe' -- Use per-route hints
'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 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.

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. Currently defaults to 65536 bytes.
--rcvbuf size
Set the TCP/UDP socket receive buffer size. Currently defaults to 65536 bytes.
--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 TCP_NODELAY is supported.

The 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. 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 n [bytes]
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.

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.


Comments