代码拉取完成，页面将自动刷新
mlock will now check if enough memlock-able memory has been reserved,The --peer-fingerprint option has been introduced to give users an
easy to use alternative to the tls-verify for matching the
fingerprint of the peer. The option takes use a number of allowed
SHA256 certificate fingerprints.
See the man page section "Small OpenVPN setup with peer-fingerprint" for a tutorial on how to use this feature. This is also available online under https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst
--peer-fingerprint is used, the --ca and --capath option
become optional. This allows for small OpenVPN setups without setting up
a PKI with Easy-RSA or similar software.--auth-user-pass-verify script supports now deferred authentication.Both auth plugin and script can now signal pending authentication to
the client when using deferred authentication. The new client-crresponse
script option and OPENVPN_PLUGIN_CLIENT_CRRESPONSE plugin function can
be used to parse a client response to a CR_TEXT two factor challenge.
See sample/sample-scripts/totpauth.py for an example.
--compat-mode)--compat-mode allows UIs to provide users
with an easy way to still connect to older servers.--tls-cert-profile insecure
has been added to allow selecting the lowest OpenSSL security level (not
recommended, use only if you must). OpenSSL 3.0 no longer supports the Blowfish
(and other deprecated) algorithm by default and the new option --providers
allows loading the legacy provider to renable these algorithms.--data-ciphers
--data-ciphers can now be prefixed with a ? to mark
those as optional and only use them if the SSL library supports them.inetd has been removedverify-hash has been deprecated--ca configuration or with a --tls-verify script.secret has been deprecated--peer-fingerprint makes
TLS mode about as easy as using --secret.ncp-disable has been removedtls-version-min is set to 1.2 by default. OpenVPN 2.6.0 defaults
to a minimum TLS version of 1.2 as TLS 1.0 and 1.1 should be generally
avoided. Note that OpenVPN versions older than 2.3.7 use TLS 1.0 only.--cipher argument is no longer appended to --data-ciphers
--cipher has been removed.
Effectively, --cipher is a no-op in TLS mode now, and will
only have an effect in pre-shared-key mode (--secret).
From now on --cipher should not be used in new configurations
for TLS mode.
Should backwards compatibility with older OpenVPN peers be
required, please see the --compat-mode instead.--prng has beeen removed--allow-compression defaults to no in OpeNVPN 2.6.0.
By default, OpenVPN 2.5 still allowed a server to enable compression by
pushing compression related options.--management-client-pf and any other compile
time or run time related option do not exist any longer.--data-ciphers when available.--prng is ignored as we rely on the SSL library random number generator.--nobind is default when --client or --pull is used in the configuration--tls-crypt-v2)tls-crypt-v2 adds the ability to supply each client with a unique
tls-crypt key. This allows large organisations and VPN providers to profit
from the same DoS and TLS stack protection that small deployments can
already achieve using tls-auth or tls-crypt.The option ncp-ciphers has been renamed to data-ciphers.
The old name is still accepted. The change in name signals that
data-ciphers is the preferred way to configure data channel
ciphers and the data prefix is chosen to avoid the ambiguity that
exists with --cipher for the data cipher and tls-cipher
for the TLS ciphers.
OpenVPN clients will now signal all supported ciphers from the
data-ciphers option to the server via IV_CIPHERS. OpenVPN
servers will select the first common cipher from the data-ciphers
list instead of blindly pushing the first cipher of the list. This
allows to use a configuration like
data-ciphers ChaCha20-Poly1305:AES-256-GCM on the server that
prefers ChaCha20-Poly1305 but uses it only if the client supports it.
See the data channel negotiation section in the manual for more details.
By default OpenVPN 2.5 will only accept AES-256-GCM and AES-128-GCM as data ciphers. OpenVPN 2.4 allows AES-256-GCM,AES-128-GCM and BF-CBC when no --cipher and --ncp-ciphers options are present. Accepting BF-CBC can be enabled by adding
data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC
and when you need to support very old peers also
data-ciphers-fallback BF-CBC
To offer backwards compatibility with older configs an explicit
cipher BF-CBC
in the configuration will be automatically translated into adding BF-CBC to the data-ciphers option and setting data-ciphers-fallback to BF-CBC (as in the example commands above). We strongly recommend to switching away from BF-CBC to a more secure cipher.
--client-connect option and the connect plugin API allow
asynchronous/deferred return of the configuration file in the same way
as the auth-plugin.IV_PROTO variable that it is in pull
mode. This allows the server to push the configuration options to
the client without waiting for a PULL_REQUEST message. The feature
is automatically enabled if both client and server support it and
significantly reduces the connection setup time by avoiding one
extra packet round-trip and 1s of internal event delays.On Linux, if configured without --enable-iproute2, configuring IP
addresses and adding/removing routes is now done via the netlink(3)
kernel interface. This is much faster than calling ifconfig or
route and also enables OpenVPN to run with less privileges.
If configured with --enable-iproute2, the ip command is used
(as in 2.4). Support for ifconfig and route is gone.
wintun devices. They are faster
than the traditional tap9 tun/tap devices, but do not provide
--dev tap mode - so the official installers contain both. To use
a wintun device, add --windows-driver wintun to your config
(and use of the interactive service is required as wintun needs
SYSTEM privileges to enable access).--bind-dev option, the OpenVPN outside socket can
now be put into a Linux VRF. See the "Virtual Routing and Forwarding"
documentation in the man page.--tls-ciphersuites and --tls-groups have been
added to fine tune TLS protocol options. Most of the improvements
were also backported to OpenVPN 2.4 as part of the maintainance
releases.--dhcp-option DOMAIN-SEARCH my.example.com has been
defined, and Windows support for it is implemented (tun/tap only, no
wintun support yet). Other platforms need to support this via --up
script (Linux) or GUI (OSX/Tunnelblick).--data-ciphers or data-ciphers-fallback
Add support for OpenSSL engines to access private key material (like TPM).
--auth-gen-token support has been improved and now generates HMAC
based user token. If the optional --auth-gen-token-secret option is
used clients will be able to seamlessly reconnect to a different server
using the same secret file or to the same server after a server restart.The protocol has been enhanced to be able to signal that the authentication should use a secondary authentication via web (like SAML) or a two factor authentication without disconnecting the OpenVPN session with AUTH_FAILED. The session will instead be stay in a authenticated state and wait for the second factor authentication to complete.
This feature currently requires usage of the managent interface
on both client and server side. See the management-notes.txt
client-pending-auth and cr-response commands for more
details.
OpenVPN servers in TAP mode can now use 802.1q tagged VLANs
on the TAP interface to separate clients into different groups
that can then be handled differently (different subnets / DHCP,
firewall zones, ...) further down the network. See the new
options --vlan-tagging, --vlan-accept, --vlan-pvid.
802.1q tagging on the client side TAP interface is not handled today (= tags are just forwarded transparently to the server).
Support building of .msi installers for Windows
Allow unicode search string in --cryptoapicert option (Windows)
--block-ipv6 to reject all IPv6 packets (ICMPv6)--ifconfig-ipv6 and --ifconfig-ipv6-push will now acceptFor an up-to-date list of all deprecated options, see this wiki page: https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
ncp-disable has been deprecatedncp-disable should not be necessary anymore.inetd has been deprecated
This is a very limited and not-well-tested way to run OpenVPN, on TCP
and TAP mode only, which complicates the code quite a bit for little gain.
To be removed in OpenVPN 2.6 (unless users protest).no-iv has been removed
This option was made into a NOOP option with OpenVPN 2.4. This has now
been completely removed.--client-cert-not-required has been removed
This option will now cause server configurations to not start. Use
--verify-client-cert none instead.--ifconfig-pool-linear has been removed
This option is removed. Use --topology p2p or --topology subnet
instead.--compress xxx is considered risky and is warned against, see below.--key-method 1 has been removed--compress is nowadays considered risky, because attacks exist
leveraging compression-inside-crypto to reveal plaintext (VORACLE). So
by default, --compress xxx will now accept incoming compressed
packets (for compatibility with peers that have not been upgraded yet),
but will not use compression outgoing packets. This can be controlled with
the new option --allow-compression yes|no|asym.--txlen aways from OS defaults unless explicitly specified
in config file. OS defaults nowadays are actually larger then what we used
to configure, so our defaults sometimes caused packet drops = bad performance.--writepid pid file on exit now--machine-readable-output)--clr-verify now loads all CRLs if more than one CRL is in the same
file (OpenSSL backend only, mbedTLS always did that)--auth-user-pass file has no password, and the management interface
is active, query management interface (instead of trying console query,
which does not work on windows)--cryptoapicert)--socks-proxy + --proto udp* will now allways use IPv4, even if
IPv6 is requested and available. Our SOCKS code does not handle IPv6+UDP,
and before that change it would just fail in non-obvious ways.key-method,
keydir, tls-auth and cipher - these are either gone now, or
negotiated, and the warnings do not serve a useful purpose.dhcp-option DNS and dhcp-option DNS6 are now treated identically
(= both accept an IPv4 or IPv6 address for the nameserver)make distcheck it is). Release tarballs
contain the openvpn.8 file, so unless some .rst is changed, doc-utils are
not needed for building.--disable-server has been removed from configure (so it is no longer
possible to build a client-/p2p-only OpenVPN binary) - the saving in code
size no longer outweighs the extra maintenance effort.--enable-iproute2 will disable netlink(3) support, so maybe remove
that from package building configs (see above)--disable-crypto configure option has been removed. OpenVPN is now always
built with crypto support, which makes the code much easier to maintain.
This does not affect --cipher none to do a tunnel without encryption.--disable-multi configure option has been removedData channel ciphers (--cipher) are now by default negotiated. If a
client advertises support for Negotiable Crypto Parameters (NCP), the
server will choose a cipher (by default AES-256-GCM) for the data channel,
and tell the client to use that cipher. Data channel cipher negotiation
can be controlled using --ncp-ciphers and --ncp-disable.
A more limited version also works in client-to-server and server-to-client
scenarios where one of the end points uses a v2.4 client or server and the
other side uses an older version. In such scenarios the v2.4 side will
change to the --cipher set by the remote side, if permitted by by
--ncp-ciphers. For example, a v2.4 client with --cipher BF-CBC
and ncp-ciphers AES-256-GCM:AES-256-CBC can connect to both a v2.3
server with cipher BF-CBC as well as a server with
cipher AES-256-CBC in its config. The other way around, a v2.3 client
with either cipher BF-CBC or cipher AES-256-CBC can connect to a
v2.4 server with e.g. cipher BF-CBC and
ncp-ciphers AES-256-GCM:AES-256-CBC in its config. For this to work
it requires that OpenVPN was built without disabling OCC support.
--remote OpenVPN
will now try all addresses (IPv6 and IPv4) of a --remote entry.A new DHCP sub-option DNS6 is added alongside with the already existing
DNS sub-option. This is used to provide DNS resolvers available over
IPv6. This may be pushed to clients where `` --up`` scripts and --plugin
can act upon it through the foreign_option_<n> environment variables.
Support for the Windows client picking up this new sub-option is added,
however IPv6 DNS resolvers need to be configured via netsh which requires
administrator privileges unless the new interactive services on Windows is
being used. If the interactive service is used, this service will execute
netsh in the background with the proper privileges.
The installer starts OpenVPNServiceInteractive automatically and configures it to start at system startup.
The interactive Windows service allows unprivileged users to start OpenVPN connections in the global config directory (usually C:\Program Files\OpenVPN\config) using OpenVPN GUI without any extra configuration.
Users who belong to the built-in Administrator group or to the local "OpenVPN Administrator" group can also store configuration files under %USERPROFILE%\OpenVPN\config for use with the interactive service.
--push-reset).<http-proxy-user-pass> .. </http-proxy-user-pass>
--push-peer-info is set on client).--tls-crypt)--tls-auth key) to encrypt control
channel packets. Provides more privacy, some obfuscation and poor-man's
post-quantum security../configure --enable-async-push. This is a compile-time only switch.For an up-to-date list of all deprecated options, see this wiki page: https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
--key-method 1 is deprecated in OpenVPN 2.4 and will be removed in v2.5.
Migrate away from --key-method 1 as soon as possible. The recommended
approach is to remove the --key-method option from the configuration
files, OpenVPN will then use --key-method 2 by default. Note that this
requires changing the option in both the client and server side configs.--tls-remote is removed in OpenVPN 2.4, as indicated in the v2.3
man-pages. Similar functionality is provided via --verify-x509-name,
which does the same job in a better way.--compat-names and --no-name-remapping were deprecated in OpenVPN 2.3
and will be removed in v2.5. All scripts and plug-ins depending on the old
non-standard X.509 subject formatting must be updated to the standardized
formatting. See the man page for more information.--no-iv is deprecated in OpenVPN 2.4 and will be removed in v2.5.--keysize is deprecated in OpenVPN 2.4 and will be removed in v2.6
together with the support of ciphers with cipher block size less than
128-bits.--comp-lzo is deprecated in OpenVPN 2.4. Use --compress instead.--ifconfig-pool-linear has been deprecated since OpenVPN 2.1 and will be
removed in v2.5. Use --topology p2p instead.--client-cert-not-required is deprecated in OpenVPN 2.4 and will be removed
in v2.5. Use --verify-client-cert none for a functional equivalent.--ns-cert-type is deprecated in OpenVPN 2.3.18 and v2.4. It will be removed
in v2.5. Use the far better --remote-cert-tls option which replaces this
feature.When using ciphers with cipher blocks less than 128-bits,
OpenVPN will complain loudly if the configuration uses ciphers considered
weak, such as the SWEET32 attack vector. In such scenarios, OpenVPN will by
default renegotiate for each 64MB of transported data (--reneg-bytes).
This renegotiation can be disabled, but is HIGHLY DISCOURAGED.
For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both fields are now exported to the environment, where each second and later occurrence of a field get _$N appended to it's field name, starting at N=1. For the example above, that would result in e.g. X509_0_OU=one, X509_0_OU_1=two. Note that this breaks setups that rely on the fact that OpenVPN would previously (incorrectly) only export the last occurrence of a field.
proto udp and proto tcp now use both IPv4 and IPv6. The new
options proto udp4 and proto tcp4 use IPv4 only.
--sndbuf and --recvbuf default now to OS defaults instead of 64k
OpenVPN exits with an error if an option has extra parameters; previously they were silently ignored
--tls-auth always requires OpenVPN static key files and will no
longer work with free form files
--proto udp6/tcp6 in server mode will now try to always listen to
both IPv4 and IPv6 on platforms that allow it. Use --bind ipv6only
to explicitly listen only on IPv6.
Removed --enable-password-save from configure. This option is now
always enabled.
Stricter default TLS cipher list (override with --tls-cipher), that now
also disables:
mbed TLS builds: changed the tls_digest_N values exported to the script environment to be equal to the ones exported by OpenSSL builds, namely the certificate fingerprint (was the hash of the 'to be signed' data).
mbed TLS builds: minimum RSA key size is now 2048 bits. Shorter keys will not be accepted, both local and from the peer.
--connect-timeout now specifies the timeout until the first TLS packet
is received (identical to --server-poll-timeout) and this timeout now
includes the removed socks proxy timeout and http proxy timeout.
In --static mode connect-timeout specifies the timeout for TCP and
proxy connection establishment
--connect-retry-max now specifies the maximum number of unsuccessful
attempts of each remote/connection entry before exiting.
--http-proxy-timeout and the static non-changeable socks timeout (5s)
have been folded into a "unified" --connect-timeout which covers all
steps needed to connect to the server, up to the start of the TLS exchange.
The default value has been raised to 120s, to handle slow http/socks
proxies graciously. The old "fail TCP fast" behaviour can be achieved by
adding "--connect-timeout 10" to the client config.
--http-proxy-retry and --sock-proxy-retry have been removed. Proxy connections
will now behave like regular connection entries and generate a USR1 on failure.
--connect-retry gets an optional second argument that specifies the maximum
time in seconds to wait between reconnection attempts when an exponential
backoff is triggered due to repeated retries. Default = 300 seconds.
Data channel cipher negotiation (see New features section) can override
ciphers configured in the config file. Use --ncp-disable if you do not want
this behavior.
All tun devices on all platforms are always considered to be IPv6
capable. The --tun-ipv6 option is ignored (behaves like it is always
on).
On the client side recursively routed packets, which have the same destination as the VPN server, are dropped. This can be disabled with --allow-recursive-routing option.
On Windows, when the --register-dns option is set, OpenVPN no longer
restarts the dnscache service - this had unwanted side effects, and
seems to be no longer necessary with currently supported Windows versions.
If no flags are given, and the interactive Windows service is used, "def1" is implicitly set (because "delete and later reinstall the existing default route" does not work well here). If not using the service, the old behaviour is kept.
OpenVPN now reloads a CRL only if the modication time or file size has changed, instead of for each new connection. This reduces the connection setup time, in particular when using large CRLs.
OpenVPN now ships with more up-to-date systemd unit files which take advantage of the improved service management as well as some hardening steps. The configuration files are picked up from the /etc/openvpn/server/ and /etc/openvpn/client/ directories (depending on unit file). This also avoids these new unit files and how they work to collide with older pre-existing unit files.
Using --no-iv (which is generally not a recommended setup) will
require explicitly disabling NCP with --disable-ncp. This is
intentional because NCP will by default use AES-GCM, which requires
an IV - so we want users of that option to consciously reconsider.
--tls-cert-profile can be used to restrict the set of
allowed crypto algorithms in TLS certificates in mbed TLS builds. The
default profile is 'legacy' for now, which allows SHA1+, RSA-1024+ and any
elliptic curve certificates. The default will be changed to the 'preferred'
profile in the future, which requires SHA2+, RSA-2048+ and any curve.--x509-track post-authentication remote DoS
A client could crash a v2.4+ mbedtls server, if that server uses the
--x509-track option and the client has a correct, signed and unrevoked
certificate that contains an embedded NUL in the certificate subject.
Discovered and reported to the OpenVPN security team by Guido Vranken.--x509-username-field option with an X.509
extension field (option argument prefixed with ext:). A client that can
cause a server to run out-of-memory (see above) might be able to cause the
server to double free, which in turn might lead to remote code execution.
Discovered and reported to the OpenVPN security team by Guido Vranken.
(OpenSSL builds only.)--http-proxy <server> <port> [<authfile>|'auto'|'auto-nct'] ntlm2),
a man-in-the-middle attacker between the client and the proxy can cause
the client to crash or disclose at most 96 bytes of stack memory. The
disclosed stack memory is likely to contain the proxy password. If the
proxy password is not reused, this is unlikely to compromise the security
of the OpenVPN tunnel itself. Clients who do not use the --http-proxy
option with ntlm2 authentication are not affected.--mssfix are enabled and the IPv6 networks used inside the VPN
are known.Proxy-Authenticate: headers for digest auth.--tls-cipher optionGetModuleFileNameW()
(OSTIF/Quarkslabs audit, finding 5.6)--verify-hash can now take an optional flag which changes the hashing
algorithm. It can be either SHA1 or SHA256. The default if not provided is
SHA1 to preserve backwards compatibility with existing configurations.--x509-username-field extension fields to subjectAltName
and issuerAltName. Other extensions probably didn't work anyway, and would
cause OpenVPN to crash when a client connects.tls_digest_* env vars, or that use --verify-hash will have to change
the fingerprint values they check against. The security impact of the
incorrect calculation is very minimal; the last few bytes (max 4, typically
4) are not verified by the fingerprint. We expect no real-world impact,
because users that used this feature before will notice that it has suddenly
stopped working, and users that didn't will notice that connection setup
fails if they specify correct fingerprints.--plugin
--remote-cert-tls is
used, we leaked some memory on each TLS (re)negotiation.--tls-auth or
--tls-crypt is used, only attackers that have the --tls-auth or
--tls-crypt key can mount an attack.
(OSTIF/Quarkslab audit finding 5.1, CVE-2017-7478)--remote-cert-ku now only requires the certificate to have at least the
bits set of one of the values in the supplied list, instead of requiring an
exact match to one of the values in the list.--remote-cert-tls now only requires that a keyUsage is present in the
certificate, and leaves the verification of the value up to the crypto
library, which has more information (i.e. the key exchange method in use)
to verify that the keyUsage is correct.--ns-cert-type is deprecated. Use --remote-cert-tls instead.
The nsCertType x509 extension is very old, and barely used.
--remote-cert-tls uses the far more common keyUsage and extendedKeyUsage
extension instead. Make sure your certificates carry these to be able to
use --remote-cert-tls.此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。