Unfortunately, it’s not just these countries that deploy DPI technologies, but some private companies also use such devices in order to monitor their employees.
The 10 thousand feet view
Tor is a nice way to avoid basic censorship technologies, but sometimes DPI technology is so good that it can fingerprint Tor traffic, which is already encrypted, and block it. In response to that, Tor people devised a technology called Pluggable Transports whose job is to obfuscate traffic in various ways so that it looks like something different than it actually is. For example it can make Tor traffic look like a skype call using SkypeMorph or one can use Obfsproxy to obfuscate traffic to look like…nothing, or at least nothing easily recognizable. What’s cool about obfsproxy though is that one can even use it separately from Tor, to obfuscate any connection he needs to.
A warning
Even though obfsproxy encrypts traffic and makes it look completely random, it’s not a fool proof solution for everything. It’s basic job is to defend against DPI that can recognize/fingerprint TLS connections. If someone has the resources he could potentially train his DPI box to “speak” the obfsproxy protocol and eventually decrypt the obfuscated traffic. What this means is that obfsproxy should not be used as a single means of protection and it should just be used as a wrapper _around_ already encrypted SSL traffic.
If you’re still in doubt about what can obfsproxy protect you from and from what it can’t, please read the Obfsproxy Threat Model document.
Two use cases
Obfuscate an SSH and an OpenVPN connection.
Obviously one needs a server outside the censorship perimeter that he or someone else will run the obfsproxy server part. Instructions on installing obfsproxy on Debian/Ubuntu are given in my previous blog post setting up tor + obfsproxy + brdgrd to fight censhorship. Installing netcat, the openbsd version; package name is netcat-openbsd on Debian/Ubuntu, is also needed for the SSH example.
What both examples do is obfuscate a TLS connection through an obfsproxy server so that it looks innocent. Assuming that the most innocent looking traffic is HTTP, try running the obfsproxy server part on port 80.
SSH connection
Scenario:
USER: running ssh client
HOST_A (obfsproxy): running obfsproxy on port 80 and redirecting to HOST_B port 22
HOST_B (dst): Running SSH server on port 22
What one needs to do is setup the following “tunneling”:
ssh client —> [NC SOCKS PROXY] —> obfsproxy client (USER)—> obfsproxy server (HOST_A) —> ssh server (HOST_B)
Steps:
1. on HOST_A setup obfsproxy server to listen for connection and redirect to HOST_B:
# screen obfsproxy --log-min-severity=info obfs2 --dest=HOST_B:22 server 0.0.0.0:802. on USER’s box, then configure obfsproxy client to setup a local socks proxy that will obfuscate all traffic passing through it:
$ screen obfsproxy --log-min-severity=info obfs2 socks 127.0.0.1:9999 Then instead of SSH-ing directly to HOST_B, the user has to ssh to HOST_A port 80 (where obfsproxy server is listening).
3. on USER’s box again, edit ~/.ssh/config and add something along the following lines:
Host HOST_A ProxyCommand /bin/nc.openbsd -x 127.0.0.1:9999 %h %pThis will force all SSH connections to HOST_A to pass through the local (obfsproxy) socks server listening on 127.0.0.1:9999
4. Finally run the ssh command:
$ ssh -p 80 username@HOST_AThat’s it. The connection will now pass get obfuscated locally, pass through obfsproxy server at HOST_A and then finally reach it’s destination at HOST_B.
OpenVPN connection
Scenario:
USER: running OpenVPN client
HOST_A (obfsproxy): running obfsproxy on port 80 and redirecting to HOST_B TCP port 443
HOST_B (dst): Running OpenVPN server on port 443
What one needs to do is setup the following “tunneling”:
openvpn client —> obfsproxy client (USER)—> obfsproxy server (HOST_A) —> OpenVPN server (HOST_B)
Steps:
1. on HOST_A setup obfsproxy server to listen for connection and redirect to HOST_B:
# screen obfsproxy --log-min-severity=info obfs2 --dest=HOST_B:443 server 0.0.0.0:802. on USER’s box, then configure obfsproxy client to setup a local socks proxy that will obfuscate all traffic passing through it:
$ screen obfsproxy --log-min-severity=info obfs2 socks 127.0.0.1:9999 Then instead of connecting the OpenVPN client directly to HOST_B, the user has edit OpenVPN config file to connect to HOST_A port 80 (where obfsproxy server is listening).
3. on USER’s box again, edit your openvpn config file, change the ‘port’ and ‘remote’ lines and add a ‘socks-proxy’ one:
port 80 remote HOST_A socks-proxy 127.0.0.1 9999
This will instruct the OpenVPN client to connect to HOST_A passing through the local (obfsproxy) socks server listening on 127.0.0.1:9999 4. Finally run the openvpn client command:
$ openvpn client.configThat’s it.
Security Enhancement
You can “enhance” obfproxy’s security by adding a shared secret parameter to command line, so anyone who doesn’t have this secret key won’t be able to use the obfsproxy server, decryption of packets will fail:
# screen obfsproxy --log-min-severity=info obfs2 --shared-secret="foobarfoo" --dest=HOST_B:443 server 0.0.0.0:80 $ screen obfsproxy --log-min-severity=info obfs2 --shared-secret="foobarfoo" socks 127.0.0.1:9999 Documentation
Or at least…some documentation.
Your best chance to understand the internals of obfsproxy is to read the protocol specification
For more info about obfsproxy client part, read the documentation here: obfsproxy client external
For more info about obfsproxy server part, read the documentation here: obfsproxy server external
Screenshots
For those who like meaningless screenshots, here’s what wireshark (which is certainly NOT a DPI) can tell about a connection without and with obfsproxy:
Without obfsproxy
With obfsproxy
*Update*
one can find openvpn configuration files for use with obfsproxy here:
Linux Client
Windows Client
from http://www.void.gr/kargig/blog/2012/10/05/bypassing-censorship-devices-by-obfuscating-your-traffic-using-obfsproxy/
-------------------------------------------------------
Use obfsproxy to obfuscate the openvpn traffic
Obfsproxy is a Tor subproject. It can be used to obfuscate (any) traffic so that it becomes unrecognizable. Obfuscating OpenVPN traffic using obfsproxy.Use obfsproxy
Obfsproxy is a Tor subproject. It can be used to obfuscate (any) traffic so that it becomes unrecognizable. Obfuscating OpenVPN traffic using obfsproxy was suggested here, with one additional mail available here:"However, the obfsproxy project sounds very interesting. And it should be possible to use obfsproxy (as it can talk like a SOCKS proxy) with OpenVPN, by using the socks-proxy argument."
A quick obfsproxy setup
This setup will start obfsproxy on your openvpn server, listening to the port 21194. On the client it will start a obfsproxy serving as a SOCKS proxy, listening on the client on port 10194. The part which says "<some-random-key>" needs to be the same value on both server and client. The key can be a longer text string, with just random letters. I'd recommend to keep it long (at least 32 characters, which is 256 bits).Client side
Add the following lines to your existing openvpn config file:socks-proxy-retry
socks-proxy 127.0.0.1 10194
and change the --remote option to be
remote <YOUR-VPN-SERVER> 21194
That is, changing the port number to match the port number the server side obfsproxy will listen to.
Then start the obfsproxy like this:
[user@host: ~] $ obfsproxy --log-file=obfsproxy.log --log-min-severity=info obfs2
--shared-secret=<some-random-key> socks 127.0.0.1:10194
Server side
Here we tell obfsproxy to listen to TCP port 21194 and to send any obfsproxy clients to the OpenVPN server, listening on 127.0.0.1, port 1194. And remember to allow TCP connections from the "outside" to port 21194 in your firewall config. Start obfsproxy like this: [user@host: ~] $ obfsproxy --log-file=obfsproxy.log --log-min-severity=info obfs2
--dest=127.0.0.1:1194 --shared-secret=<some-random-key> server 0.0.0.0:21194
The OpenVPN server needs in this case just this line in the config:
port 1194
That's all the magic, and should be a complete working setup. (不错。我测试成功。上述的1194可改为其他的端口号,比如11384。首先在/etc/openvpn/openvpn.conf中修改，即修改openvpn服务器端的端口号。）
（【伺服器运行obfs】
# obfsproxy --log-min-severity=info obfs2 --shared-secret=
<some-random-key> --dest=127.0.0.1:11384 server 0.0.0.0:21195
【客戶端运行obfs】obfsproxy.exe --log-min-severity=info obfs2 --shared-secret=
<some-random-key> socks 127.0.0.1:10194 )
from https://community.openvpn.net/openvpn/wiki/TrafficObfuscation
Overview
After my initial post about obfs4 on how to hide any TCP traffic and an example for hiding SSH traffic, it’s now time to do so for OpenVPN.
For this, I have written a Bash script to do the job. It’s called obfs4proxy-openvpn and is freely available under MIT license.
Supported transports
obfs4
The main goal of the script is to provide obfs4 transport to OpenVPN. This is also the main interest of this article.
This transport requires out-of-band CERT exchange between client and server and because of that, can provide some advanced functionalities which are missing in older transports.
obfs3
obfs3 transport is supported but should generally be avoided in favor of obfs4.
obfs2
obfs2, the oldest transport is supported as well (mainly because its supported by obfs4proxy). You really shouldn’t use it…
Architecture
Before going into detail, its good to have a basic idea on how different parts of the script work together to provide obfs4 functionality to openvpn.
Client architecture
- The script reads and validates its config file. This file is responsible for putting it in client mode as well as passing the required settings to it.
- The script does a basic check and validation on the specified openvpn config file. This file will be passed to the openvpn process later on.
- At this stage, obfs4proxy process is started acting as a SOCKS5 proxy server, listening to a random port.
- Based on its config, the script generates an appropriate socks5_auth file compatible with the openvpn.
- Using the specified openvpn config file, obfs4proxy local SOCKS5 port, and socks5_auth file, the execution is now passed to the openvpn client.
- openvpn client tries to connect to the remote server using the local obfs4proxy SOCKS5 proxy.
- obfs4proxy obfuscates the traffic and sends them along the line.
Server architecture
- The script reads and validates its config file. This file is responsible for putting it in server mode as well as passing the required settings to it.
- The script does a basic check and validation on the specified openvpn config file. This file will be passed to the openvpn process later on.
- At this stage, obfs4proxy process is started. It binds to a valid IP address and port.
- Based on its config, the script starts openvpn server process, passing it the required port/address for binding (to receive traffic from obfs4proxy).
- obfs4proxy receives the obfuscated traffic from the internet and de-obfuscate it.
- The de-obfuscated traffic is passed to the openvpn server.
obfs4proxy-openvpn config
A sample config file is provided in the examples/ folder.
Please also note that this file (specially when used in client mode), will contain possibly sensitive data (i.e, the CERT). So better to set its permission to either 600 or 640:
chmod 600 /etc/obfs4proxy-openvpn.conf
Below are all the valid options along with a description for each (default values are placed inside parenthesis):
General options
These are options that are valid for both client and server:
-
MODE: mode of operation client/server. -
TRANSPORT(obfs4): obfs4,obfs3 and obfs2 is supported. -
OPENVPN_CONFIG_FILE: For maximum flexibility, the script does not magically generate an openvpn config file for you, and expects that you provide it with one instead. There are however almost ready-to-use openvpn config samples available in the repository which you may use. -
OBFS4PROXY_WORKING_DIR(/var/lib/obfs4proxy-openvpn): The directory path that will be used for the obfsproxy log, config, as well as the socks5_auth file (in client mode). If the path does not exist, it will be automatically created by the script with the required permissions. It is possible to run multiple instance of the script by using different paths and config files. -
OBFS4PROXY_UID/OBFS4PROXY_GID(obfs4-ovpn / obfs4-ovpn): The user and group name that obfs4proxy will run in. If neither UID nor GID already exist on the system (and their value matches), they will be automatically created by the script1. The home directory of the UID, will be set to OBFS4PROXY_WORKING_DIR. So I suggest that you use different set of UID/GID per each script instance2. -
OBFS4PROXY_LOG_LEVEL(error): Can be one of none,error,warn,info,debug values which indicates the level of log for obfs4proxy. -
OBFS4PROXY_LOG_IP(false): Should supposedly disable scrubbing addresses in the obfs4proxy log if its set to true3.
obfs4 specific options
These options are valid only when using obfs4 transport:
IAT_MODE(0): Inter-Arrival Time mode. Essentially this option provides some protections against packet timing fingerprints. Valid values are 0, 1 or 2. Client and server values don’t need to be matched. Do note that you would sacrifice some performance if enabled (specially if it’s set to 2).
Client options
These options are only valid when running in client mode and are ignored in server mode:
CLIENT_UPSTREAM_PROXY: The optional upstream proxy that obfs4proxy should use when making outgoing network connections. It is a URI [RFC3986] of the format:
<proxy_type>://[<user_name>[:<password>][@]<ip>:<port>
obfs4 specific client options
These options are only valid when the client using obfs4 transport:
-
CLIENT_REMOTE_CERT: This is a 70-characters long base64 string which must be imported from the obfs4proxy running on the server side. It’s basically a combination ofCLIENT_REMOTE_NODE_IDandCLIENT_REMOTE_PUBLIC_KEYfor maximum portability. -
CLIENT_REMOTE_NODE_ID/CLIENT_REMOTE_PUBLIC_KEY: At its core, obfs4proxy uses these values for obfs4 transport. They can be directly specified instead ofCLIENT_REMOTE_CERT. But you generally shouldn’t be needing to do that.
Server options
These options are only valid when running in server mode and are ignored in client mode:
-
SERVER_OBFS4_BIND_ADDR/SERVER_OBFS4_BIND_PORT(0.0.0.0 / 1516): This is the address:port that the obfs4proxy server would listen for incoming connections from obfs4proxy client (i.e, It is the same address:port that you should put in the--remote host [port]directive in openvpn client config file). Note that you may run into permission issues if you try to specify a port less than 10244. -
SERVER_OPENVPN_BIND_ADDR/SERVER_OPENVPN_BIND_ADDR(127.0.0.1 / 1515): This is the address:port of the openvpn server that obfs4proxy server would redirect de-obfuscated traffic to. For this reason, the address is usually127.0.0.1to ensure real openvpn port is not accessible to the public. Another valid use is when the address is set to0.0.0.0making openvpn to bind to all interfaces. This could be beneficial and provides both obfuscated and non-obfuscated openvpn traffic at the same time.
OpenVPN configs
The script requires you to specify an openvpn config file. This is your typical openvpn client/server conf file in most aspects with couple of restrictions:
- Only TCP tunneling is supported and no UDP specific option should be specified. You don’t need to explicitly set the
--proto, this will be done by the script. - Don’t use
--daemonor--inetd. You may however run obfs4proxy-openvpn as a service. - You may not use any related proxy options in client mode (e.g,
--http-proxy,--socks-proxy). If you need to use a proxy to connect to the internet, it should be specified in CLIENT_UPSTREAM_PROXY. - You may not use
--local,--portor--lportin server mode. These settings are adjusted via SERVER_OPENVPN_BIND_ADDR / SERVER_OPENVPN_BIND_ADDR.
OpenVPN UID/GID
You should consider running openvpn process in a limited (and preferably dedicated) account. The nobody
UID should be available in most distros and it’s easy to use (but
again, a better approach would be having a dedicated account for it).
This is more of an OpenVPN topic but it usually involves adding --user and --group directives in the openvpn config file along with --persist-tun and --persist-key to deal with any permission issues that might arise upon receiving SIGUSR1.
In client mode when using obfs4 transport, openvpn process also needs to access the socks5_auth file. For that reason, it is recommended that t uses the same group as obfs4proxy. This is not needed in server mode.
To recap, if you plan to run openvpn in a limited account (e.g, “nobody”), these would be the appropriate directives in the openvpn conf file:
In client mode:
user nobody
group obfs4-ovpn
persist-tun
persist-key
In server mode:
user nobody
persist-tun
persist-key
Hardcoded arguments
To make openvpn work with obfs4proxy, these hardcoded arguments are passed to it:
In client mode:
openvpn \
--config $OPENVPN_CONFIG_FILE \
--proto tcp-client \
--socks-proxy 127.0.0.1 $CLIENT_OBFS4_SOCKS5_PORT $OBFS4PROXY_WORKING_DIR/socks5_auth
Note that CLIENT_OBFS4_SOCKS5_PORT will be generated by the obfs4proxy on each run and is not adjustable. $OBFS4PROXY_WORKING_DIR/socks5_auth is also only passed to the openvpn process when using obfs4 transport.
In server mode:
openvpn \
--config $OPENVPN_CONFIG_FILE \
--proto tcp-server \
--local $SERVER_OPENVPN_BIND_ADDR \
--lport $SERVER_OPENVPN_BIND_PORT
CIA triad
obfs4 transport ONLY. In particular, it does NOT apply to obfs3/obfs2 transports.
Performance can be slightly improved by getting advantage of the obfs4 protocol encryption.
obfs4-spec suggests that the CIA triad concept applies obfs4 protocol as well. So If the CERT kept secret, one may rely on obfs4 alone for confidentiality, integrity and authenticity. In such cases, it might be okay to disable openvpn’s own encryption and authentication mechanisms (You do this by not including any --secret or tls related settings.
If the CERT is made publicly available, confidentiality and
integrity are still kept but the client authenticity is lost. You have
to rely on other means (like pre-shared secret keys or tls auth) to authenticate the clients. But it still might be okay to use --cipher none with it.
In both cases, openvpn should output a scary warning message about the situation.
If you have even the smallest doubt, just play it safe. It takes less
than a second to setup a simple pre-shared key on the server:
openvpn --genkey --secret /etc/openvpn/secret.obfs4.key
and you’re not really reading this article to optimize OpenVPN throughput now, are you?!
obfs4proxy-openvpn arguments
The script comes with a limited support for command line arguments:
-h, --help: Outputs a simple help on the supported command line arguments.-c, --config CONFIG_FILE: Points to obfs4proxy-openvpn config file that the script should employ. Default is /etc/obfs4proxy-openvpn.conf. One use for this is to run multiple instances of the script simultaneously. It’s also possible to use CONFIG_FILE alone as the only non-optional parameter.--export-cert FILE: This option is only valid in server mode. The mandatory FILE argument is the path of a non-existent file to save the CERT string into (use-for stdout).-V, --version: Outputs version number and copyright information.
Running as a service
After the execution is passed to it, openvpn process stays in the foreground until it ended (at that point the script will cleanup after itself and exit).
It’s possible to run the script as a service. A sample service file is provided in the examples/ folder. Download it and follow these simple steps to setup the service:
- Adjust the
ExecStartline if required - Move and rename to the correct location:
mv examples/obfs4proxy-openvpn.service.sample /etc/systemd/system/obfs4proxy-openvpn.service - Reload systemd configuration:
systemctl daemon-reload - Start the service:
systemctl start obfs4proxy-openvpn.service - Optionally check its status:
systemctl status obfs4proxy-openvpn.service - Enable the service at startup:
systemctl enable obfs4proxy-openvpn.service
-
Using adduser for Debian based distros and useradd for the rest. ↩︎
-
You’d be able to delete the associated data just by deleting the user then. ↩︎
-
If you could make that actually work, let me know! ↩︎
-
An acceptable workaround for this is provided in my another post: How to hide (obfuscate) SSH traffic using obfs4
from http://web.archive.org/web/20230516155711/https://hamy.io/post/000f/obfs4proxy-openvpn-obfuscating-openvpn-traffic-using-obfs4proxy/
-------------------------------------------------------
关于obfsproxy的搭建，见 http://briteming.blogspot.co.uk/2012/12/obfsproxyshadowsocks-nodejs.html
https://github.com/edwardbarnard/udp_obfs (仅限于在linux desktop下使用）
(http://www.brokestream.com/udp_redirect.html)
https://www.torproject.org/projects/obfsproxy-instructions.html.en
http://sourceforge.net/mailarchive/forum.php?thread_name=510133EC.6000408%40topphemmelig.net&forum_name=openvpn-devel
---------------------
obfsproxy：模糊SSL或TLS加密流量的代理工具
据悉该工具目的是将SSL或TLS加密流量看起来像未加密的HTTP或即时通讯流量，从而突破封锁网络的国家对ssl加密通讯的封锁。目前该工具只能伪装SSL成SOCKS协议，未来将可以让加密流量伪装成任何协议。Tor执行董事Andrew Lewman打了一个比方，该工具就像是在法拉利上套丰田外壳，让法拉利看起来像丰田。
obfsproxy通过数据流量在客户端与tor节点之间的转换来试图规避网络审查。这种方式的数据传输就像是“看起来无特征的”（innocent-looking）流量。
obfsproxy支持多种协议，称为可插拔传输（pluggable transports）。
obfsproxy是一个单独的应用程序，完全独立于Tor，它使用一个内部协议来尽量减少终端用户的配置。
官方项目主页：
https://www.torproject.org/projects/obfsproxy.html.en
https://www.torproject.org/dist/obfsproxy/
-----------------------------------------------------------
利用obfsproxy+OpenVPN进行翻墙
一种利用obfsproxy+OpenVPN进行翻墙的方式，目前情况下相当稳定快速。
obfsproxy 是 Tor Project 的一个附属项目，采用流量混淆的方式专门用于突破互联网封锁。对用户的表现形式是一个TCP端口转发隧道，和 ssh -L 的功能完全一致。
有任何建议和问题欢迎在Twitter上和我讨论： @blankwonder
本文目标读者为有一定Linux和网络知识基础的用户，并没有把所有命令全部傻瓜话的列出，
A. 服务器端配置
OpenVPN配置
首先，我们需要先安装配置OpenVPN，如果你不需要IPv6的话，直接用包管理安装就行。否则请到官网下载2.3版本的源码自行编译安装。（目前最新版本是2.3 RC2）Debian编译OpenVPN所需要的包有libssl-dev, libpam0g-dev, liblzo2-dev
注：若是自行编译的OpenVPN，会缺少easy-rsa和init.d脚本，easy-rsa可以从OpenVPN官方的Github获得。init.d 脚本可以从各发行版的源码获得：接下来，按照标准的OpenVPN部署流程，生成各种密钥和证书（CA, server, client）。Linode 的官方文档写的非常好，这里不再阐述。
如果你没有修改安装prefix的话，OpenVPN会被安装到/usr/local/sbin/openvpn上，记得修改init.d脚本的相应内容。
- Debian/Ubuntu 用户：下载这个文件包 http://ftp.de.debian.org/debian/pool/main/o/openvpn/openvpn_2.3~rc1-1.debian.tar.gz，解压后找到openvpn.init.d文件，将其放到/etc/init.d/openvpn
- Gentoo 用户： sudo wget http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openvpn/files/openvpn-2.1.init -O /etc/init.d/openvpn
我使用的服务端配置(/etc/openvpn/openvpn.conf)如下：
local 127.0.0.1
port 40059
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 172.16.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
duplicate-cn
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 3
mute 10
接下来设置iptables进行NAT转换，这里省略了Linode文档中的安全部分（DROP），需要可自行补上。
sudo iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE
- Debian/Ubuntu 用户：启动脚本的路径为 /etc/rc.local
- Gentoo 用户：需要在/etc/local.d目录中创建一个后缀为.start的文件（如openvpn_iptables.start），将命令写在里面，同时记得使用chmod a+x。
sudo sysctl -w net.ipv4.ip_forward=1
现在可以把OpenVPN跑起来了，命令如下
sudo /etc/init.d/openvpn start
obfsproxy配置
现在开始编译安装obfsproxy，官方指导文档在这 https://www.torproject.org/projects/obfsproxy-instructions.html.en注：Gentoo用户在emerge libevent时请注意添加USE标记ssl。Debian/Ubuntu用户可以直接使用包管理安装
sudo apt-get install obfsproxy
obfsproxy obfs2 --dest=127.0.0.1:40059 server 0.0.0.0:9132
至此，服务端配置完毕。
B. 客户端配置
obfsproxy配置
首先编译安装obfsproxy，文档同上。Mac用户可以用使用homebrew安装，请参照这里 https://github.com/mtigas/homebrew-tor/blob/master/README.md由于我们需要将所有流量重定向到OpenVPN，而由于使用了obfsproxy，OpenVPN不知道服务器IP是多少没办法对到OpenVPN 服务器的流量进行特殊处理，所以我们需要手动将到服务器的路由固定下来，假设你的服务器IP为12.34.56.78，当前网络的网关地址是 192.168.1.1：（路由修改的命令请根据自己的操作系统自行调整，此处以Mac OS X为例）
sudo route add 12.34.56.78 192.168.1.1
obfsproxy obfs2 --dest=12.34.56.78:9132 client 127.0.0.1:50443
#!/bin/bash
SERVER_IP="12.34.56.78"
GATEWAY=`netstat -nr | grep '^default' | grep -v 'tun' | sed 's/default *\([0-9\.]*\) .*/\1/'`
/sbin/route add $SERVER_IP $GATEWAY
/usr/local/bin/obfsproxy obfs2 --dest=${SERVER_IP}:9132 client 127.0.0.1:50443
# Below line won't be excuted until obfsproxy exit
/sbin/route delete $SERVER_IP $GATEWAY
OpenVPN配置
接下来选择你喜爱的OpenVPN客户端软件进行连接就可以了，我的配置式样例如下：remote 127.0.0.1 50443 tcp-client
pull
tls-client
ns-cert-type server
persist-key
ca ca.crt
redirect-gateway def1
nobind
persist-tun
cert cert.crt
comp-lzo adaptive
dev tun
key key.key
dhcp-option DNS 8.8.8.8
resolv-retry infinite
log-append /var/log/openvpn.log
--------------------------------------------------------------
以obfsproxy解決中國2012年12月針對OpenVPN之網絡封鎖
多得偉大團結無私的執政集團，以及曾入選中國網民眼中二十大嘔心人物的北京郵電大學方濱興校長，2012年12月，GFW針對OpenVPN進行網絡封 鎖，經一番追查和考究，最終發現封鎖技術建基於OpenVPN PKI模式下TLS Handshake過程的特徵。我們一直依賴OpenVPN突破網絡封鎖的國內人員亦深受影響，以我們一直的認知，以為OpenVPN並沒有特徵可言，但 事實是，TLS Handshake還是會有特徵。
【應對方法】
解決方法1(消極):
「斬腳趾避沙蟲」，改用中古年代的Static-Key模式避過TLS Handshake過程，缺點是：
‧只能一個埠對應一個Client
‧一個Client就要有一個OpenVPN Instance
解決方法2(進取):
另一種比較進取的解決方法是要求OpenVPN社群建立為TLS Handshake過程進行加密的機制
透過TLS-Auth的Static-Key來進行，也是一個不錯的選擇
解決方法3(折騰):
以Obfsproxy模糊TLS Handshake過程，缺點是：
1. 效能上有小量Overhead
2. 不支援UDP…
3. Android手機似乎未有Obfsproxy客戶端…
以下是「解決方法3」的實作過程
【安裝obfsproxy】
#於伺服器和客戶端雙方安裝obfsproxy
$cd /usr/bin/
$sudo git clone https://git.torproject.org/obfsproxy.git
$cd obfsproxy
$./autogen.sh && ./configure && make
$sudo make install
#視窗用戶可下載Windows Obfsproxy Tor Browser Bundle
#https://www.torproject.org/dist/torbrowser/tor-obfsproxy-browser-2.4.6-alpha-2_en-US.exe
【伺服器obfs 設置】
$sudo obfsproxy –log-min-severity=info obfs2 –shared-secret=”Neverf0rget8964″ –dest=127.0.0.1:1194 server 0.0.0.0:689
#基於Obfsproxy限制，OpenVPN 伺服器所用的1194埠是指TCP1194，而非UDP1194
【客戶端obfs 設置】
$obfsproxy –log-min-severity=info obfs2 –shared-secret=”Neverf0rget8964″ socks 127.0.0.1:689
【伺服器Sample Init Script】
#! /bin/sh
### BEGIN INIT INFO
#Provides: ObfsProxy Init Script for OpenVPN
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Short-Description: Fuck GFW
# Description: ObfsProxy Daemon for OpenVPN
### END INIT INFO
PIDFILE=/var/run/obfsproxy.pid
PATH=/usr/bin:/sbin
DESC=”ObfsProxy Daemon for OpenVPN”
NAME=obfsproxy
DAEMON=/usr/bin/obfsproxy/obfsproxy
DAEMON_ARGS=”–log-min-severity=info obfs2 –shared-secret=Neverf0rget8964 –dest=127.0.0.1:8080 server 0.0.0.0:689″
TIMEOUT=30
SCRIPTNAME=/etc/init.d/obfsproxy
case “$1″ in start)
echo -n “Starting ObfsProxy Daemon for OpenVPN”
start-stop-daemon -b –start –quiet –make-pidfile –pidfile $PIDFILE –exec $DAEMON — $DAEMON_ARGS
;;
stop)
echo -n “Shutting down ObfsProxy Daemon for OpenVPN”
start-stop-daemon –stop –quiet –retry=QUIT/$TIMEOUT/TERM/5/KILL/5 –pidfile $PIDFILE –name $NAME
;;
esac
【客戶端ovpn 更改】
-remote openvpnserver.com 1194
+remote openvpnserver.com 689
+socks-proxy 127.0.0.1 689
【NAT】
伺服器端無須再就TCP 1194進行Static PAT，相反TCP 689要做NAT Mapping。
【結論】
方校長這次還玩得真有點過火
原文连接：https://www.facebook.com/notes/%E6%AF%8B%E5%BF%98%E5%85%AD%E5%9B %9B/%E7%B6%B2%E7%B5%A1%E8%A1%8C%E5%8B%95%E7%B5%84-%E4%BB%A5obfsproxy%E8%A7%A3%E6%B1%BA%E4%B8%AD%E5%9C%8B2012%E5%B9%B412%E6%9C%88%E9%87%9D%E5%B0%8Dopenvpn%E4%B9%8B%E7%B6%B2%E7%B5%A1%E5%B0%81%E9%8E%96%E5%A2%9E%E5%BC%B7/10150993099683078
------------
