openvpn.8

一个开源的VPN原码

The typical usage of
.B --test-crypto
would be something like this:

.B openvpn --test-crypto --secret key

or

.B openvpn --test-crypto --secret key --verb 8

This option is very useful to test OpenVPN after it has been ported to
a new platform, or to isolate problems in the compiler, OpenSSL
crypto library, or OpenVPN's crypto code.  Since it is a self-test mode,
problems with encryption and authentication can be debugged independently
of network and tunnel issues.
.SS TLS Mode Options:
TLS mode is the most powerful mode of OpenVPN in both security and flexibility.
TLS mode works by establishing control and
data channels which are multiplexed over a single UDP port.  OpenVPN initiates
a TLS session over the control channel and uses it to exchange cipher
and HMAC keys to protect the data channel.  TLS mode uses a robust reliability
layer over the UDP connection for all control channel communication, while
the data channel, over which encrypted tunnel data passes, is forwarded without
any mediation.  The result is the best of both worlds: a fast data channel
that forwards over UDP with only the overhead of encrypt,
decrypt, and HMAC functions,
and a control channel that provides all of the security features of TLS,
including certificate-based authentication and perfect forward security.

To use TLS mode, each peer that runs OpenVPN should have its own local
certificate/key pair (
.B --cert
and
.B --key
), signed by the root certificate which is specified
in
.B --ca.

When two OpenVPN peers connect, each presents its local certificate to the
other.  Each peer will then check that its partner peer presented a
certificate which was signed by the master root certificate as specified in
.B --ca.

If that check on both peers succeeds, then the TLS negotiation will succeed, both OpenVPN
peers will exchange temporary session keys, and the tunnel will begin
passing data.

The OpenVPN distribution contains a set of scripts for managing RSA certificates & keys,
located in the
.I easy-rsa
subdirectory.

The easy-rsa package is also rendered in web form here:
.I http://openvpn.sourceforge.net/easyrsa.html
.TP
.B --tls-server
Enable TLS and assume server role during TLS handshake.  Note that
OpenVPN is designed as a peer-to-peer application.  The designation
of client or server is only for the purpose of negotiating the TLS
control channel.
.TP
.B --tls-client
Enable TLS and assume client role during TLS handshake.
.TP
.B --ca file
Certificate authority (CA) file in .pem format, also referred to as the
.I root
certificate.  This file can have multiple
certificates in .pem format, concatenated together.  You can construct your own
certificate authority certificate and private key by using a command such as:

.B openssl req -nodes -new -x509 -keyout tmp-ca.key -out tmp-ca.crt

Then edit your openssl.cnf file and edit the
.B certificate
variable to point to your new root certificate
.B tmp-ca.crt.

For testing purposes only, the OpenVPN distribution includes a sample
CA certificate (tmp-ca.crt).
Of course you should never use
the test certificates and test keys distributed with OpenVPN in a
production environment, since by virtue of the fact that
they are distributed with OpenVPN, they are totally insecure.
.TP
.B --dh file
File containing Diffie Hellman parameters
in .pem format (required for
.B --tls-server
only). Use

.B openssl dhparam -out dh1024.pem 1024

to generate your own, or use the existing dh1024.pem file
included with the OpenVPN distribution.  Diffie Hellman parameters
may be considered public.
.TP
.B --cert file
Local peer's signed certificate in .pem format -- must be signed
by a certificate authority whose certificate is in
.B --ca file.
Each peer in an OpenVPN link running in TLS mode should have its own
certificate and private key file.  In addition, each certificate should
have been signed by the key of a certificate
authority whose public key resides in the
.B --ca
certificate authority file.
You can easily make your own certificate authority (see above) or pay money
to use a commercial service such as thawte.com (in which case you will be
helping to finance the world's second space tourist :).
To generate a certificate,
you can use a command such as:

.B openssl req -nodes -new -keyout mycert.key -out mycert.csr

If your certificate authority private key lives on another machine, copy
the certificate signing request (mycert.csr) to this other machine (this can
be done over an insecure channel such as email).  Now sign the certificate
with a command such as:

.B openssl ca -out mycert.crt -in mycert.csr

Now copy the certificate (mycert.crt)
back to the peer which initially generated the .csr file (this
can be over a public medium).
Note that the
.B openssl ca
command reads the location of the certificate authority key from its
configuration file such as
.B /usr/share/ssl/openssl.cnf
-- note also
that for certificate authority functions, you must set up the files
.B index.txt
(may be empty) and
.B serial
(initialize to
.B 
01
).
.TP
.B --key file
Local peer's private key in .pem format.  Use the private key which was generated
when you built your peer's certificate (see
.B -cert file
above).
.TP
.B --tls-cipher l
A list l of allowable TLS ciphers separated by
.B |
(optional).  If you require a high level of security,
you may want to set this parameter manually, to prevent a
version rollback attack where a man-in-the-middle attacker tries
to force two peers to negotiate to the lowest level
of security they both support.
Use
.B --show-tls
to see a list of supported TLS ciphers.
.TP
.B --tls-timeout n
Packet retransmit timeout on TLS control channel
if no acknowledgment from remote within
.B n
seconds (default=5).  When OpenVPN sends a control
packet to its peer, it will expect to receive an
acknowledgement within
.B n
seconds or it will retransmit the packet.  This parameter
only applies to control channel packets.  Data channel
packets (which carry encrypted tunnel data) are never
acknowledged, sequenced, or retransmitted by OpenVPN because
the higher level network protocols running on top of the tunnel
such as TCP expect this role to be left to them.
.TP
.B --reneg-bytes n
Renegotiate data channel key after
.B n
bytes sent or received (disabled by default).
OpenVPN allows the lifetime of a key
to expressed as a number of bytes encrypted/decrypted, a number of packets, or
a number of seconds.  A key renegotiation will be forced
if any of these three criteria are met by either peer.
.TP
.B --reneg-pkts n
Renegotiate data channel key after
.B n
packets sent and received (disabled by default).
.TP
.B --reneg-sec n
Renegotiate data channel key after
.B n
seconds (default=3600).
.TP
.B --hand-window n
Handshake Window -- the TLS-based key exchange must finalize within
.B n
seconds
of handshake initiation by any peer (default = 60 seconds).
If the handshake fails
we will attempt to reset our connection with our peer and try again.
Even in the event of handshake failure we will still use
our expiring key for up to
.B --tran-window
seconds to maintain continuity of transmission of tunnel
data.
.TP
.B --tran-window n
Transition window -- our old key can live this many seconds
after new a key renegotiation begins (default = 3600 seconds).
This is a powerful feature that contributes to the robustness
of the OpenVPN key negotiation protocol.  Even during periods
of extremely poor network connectivity between peers, with
significant dropped packets, OpenVPN
will never let the failure of a key exchange handshake interfere with
the continuing transmission of tunnel data.
.TP
.B --single-session
After initially connecting to a remote peer, disallow any new connections.
Using this
option means that a remote peer cannot connect, disconnect, and then
reconnect.

If the daemon is reset by a signal or
.B --ping-restart,
it will allow one new connection.

.B --single-session
can be used with
.B --ping-exit
or
.B --inactive
to create a single dynamic session that will exit when finished.
.TP
.B --tls-auth f
Add an additional layer of authentication on top of the TLS
control channel to protect against DoS attacks.
.B f
(required) is a shared-secret passphrase file.

.B --tls-auth
is recommended when you are running OpenVPN in a mode where
it is listening for packets from any IP address such as when
.B --remote
is not specified, or
.B --remote
is specified with
.B --float.

The rationale for
this feature is as follows.  TLS requires a multi-packet exchange
before it is able to authenticate a peer.  During this time
before authentication, OpenVPN is allocating resources (memory
and CPU) to this potential peer.  The potential peer is also
exposing many parts of OpenVPN and the OpenSSL library to the packets
it is sending.  Most successful network attacks today seek
to either exploit bugs in programs (such as buffer overflow attacks) or
force a program to consume so many resources that it becomes unusable.
Of course the first line of defense is always to produce clean,
well-audited code.  OpenVPN has been written with buffer overflow
attack prevention as a top priority.
But as history has shown, many of the most widely used
network applications have, from time to time,
fallen to buffer overflow attacks.

So as a second line of defense, OpenVPN offers
this special layer of authentication on top of the TLS control channel so that
every packet on the control channel is authenticated by an
HMAC signature and a unique ID for replay protection.
This signature will also help protect against DoS (Denial of Service) attacks.
An important rule of thumb in reducing vulnerability to DoS attacks is to
minimize the amount of resources a potential, but as yet unauthenticated,
client is able to consume.

.B --tls-auth
does this by signing every TLS control channel packet with an HMAC signature,
including packets which are sent before the TLS level has had a chance
to authenticate the peer.
The result is that packets without
the correct signature can be dropped immediately upon reception,
before they have a chance to consume additional system resources
such as by initiating a TLS handshake.

It should be emphasized that this feature is optional and that the
passphrase file used with
.B --tls-auth
gives a peer nothing more than the power to initiate a TLS
handshake.  It is not used to encrypt or authenticate any tunnel data.
.TP
.B --askpass
Get PEM password from controlling tty before we daemonize.  For the extremely
security conscious, it is possible to protect your private key with
a password.  Of course this means that every time the OpenVPN
daemon is started you must be there to type the password.  The
.B --askpass
option allows you to start OpenVPN from the command line.  It will
query you for a password before it daemonizes.  To protect a private
key with a password you should omit the
.B -nodes
option when you use the
.B openssl
command line tool to manage certificates and private keys.
.TP
.B --tls-verify cmd
Execute shell command
.B cmd
to verify the X509 name of a
pending TLS connection that has otherwise passed all other
tests of certification.
.B cmd
should return 0 to allow the TLS handshake to proceed, or 1 to fail.
.B cmd
is executed as

.B cmd certificate_depth X509_NAME_oneline

Commas (',') may be used to separate multiple args in
.B cmd.

Before the command line is passed to the shell, all commas
will be converted to spaces.

This feature is useful if the peer you want to trust has a certificate
which was signed by a certificate authority who also signed a zillion
other certificates.  In this case you want to be selective about which
peer certificate you accept.  This feature allows you to write a script
which will test the X509 name on a certificate and decide whether or
not it should be accepted.  For a simple perl script which will test
the common name field on the certificate, see the file
.B verify-cn
in the OpenVPN distribution.
.TP
.B --disable-occ
Disable options compatibility check between peers.  This is designed
to circumvent OpenVPN's normal options compatibility check in
TLS mode.  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.
.SS SSL Library information:
.TP
.B --show-ciphers
Show all cipher algorithms to use with the
.B --cipher
option.
.TP
.B --show-digests
Show all message digest algorithms to use with the
.B --auth
option.
.TP
.B --show-tls
Show all TLS ciphers (TLS used only as a control channel).  The TLS
ciphers will be sorted from highest preference (most secure) to
lowest.
.SS Generate a random key:
Used only for non-TLS static key encryption mode.
.TP
.B --genkey
Generate a random key to be used as a shared secret,
for use with the
.B --secret
option.  This file must be shared with the
peer over a pre-existing secure channel such as
.BR scp (1)
.
.TP
.B --secret file
Write key to
.B file.
.SS TUN/TAP persistent tunnel config mode:
Available with linux 2.4.7+.  These options comprise a standalone mode
of OpenVPN which can be used to create and delete persistent tunnels.
.TP
.B --mktun
Create a persistent tunnel.  Normally tun/tap tunnels exist only for
the period of time that an application has them open.  This option
takes advantage of the tun/tap driver's ability to build persistent
tunnels that live through multiple instantiations of OpenVPN and die
only when they are deleted or the machine is rebooted.

One of the advantages of persistent tunnels is that they eliminate the
need for separate
.B --up
and
.B --down
scripts to run the appropriate
.BR ifconfig (8)
and
.BR route (8)
commands.  These commands can be placed in the the same shell script
which starts or terminates an OpenVPN session.

Another advantage is that open connections through the tun/tap-based tunnel
will not be reset if the OpenVPN peer restarts.  This can be useful to
provide uninterrupted connectivity through the tunnel in the event of a DHCP
reset of the peer's public IP address (see the
.B --ipchange
option above).

One disadvantage of persistent tunnels is that it is harder to automatically
configure their MTU value (see
.B --udp-mtu
and
.B --tun-mtu
above).
.TP
.B --rmtun
Remove a persistent tunnel.
.TP
.B --dev tunX | tapX
TUN/TAP device
.SH SIGNALS