# openvpn桥模式用的[我不用桥模式]# Configure server mode for ethernet bridging.# You must first use your OS's bridging capability# to bridge the TAP interface with the ethernet# NIC interface. Then you must manually set the# IP/netmask on the bridge interface, here we# assume 10.8.0.4/255.255.255.0. Finally we# must set aside an IP range in this subnet# (start=10.8.0.50 end=10.8.0.100) to allocate# to connecting clients. Leave this line commented# out unless you are ethernet bridging.;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100

# EXAMPLE: Suppose you want to give# Thelonious a fixed VPN IP address of 10.9.0.1.# First uncomment out these lines:;client-config-dir ccd;route 10.9.0.0 255.255.255.252# Then add this line to ccd/Thelonious:# ifconfig-push 10.9.0.1 10.9.0.2

# 下面这句使客户端所有网络通信通过vpn# If enabled, this directive will configure# all clients to redirect their default# network gateway through the VPN, causing# all IP traffic such as web browsing and# and DNS lookups to go through the VPN# (The OpenVPN server machine may need to NAT# the TUN/TAP interface to the internet in# order for this to work properly).# CAVEAT: May break client's network config if# client's local DHCP server packets get routed# through the tunnel. Solution: make sure# client's local DHCP server is reachable via# a more specific route than the default route# of 0.0.0.0/0.0.0.0.;push "redirect-gateway"

# 这段常用于测试用途，注释该条可实现限制一个证书在同一时刻只能有一个客户端接入# Uncomment this directive if multiple clients# might connect with the same certificate/key# files or common names. This is recommended# only for testing purposes. For production use,# each client should have its own certificate/key# pair.# IF YOU HAVE NOT GENERATED INDIVIDUAL# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,# EACH HAVING ITS OWN UNIQUE "COMMON NAME",# UNCOMMENT THIS LINE OUT.;duplicate-cn

# 活动连接保时期限# The keepalive directive causes ping-like# messages to be sent back and forth over# the link so that each side knows when# the other side has gone down.# Ping every 10 seconds, assume that remote# peer is down if no ping received during# a 120 second time period.keepalive 10 120

# 设置日志记录冗长级别# Set the appropriate level of log# file verbosity.## 0 is silent, except for fatal errors# 4 is reasonable for general usage# 5 and 6 can help to debug connection problems# 9 is extremely verboseverb 3

# 重复日志记录限额# Silence repeating messages. At most 20# sequential messages of the same message# category will be output to the log.mute 20[/replyview]

1. 编辑 vars 文件.2. 设置 KEY_CONFIG 指向openssl.cnf文件[默认vars已经做好,这个不用管了]3. 设置 KEY_DIR 指向你的key、证书等所在目录，这个目录不必已经存在，如果它存在将被自动rm -rf[默认vars已经做好,这个不用管了]4. 如果你觉得KEY_SIZE=1024不满足你的偏执狂，你可以设置其为2048[我觉得已经够了，所以这块不改] 其他如:国家、省份、城市、组织、Email自己看着改吧5 . vars6. ./clean-all7. As you create certificates, keys, and certificate signing requests, understand that only .key files should be kept confidential. .crt and .csr files can be sent over insecure channels such as plaintext email.8. You should never need to copy a .key file between computers. Normally each computer will have its own certificate/key pair.

BUILD YOUR OWN ROOT CERTIFICATE AUTHORITY (CA) CERTIFICATE/KEY

1. ./build-ca2. ca.crt and ca.key will be built in your KEY_DIR directory

BUILD A CERTIFICATE SIGNING REQUEST (Ifyou want to sign your certificate with a rootcertificate controlled by another individualor organization, or residing on a different machine).

1. Get ca.crt (the root certificate) from your certificate authority. Though this transfer can be over an insecure channel, to prevent man-in-the-middle attacks you must confirm that ca.crt was not tampered with. Large CAs solve this problem by hardwiring their root certificates into popular web browsers. A simple way to verify a root CA is to call the issuer on the telephone and confirm that the md5sum or sha1sum signatures on the ca.crt files match (such as with the command: "md5sum ca.crt").2. Choose a name for your certificate such as your computer name. In our example we will use "mycert".3. ./build-req mycert4. You can ignore most of the fields, but set "Common Name" to something unique such as your computer's host name. Leave all password fields blank, unless you want your private key to be protected by password. Using a password is not required -- it will make your key more secure but also more inconvenient to use, because you will need to supply your password anytime the key is used. NOTE: if you are using a password, use ./build-req-pass instead of ./build-req5. Your key will be written to $KEY_DIR/mycert.key6. Your certificate signing request will be written to to $KEY_DIR/mycert.csr7. Email mycert.csr to the individual or organization which controls the root certificate. This can be done over an insecure channel.8. After the .csr file is signed by the root certificate authority, you will receive a file mycert.crt (your certificate). Place mycert.crt in your KEY_DIR directory.9. The combined files of mycert.crt, mycert.key, and ca.crt can now be used to secure one end of an SSL/TLS connection.

SIGN A CERTIFICATE SIGNING REQUEST

1. ./sign-req mycert2. mycert.crt will be built in your KEY_DIR directory using mycert.csr and your root CA file as input.

BUILD AND SIGN A CERTIFICATE SIGNING REQUESTUSING A LOCALLY INSTALLED ROOT CERTIFICATE/KEY -- thisscript generates and signs a certificate in one step,but it requires that the generated certificate and privatekey files be copied to the destination host over asecure channel.

1. ./build-key mycert (no password protection)2. OR ./build-key-pass mycert (with password protection)3. OR ./build-key-pkcs12 mycert (PKCS #12 format)4. OR ./build-key-server mycert (with nsCertType=server)5. mycert.crt and mycert.key will be built in your KEY_DIR directory, and mycert.crt will be signed by your root CA. If ./build-key-pkcs12 was used a mycert.p12 file will also be created including the private key, certificate and the ca certificate.

IMPORTANT

To avoid a possible Man-in-the-Middle attack where an authorizedclient tries to connect to another client by impersonating theserver, make sure to enforce some kind of server certificateverification by clients. There are currently four different waysof accomplishing this, listed in the order of preference:

(1) Build your server certificates with the build-key-server script. This will designate the certificate as a server-only certificate by setting nsCertType=server. Now add the following line to your client configuration:

ns-cert-type server

This will block clients from connecting to any server which lacks the nsCertType=server designation in its certificate, even if the certificate has been signed by the CA which is cited in the OpenVPN configuration file (--ca directive).

(2) Use the --tls-remote directive on the client to accept/reject the server connection based on the common name of the server certificate.

(3) Use a --tls-verify script or plugin to accept/reject the server connection based on a custom test of the server certificate's embedded X509 subject details.

(4) Sign server certificates with one CA and client certificates with a different CA. The client config "ca" directive should reference the server-signing CA while the server config "ca" directive should reference the client-signing CA.