OpenVPN配置靜態共享密鑰，應對防火長城（GFW）封鎖

1. 背景：

防火長城在十八大期間前所未有的升級，導致大批OpenVPN不能訪問了。

2. 原因分析：

OpenVPN象幾乎所有的安全通信協議的缺陷一樣，最開始的密鑰交換階段所有交互流量都是明文的。防火長城或許發現了其中的一些特徵（signature，比如某些字元串)，這些特徵是其他應用協議中不會出現的。然後，GFW或許象當年封鎖tor 一樣 [2]，模仿OpenVPN客戶端去連接 伺服器。儘管不太可能成功連接，但是可以確認伺服器是否是OpenVPN。然後的動作可以想像：TCP RST 或者封地址，甚者有可能有串聯的設備動態丟包了。

3. 應對方法（之一）：

既然密鑰交換過程容易被發現，我們就不做密鑰交換了吧，使用預先商定的密鑰。儘管這對於安全性要求高的應用有風險，但是對於我們小老百姓翻牆，已經足夠了。

這種方法還有一個限制：只能有一個伺服器、一個客戶端。好在客戶端（一般在國內）可以配置成PPTP VPN伺服器，於是，用這種方法最好是這樣的結構：

OpenVPN Server <------> OpenVPN Client | PPTP Server <---> Multiple PPTP Clients

4. 操作步驟

參照［1］，這裡只介紹OpenVPN客戶和伺服器之間的共享密鑰配置，具體操作如下：

1） 在伺服器上運行下面的命令，生成共享密鑰（2048 bit ，足夠了吧？）

openvpn --genkey --secret static.key

把生成的static.key 傳到客戶端 openvpn 配置文件所在目錄下，如/etc/openvpn

2）伺服器端的配置：

dev tun
ifconfig 10.8.0.1 10.8.0.2
secret static.key
proto udp
# 選一個隨機的連線埠，至少不要用預設的1194
port 35287
comp-lzo
log-append openvpn-static.log

3）客戶端的配置：

#連線埠需要與伺服器設置的連線埠一致
remote IP_address_of_your_server 35287
proto udp
dev tun
ifconfig 10.8.0.2 10.8.0.1
secret static.key
#如果客戶端不制定連線埠，使用預設的1194，仍然容易被發現
port 23456
comp-lzo
log-append openvpn-static.log
redirect-gateway def1

注意：不能同時配置證書認證、同時又配置靜態密鑰認證。

然後，可以配置本地路由，使國內訪問不經過VPN。

5. 參考：

[1] How the Great Firewall of China is Blocking Tor : https://www.usenix.org/conference/foci12/how-great-firewall-china-blocking-tor

[2] Static Key Mini-HOWTO: https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html