http://feeds.feedburner.com/allinfa/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 [...]
via 美博园 http://feedproxy.google.com/~r/allinfa/~3/4oL8xdrr154/openvpn-gfw-shared-key.html
» 除声明转载均为原创，原文标题：OpenVPN配置静态共享密钥，应对防火长城（GFW）封锁 - 美博园翻墙
via 美博园 http://feedproxy.google.com/~r/allinfa/~3/4oL8xdrr154/openvpn-gfw-shared-key.html
No comments:
Post a Comment