Как изменить mtu openvpn

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 ipv6only keyword is present OpenVPN will bind only
to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.

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.

Valid syntax:

fragment max
fragment max mtu

Enable internal datagram fragmentation so that no UDP datagrams are sent
which are larger than max bytes.

If the mtu parameter is present the max parameter is
interpreted to include IP and UDP encapsulation overhead. The
mtu parameter is introduced in OpenVPN version 2.6.0.

If the mtu parameter is absent, 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.

A helper directive designed to simplify the expression of --ping and
--ping-restart.

Valid syntax:

keepalive interval timeout

Send ping once every interval seconds, restart if ping is not received
for timeout seconds.

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

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

Due to variable header size of IP header (20 bytes for IPv4 and 40 bytes
for IPv6) and dynamically negotiated data channel cipher, this option
is not reliable. It is recommended to set tun-mtu with enough headroom
instead.

Valid syntax:

mssfix max [mtu]

mssfix max [fixed]

mssfix

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 1492 mtu. Use 0
as max to disable mssfix.

If the mtu parameter is specified the max value is interpreted
as the resulting packet size of VPN packets including the IP and UDP header.
Support for the mtu parameter was added with OpenVPN version 2.6.0.

If the mtu parameter is not specified, 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 OpenVPN packets to be
transmitted over IPv4 on a link with MTU 1478 or higher without IP level
fragmentation (and 1498 for IPv6).

If the fixed parameter is specified, OpenVPN will make no attempt
to calculate the VPN encapsulation overhead but instead will set the MSS to
limit the size of the payload IP packets to the specified number. IPv4 packets
will have the MSS value lowered to mssfix — 40 and IPv6 packets to mssfix — 60.

if --mssfix is specified is specified without any parameter it
inherits the parameters of --fragment if specified or uses the
default for --mssfix otherwise.

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.

--max-packet-size, --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

If the max-packet-size size option is used in the configuration
it will also act as if mssfix size mtu was specified in the
configuration.

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:

no Never send DF (Don’t Fragment) frames

maybe Use per-route hints

yes Always DF (Don’t Fragment)

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.

When using OpenVPN in server mode see also --keepalive.

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.

Similar to --ping-exit, but trigger a 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 https://www.nsupdate.info/ + 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 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.

Use protocol p for communicating with remote host. p can be
udp, tcp-client, or tcp-server. You can also
limit OpenVPN to use only IPv4 or only IPv6 by specifying p as
udp4, tcp4-client, tcp4-server or udp6,
tcp6-client, tcp6-server, respectively.

The default protocol is 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
tcp-server will wait indefinitely for an incoming connection. A peer
started with 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.

Modify the replay protection sliding-window size and time window.

Valid syntaxes:

replay-window n
replay-window n t

Use a replay protection sliding-window of size n and a time window
of t seconds.

By default n is 64 (the IPSec default) and t is
15 seconds.

This option is only relevant in UDP mode, i.e. when either --proto
udp is specified, or no --proto option is specified.

When OpenVPN tunnels IP packets over UDP, there is the possibility that
packets might be dropped or delivered out of order. Because OpenVPN,
like IPSec, is emulating the physical network layer, it will accept an
out-of-order packet sequence, and will deliver such packets in the same
order they were received to the TCP/IP protocol stack, provided they
satisfy several constraints.

1. The packet cannot be a replay (unless --no-replay is
   specified, which disables replay protection altogether).
2. If a packet arrives out of order, it will only be accepted if
   the difference between its sequence number and the highest sequence
   number received so far is less than n.
3. If a packet arrives out of order, it will only be accepted if it
   arrives no later than t seconds after any packet containing a higher
   sequence number.

If you are using a network link with a large pipeline (meaning that the
product of bandwidth and latency is high), you may want to use a larger
value for n. Satellite links in particular often require this.

If you run OpenVPN at --verb 4, you will see the message
«PID_ERR replay-window backtrack occurred [x]» every time the maximum sequence
number backtrack seen thus far increases. This can be used to calibrate
n.

There is some controversy on the appropriate method of handling packet
reordering at the security layer.

Namely, to what extent should the security layer protect the
encapsulated protocol from attacks which masquerade as the kinds of
normal packet loss and reordering that occur over IP networks?

The IPSec and OpenVPN approach is to allow packet reordering within a
certain fixed sequence number window.

OpenVPN adds to the IPSec model by limiting the window size in time as
well as sequence space.

OpenVPN also adds TCP transport as an option (not offered by IPSec) in
which case OpenVPN can adopt a very strict attitude towards message
deletion and reordering: Don’t allow it. Since TCP guarantees
reliability, any packet loss or reordering event can be assumed to be an
attack.

In this sense, it could be argued that TCP tunnel transport is preferred
when tunneling non-IP or UDP application protocols which might be
vulnerable to a message deletion or reordering attack which falls within
the normal operational parameters of IP networks.

So I would make the statement that one should never tunnel a non-IP
protocol or UDP application protocol over UDP, if the protocol might be
vulnerable to a message deletion or reordering attack that falls within
the normal operating parameters of what is to be expected from the
physical IP layer. The problem is easily fixed by simply using TCP as
the VPN transport layer.

Persist replay-protection state across sessions using file to save
and reload the state.

This option will keep a disk copy of the current replay protection state
(i.e. the most recent packet timestamp and sequence number received from
the remote peer), so that if an OpenVPN session is stopped and
restarted, it will reject any replays of packets which were already
received by the prior session.

This option only makes sense when replay protection is enabled (the
default) and you are using either --secret (shared-secret key mode)
or TLS mode with --tls-auth.

Raises SIGTERM for the client instance after n seconds since
the beginning of the session, forcing OpenVPN to disconnect.
In client mode, OpenVPN will disconnect and exit, while in server mode
all client sessions are terminated.

This option can also be specified in a client instance config file
using --client-config-dir or dynamically generated using a
--client-connect script. In these cases, only the related client
session is terminated.

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.

This macro sets the TCP_NODELAY socket flag on the server as well
as pushes it to connecting clients. The TCP_NODELAY flag disables
the Nagle algorithm on TCP sockets causing packets to be transmitted
immediately with low latency, rather than waiting a short period of time
in order to aggregate several packets into a larger containing packet.
In VPN applications over TCP, TCP_NODELAY is generally a good
latency optimization.

The macro expands as follows:

if mode server:
    socket-flags TCP_NODELAY
    push "socket-flags TCP_NODELAY"

This option will instruct OpenVPN to try to limit the maximum on-write packet
size by restricting the control channel packet size and setting --mssfix.

OpenVPN will try to keep its control channel messages below this size but
due to some constraints in the protocol this is not always possible. If the
option is not set, the control packet maximum size defaults to 1250.
The control channel packet size will be restricted to values between
154 and 2048. The maximum packet size includes encapsulation overhead like
UDP and IP.

In terms of --mssfix it will expand to:

mssfix size mtu

If you need to set --mssfix for data channel and control channel maximum
packet size independently, use --max-packet-size first, followed by a
--mssfix in the configuration.

In general the default size of 1250 should work almost universally apart
from specific corner cases, especially since IPv6 requires a MTU of 1280
or larger.